5.0 Is Pending, 5.1 Beta already available!

Alright!  With 5.0 locked and pending Apple Review (thanks testers!) I couldn’t just sit idle and have been working on a 5.1 beta as well, that means new features!

New Features:

  • Pickup for mix – If there are items that you can mix to make items that you are missing then they will show up in a new section!
  • Pouch – If there are items you can mix in your pouch to make an item you are missing, the recipe will appear in it’s own section (How convenient!)
  • SD / DD / TD / 1xxx Searching – You can now enable / disable searching for items with issue numbers less than 10, 100, 1000 or 2000! (Good way to find trading or market fodder!)

Fixes:

  • Typos
  • Crash bug
  • Stall when sorting market items

Known Issues:

  • Haven’t tested it yet, but I think the recipe maker might be a little goofy if you have to mix more than one of the same type of item (sorry about that)

Feature Requests — Upcoming builds:

  • Pouch / User / Locked item searching
  • Automatic searching and background notifications when items are discovered as you move!
  • Favorite Number setting – Only show improvements if you don’t already have your favorite number, highlight any favorites found nearby or in pouches

Click here if you’d like to be a beta tester.

Email me if you are a tester and have found any undiscovered bug or would like to request a non-listed feature.

Beta 4

Okay, thinking this one might be the 5.0 GM:

New Features:

  • Disable market searching – For those of you who want to stumble upon your sets the usual way

Fixes:

  • Sped up market searching – Still a little slow if you are missing lots and have a really broad filter set
  • Unique items aren’t goofy!
  • If there are too many items to show, it will show a few, rotating to landscape or using iPad will still show more.
  • Grayed rows indicate how far away you are in order to pick up items

Known Issues:

  • Initial market searches are still a little slow, especially if you have lots of results
  • Tapping on Helicarrier rows / Market Rows don’t jump you right to the screen you need to be on — Limitation of the Wallab.ee API — I’m requesting an update
  • Some users with Emoji in their user name are unable to search :(

Feature Requests (these won’t come in this version but I’ve got it on the boiler):

  • Pouch / User / Locked item searching
  • Automatic searching and background notifications when items are discovered as you move!
  • Item mixes for missing items (both in your pouch and ingredient pickup)
  • TD and DD searching
  • Favorite Number setting – Only show improvements if you don’t already have your favorite number, highlight any favorites found nearby or in pouches

Click here if you’d like to be a beta tester.

Email me if you are a tester and have found any undiscovered bug or would like to request a non-listed feature.

Beta 3

New Features:

  • Disable nearby searching — Disables searching nearby locations (good for if you already know that they’re a bust)

Fixes:

  • Crash when you open settings on iPad
  • Sporadic crashing (some)
  • All pages of market load (previously just the first 1000 market items were loading)
  • Faster market item loading (Caching item type and set information in iCloud, we’ll see how this works out)
  • Branded items shouldn’t be goofy anymore in list

Known Issues:

  • Initial market searches are still a little slow, especially if you have lots of results
  • Unique items sets are goofy in the market search
  • When there are lots of item in the row they get too squished – Workaround, flip to landscape or use iPad — This is a real pain as I want to make all that information visible.. might end up limiting the amount of squish that can be done.
  • Grayed rows should be more clear that the issue is the user is too far away
  • Tapping on Helicarrier rows / Market Rows don’t jump you right to the screen you need to be on — Limitation of the Wallab.ee API — I’m requesting an update

Feature Requests (these won’t come in this version but I’ve got it on the boiler):

  • Pouch / User / Locked item searching
  • Automatic searching and background notifications when items are discovered as you move!
  • Item mixes for missing items (both in your pouch and ingredient pickup)
  • TD and DD searching
  • Favorite Number setting – Only show improvements if you don’t already have your favorite number, highlight any favorites found nearby or in pouches

Click here if you’d like to be a beta tester.

Email me if you are a tester and have found any undiscovered bug or would like to request a non-listed feature.

Build 2

New Features:

  • Market Search – Searches all markets for missing / improved items
  • Market Max – Set a max price you are willing to spend on any market item
  • Helicarrier Search – Searches the helicarrier for missing / improved items
  • Improvement Min – Lets you set a minimum improvement threshold for the improvements section

Known Issues:

  • Initial market search takes a LONG time (additional searches are much faster) – Improving this mechanism with better shared caching
  • Unique / Branded items sets are goofy in the market search – Will fix this with next beta build
  • When there are lots of item in the row they get too squished – Workaround, flip to landscape or use iPad — This is a real pain as I want to make all that information visible.. might end up limiting the amount of squish that can be done.
  • Grayed rows should be more clear that the issue is the user is too far away
  • Tapping on Helicarrier rows / Market Rows don’t jump you right to the screen you need to be on — Limitation of the Wallab.ee API — I’m requesting an update

Feature Requests (these won’t come in this version but I’ve got it on the boiler):

  • Pouch / User / Locked item searching
  • Automatic searching and background notifications when items are discovered as you move!
  • Item mixes for missing items (both in your pouch and ingredient pickup)
  • TD and DD searching
  • Favorite Number setting – Only show improvements if you don’t already have your favorite number, highlight any favorites found nearby or in pouches

Click here if you’d like to be a beta tester.

Email me if you are a tester and have found any undiscovered bug or would like to request a non-listed feature.

PirateWalla Beta Testing

Hi, my name is Kevin, creator of PirateWalla and I’m a Walla addict.

I’d kicked the habit by deleting WallaBee from my phone and trying to get back to my regular life, and had been clean for more than a year.  Then someone sent me an email asking for a couple of TD items that I had, as their wife was collecting the set, and I thought, “Sure, no problem, I’ll just get in and out real quick, and delete the app once more”.

As such, I’d like to announce that I’ve rebuilt PirateWalla a fine tool for searching and completing the sets in WallaBee from the ground up using swift and it is now open for beta.

Sign up here

Current features are a short set, designed to help find missing items and improve existing ones quickly as possible, but more will surely be coming soon as I catch up on all the easy to find items :)

  • Find nearby missing items (including missing Unique items)
  • Find nearby improved items
  • Quick jump – Items you are missing are shown in the same row as the place you need to go to pick them up, and tapping the row jumps you right to the place page in WallaBee!

Agario Portal — Now in Apple Store

agario_3

Agar.io is a fun, multiplayer, online game which you can play at http://agar.io

It has some mobile functionality, but for playing on the iPhone or iPad there are few glaring issues:

  1. To control, you must tap in the direction you want to go; this behavior is laggy and overall unplayable
  2. There is a button to split, however there is no button to eject mass, an important behavior for playing the game
  3. There is no ability to bring up the menu and change options
  4. On the iPhone, the main menu is hard to use because it’s sizing seems to be “not quite right” making it impossible in some resolutions to set your name.

There are also other “Agar.io” style games in the App store, but none of them have the full features, multiplayer aspects, or mechanics that we love about the real deal.

To solve these things, I wrote Agario Portal – Currently available in the App Store which solves these problems – a custom “browser” for playing Agar.io with a few benefits:

  • A joystick for better control
  • Buttons for both split and eject mass
  • Button to bring up main menu
  • Better format for main menu allowing user to see the whole thing.

Screenshots:

iPad Screenshot

iPhone Screenshot

Stupid bot creatures

Turned on image captcha.  I apologize to real people.  I do not apologize to the bots.

Script to get errors and logs out of xCode prebuild action

In response to an issue that came up on stack overflow – http://stackoverflow.com/a/18477820/285694

log_prebuild.sh

Run your script in your prebuild action using this script.

#!/bin/sh

# log_prebuild.sh
#
# Created by Kevin Lohman on 8/27/13.
#

#### Default Setup
scriptName=${BASH_SOURCE[0]##*/}
echoerr() { echo "Error - $scriptName - $@" 1>&2; exit 1; }
if [ -z $SOURCE_ROOT ]; then
outputFolder="$( cd "$( dirname "${SOURCE_ROOT}" )"/build && pwd )"
else
outputFolder="${SOURCE_ROOT}/build"
fi
stopOnError=""
unset scriptPath

##### Parse Parameters
while true ; do
case "$1" in
-v) echo "### Verbose mode enabled -v"; set -x; shift;;
--output) outputFolder=`python -c 'import os,sys;print os.path.realpath(sys.argv[1])' $2`; shift 2;;
"") break;;
*) if [ -z scriptPath ]; then
echo "Unknown flag: $1"; echoerr "usage: $scriptName [-v] [--output destinationFolder] scriptPath"
else
scriptPath=`python -c 'import os,sys;print os.path.realpath(sys.argv[1])' $1`
fi; shift;;
esac
done

if [ -z scriptPath ]; then
echoerr "Script path parameter needs to be set" > "$outputFolder/prebuild_error.log"
fi

if [ -f "$outputFolder"/prebuild_error.log ]; then
rm "$outputFolder"/prebuild_error.log
fi

echo "### Prebuild Logging Script Launching - $scriptPath" > "$outputFolder"/prebuild.log

$scriptPath >> "$outputFolder"/prebuild.log 2> "$outputFolder"/prebuild_error.log

enforcePrebuildFailures.sh

This script should be placed in a Run Script build phase for your target (ideally before compile)

#!/bin/sh

# enforcePrebuildFailures.sh
#
#
# Created by Kevin Lohman on 8/27/13.
#

prebuildLog="$SOURCE_ROOT"/build/prebuild.log
errorLog="$SOURCE_ROOT"/build/prebuild_error.log

if [ -s $prebuildLog ]; then echo "#### PRE-BUILD Output"; cat $prebuildLog; rm $prebuildLog; fi
if [ -s $errorLog ]; then echo "#### PRE-BUILD Error" 1>&2; cat $errorLog; rm $errorLog exit 1; fi

Support iOS 4 devices while building with the iOS 6 SDK

Apple has released iOS 6.0 SDK alongside the iPhone 5.  It comes with a number of changes (and deprecations) from previous SDK’s.  We still needed to support iOS 4 in our product (backwards compatibility), but had a large number of customers clamoring for iPhone 5 support (full screen).  Apple rejects any applications that are submitted with support for iPhone 5 that aren’t built with the iOS 6 SDK, so it was necessary to do a few tricks to support both iOS 4 and the new iPhone 5.

First our product has “Treat all errors as warnings” enabled, this meant that a number of deprecated functions that have been used all over the place (dismissModal, presentModal, etc…) are now throwing warnings and those warnings are treated as errors.  So it was necessary to add a build flag to the build settings in X-Code to not warn about deprecations (Under build settings change “Warn about Deprecated Functions” to no), this ignored all the errors that were related.  This was necessary because we couldn’t remove these errors from the code, as for most of the deprecated functions, there are no replacements until iOS 5, so if iOS 4 support is desired, we have to continue to use the old deprecated methods.

Next, the minimum target had to be changed to iOS 4.3 (Goodbye iPhone 3G support) but we still have support for other devices running 4.3 =< and iPhone 3GS > (Here is a matrix).

Finally, apple changed the way rotation works, and it was necessary to “hotwire” all of our existing rotation code into the new code.  shouldAutorotateToInterfaceOrientation: is the old way of checking rotation, and would be called (even when compiled with iOS 6 SDK) on any device that was running iOS < 6.  However this method would not be called for iOS 6 devices, instead it would look for the shouldAutorotate and supportedInterfaceOrientations methods, and extract it from there.  Rather then go through the 100+ view controllers we have with custom implementations for shouldAutorotateToInterfaceOrientation: I created a #define that would insert itself into the code for shouldAutorotateToInterfaceOrientation, and define the two new methods (should Autorotate and supportedInterfaceOrientations) so that they would query the old method and return an updated result.

I placed the following code in our Prefix file:

#ifdef __IPHONE_6_0 // Only do the rotation fix if we are building with iOS 6 API
@protocol DeprecatedRotationSupported
@optional
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)toOrientation;
- (BOOL)shouldAutorotate;
- (NSUInteger)supportedInterfaceOrientations;
@end

#define shouldAutorotateToInterface_fixed shouldAutorotate \
{ \
    UIViewController  *selfTyped = (UIViewController  *) self; \
\
    if(![self respondsToSelector:@selector(shouldAutorotateToInterfaceOrientation:)]) \
        return NO; \
    int optionCount = 0; \
    for(UIInterfaceOrientation orientation = UIInterfaceOrientationPortrait; orientation <= UIDeviceOrientationLandscapeLeft; orientation++) \
    { \
        if(![selfTyped shouldAutorotateToInterfaceOrientation:orientation]) continue; \
        if(optionCount==1) return YES; \
        optionCount++; \
    } \
    return NO; \
} \
\
- (NSUInteger)supportedInterfaceOrientations \
{ \
    UIViewController  *selfTyped = (UIViewController  *) self; \
\
    if(![self respondsToSelector:@selector(shouldAutorotateToInterfaceOrientation:)]) return UIInterfaceOrientationMaskPortrait; \
    \
    NSUInteger supported = 0; \
    \
    if([selfTyped shouldAutorotateToInterfaceOrientation:UIInterfaceOrientationPortrait]) supported |= UIInterfaceOrientationMaskPortrait; \
    if([selfTyped shouldAutorotateToInterfaceOrientation:UIInterfaceOrientationLandscapeLeft]) supported |= UIInterfaceOrientationMaskLandscapeLeft; \
    if([selfTyped shouldAutorotateToInterfaceOrientation:UIInterfaceOrientationLandscapeRight]) supported |= UIInterfaceOrientationMaskLandscapeRight; \
    if([selfTyped shouldAutorotateToInterfaceOrientation:UIInterfaceOrientationPortraitUpsideDown]) supported |= UIInterfaceOrientationMaskPortraitUpsideDown; \
    return supported;  \
} \
\
- (BOOL)shouldAutorotateToInterfaceOrientation
#else // We are building with the older API, leave shouldAutorotateToInterfaceOrientation alone.
#define shouldAutorotateToInterface_fixed shouldAutorotateToInterfaceOrientation
#endif // __IPHONE_6_0

Then, I did a replace all for shouldAutorotateToInterfaceOrientation: with shouldAutorotateToInterface_fixed: like below:

- (BOOL)shouldAutorotateToInterface_fixed:(UIInterfaceOrientation)toInterfaceOrientation

Also, make sure if you are using addSubview to add your main view to the window that you use setRootViewController instead.

iOS Security vulnerability allows keycapture and screengrabs without users knowledge

It is possible to do screen captures of foreground applications while your application is in the background, without the user notified. These can be strung together to create video, or analyzed to identify keyboard presses (key capture). The functionality to do this is present in the app store application “Display Recorder” but could be hidden in ANY application. Pretty concerning.

Display recorder was a tool that was made by Ryan Pietrich (http://rpetri.ch/) to allow the user to easily record iPhone activity, useful for demonstration videos, sharing bugs, etc.  It relied on a public, but later private API that allows applications to capture the contents of the screen.

Recently, another developer has taken Ryan’s idea (and marketing) and released a version (unrelated to Ryan) and remarkably, the Apple review team allowed it in to the store.  Might be a good idea to download it, if you have legit uses for an application like this, however it does feel a little greasy giving $2 to whoever posted it originally.. (which as best as I can tell a Vietamese company named Bugun Soft, with an otherwise unremarkable track record)

But that’s not what I’m really writing about.  Because the ability to take snapshots (and video) from an application in the background, without the users knowledge or consent (Note: Display recorder is controlled by the user, but there is no Apple based controls that require that level), is a major security problem.  Users passwords, email, and other private information can be put at risk.  Either because a developer could sneak this functionality into their product, and surreptitiously send data to a remote server, or someone with brief access to your phone could install the application on your device, start the recording, and later retrieve it.  Here is a sample video I took with Display Recorder, two things to note:

  • Display Recorder is nice enough to stick up a red band at the top to inform you that the recording is taking place (this is due to the microphone recording part, which isn’t needed for screen grabbing)
  • However, when an audio source is tried to be used (like when I try to play a voicemail), the band goes away, and the video recording continues
  • Notice how keyboard presses are highlighted, allowing you to see what is typed

I hope that Apple finds a way to deal with this such that the security risk is eliminated, and we can still have the kind of utility and function that is desired in the first place (screen recordings are incredibly useful).

Here is an example of how this could be used:

  1. Create an application or use an existing application as your base that does something harmless (basically a trojan)
  2. Whenever the application is launched and put into background, for the next 10 minutes, capture screenshots (using legitimate or Private API, as it seems that reviewers don’t always catch the usage)
  3. Upload those videos / captures / etc to whatever server you like
  4. Enjoy reading users e-mail and looking at their passwords.
  5. As an added bonus, they could analyze the video for specific icons from keyboard presses, and parse out the actual passwords for uploading (to reduce the upload footprint).

This represents a major security threat that could be present in ANY application, not just Display Recorder, however display recorder is just the first that makes it obvious what can be done.

WordPress Themes