Archive for July, 2011


Complex Gesture Recognition

Have in mind doing something that requires gesture recognition, and found out in short order that’s a pretty tricky thing to do? Here’s an excellent article set for you:

Complex Gesture Recognition in iOS – Part 1: The Research

Complex Gesture Recognition in iOS – Part 2: The Implementation

Or for the ADD-inflicted, source is on github for an iOS $N Multistroke Recognizer implementation!

h/t: ManiacDev — check their post for links to $1 gesture recognizer stuff as well if that’s enough to suit your needs.



Here’s a possibly interesting collaboration tool: These people who apparently are Yet Another IM Network, because we certainly don’t have enough of those or anything, are doing their bit to stand out from the crowd by providing an SDK that lets you use their platform to share content from your app:

… By giving your users the ability to share with each other in real time, your app will be that much more fun and compelling (see the Sketchee story below). Sharing can also give a big boost in adoption – when a user who doesn’t have your app receives a Kik content message from it, Kik offers to take them directly to your download page where they can install it. All of a sudden you aren’t asking your users to share your app with their friends, but to share content from your app with their friends – content that requires them to get your app to view and interact with it. It’s the difference between inviting someone to join a social network vs. tagging a photo of them that requires them to join the social network to view it.

And best of all, it will only take you 10 minutes to add this kind of functionality to your app…

That does actually sound like a pretty solid reason to adopt this, if your app has content amenable to being shared, yes. And hey, if that brings some bright spark to mind, and you’ve got a couple weeks at loose ends right now, here’s some decent motivation to check it out:

$5,000 awards for the pioneers

To celebrate our beta SDK release, we want to offer some awards to our early adopter developers. We will be awarding $5,000 to the 3 developers who write and launch the best apps using our SDK before August 8th. Learn more about the awards here

h/t: readwriteweb!


Supporting iCade

So you heard about that iCade thing for the seriously retro iPad vibe?


If you’d like a full review, check out

Thoughts on the iCade (and on using it with Flash games)

but we’d just like to note for your development pleasure this bit, if you’ve already decided that would be a neat thing to support in your games:

So how do you add iCade support on iOS? Luckily someone made a library that makes it super easy: – basically you just add a special view to your main view controller which listens to keyboard events, and that view then sends messages to a delegate when buttons are pushed. There’s really not much more to it…

“Super easy” is a good level of integration complexity, yep.


Tip: Keyboard Area

As you know if you’ve ever tried it, it’s harder than you’d think it ought to be to figure out just where the keyboard is coming up on the screen. Here’s a tip which looks like a good approach:

Calculating Area Covered by Keyboard

I’ve seen several approaches to this so far, but they often hard code a certain position of the view or sizes. Like assuming that the covered view always reaches towards the bottom of the screen or always has a certain amount of space taken away from it by the status bar, navigation bar and possibly toolbar.

The whole thing gets even more complicated by the fact the the coordinate system of the app’s window is always in portrait even though your app rotates. So is the frame of the keyboard which you can get from an info dictionary in several notifications. I’ll show you the most universally working method I was able to come up with…

Those bars at the bottom are usually the tricky bit, we find. If this actually does handle them properly in just that little bit of code, we’ll be pretty impressed!


Bezier Path Boolean Ops

This is a solid series on manipulating NSBezierPaths:

How to implement boolean operations on bezier paths, Part 1

This post will focus on finding intersections between individual bezier curves, and the next will show how to implement the boolean operations based on that. The algorithm presented will be able to handle arbitrary closed bezier paths, including those with holes and self intersections.

If you’re impatient, you can skip straight to the commented source code

How to implement boolean operations on bezier paths, Part 2

This time I’ll show how to conceptually perform the four common boolean operations: union, intersect, difference, and exclusive or…

How to implement boolean operations on bezier paths, Part 3

In this final installment I’ll present the algorithm used to implement the boolean operations…

Beats figuring it all out yourself!


Core Text Tutorial

This is a rather nice introductory piece to the somewhat underdocumented Core Text framework to go along with the various bits and pieces we’ve noted before:

How To Create a Simple Magazine App with Core Text

This tutorial will get you started with Core Text by taking you through the process of creating a very simple Magazine application using Core Text – for Zombies!

You’ll learn how to:

  • lay formatted text down on the screen;
  • fine tune the text’s appearance;
  • add images inside the text content;
  • and finally create a magazine app, which loads text markup to easily control the formatting of the rendered text.
  • eat brains! Ok just kidding, that’s only for the readers of this magazine.

Good stuff, good stuff.


Tip: CoreGraphics Patterns

Here’s a snippet demonstrating, as the title says,

Using Patterns in Quartz2D

There’s not a ton of information out there about how to use patterns with the Quartz framework and drawing patterns, especially about combining it with UIColors ability to create colors with patterns…

Also sample project on github. And what actually got our attention enough to merit a blog note, check out

Stripe Generator 2.0 — “The Ultimate Tool For Web 2.0 Designers”

which looks like a rather nice site indeed for generating stripey background patterns.

Also might want to check out the latest from the ever expanding Wenderlich tutorial empire,

Photoshop Tutorial: How To Get The Repeating Image From A Pre-Made Pattern

h/t: @pzearfoss!


Threadsafe Date Formatting

So let’s say you’ve got a project that involves a bunch of repetitive date manipulations, like merging multiple RSS feeds into a single timeline. And having done some timing, and read QA1480, you’re quite aware that

[NSDateFormatter alloc] is insanely expensive. If you’re doing it more than once, YOU’RE DOING IT WRONG.

So you’re doing it only once. And then you find that you start getting a disturbing number of crash reports with terminal lines like

Thread 9 Crashed:
3 libicucore.A.dylib 0x300cafa4 icu::DateFormat::parse(icu::UnicodeString const&, icu::ParsePosition&) const + 120

And that makes you remember, uh-oh … NSDateFormatter is thread-unsafe. Whoops. Well, that throws the above statement for a loop.

However, we can edit that to the actually correct

If you’re doing it more than once per thread, YOU’RE DOING IT WRONG.

by using thread local storage as suggested in this Dropbox forum posting, for something like

+ (NSDateFormatter *)dateReader
   NSMutableDictionary *dictionary = [[NSThread currentThread] threadDictionary];
   NSDateFormatter *dateReader = [dictionary objectForKey:@"SCDateReader"];
   if (!dateReader)
      dateReader = [[[NSDateFormatter alloc] init] autorelease];
      dateReader.locale = [[[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"] autorelease];
      dateReader.timeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
      dateReader.dateFormat = @"EEE, dd MMM yyyy HH:mm:ss Z";
      [dictionary setObject:dateReader forKey:@"SCDateReader"];
   return dateReader;

+ (NSDateFormatter *)dateWriter
   NSMutableDictionary *dictionary = [[NSThread currentThread] threadDictionary];
   NSDateFormatter *dateWriter = [dictionary objectForKey:@"SCDateWriter"];
   if (!dateWriter)
      dateWriter = [[[NSDateFormatter alloc] init] autorelease];
      dateWriter.locale = [NSLocale currentLocale];
      dateWriter.timeZone = [NSTimeZone defaultTimeZone];
      dateWriter.dateStyle = NSDateFormatterMediumStyle;
      [dictionary setObject:dateWriter forKey:@"SCDateWriter"];
   return dateWriter;

That should work out nicely for you.


Fixing Symbolication

So you been having trouble with symbolication since the Xcode 4 release? And of course you checked out our Xcode 4 resources post and so applied the version on github which was described here, but that didn’t fix all your problems? Well, here’s a new take on it with a rather simple solution:

Fixing Xcode 4′s symbolicate utility to get comprehensible crash logs

…Digging into the errant symbolicatecrash source, I noticed that the code that finds the executable path tests each candidate using otool, but doesn’t seem to be able to comprehend the output from otool caused by running it on the wrong architecture.

So, replacing the rather unhelpful ‘die’ statement on line 323:

die “Can’t understand the output from otool ($TEST_uuid -> ‘$otool -arch $arch -l $path’)”;

With a “No, it ain’t this executable” response:

return 0;

…solves the problem immediately. Now I can drag crash logs straight into the Organizer in Xcode, and it’ll symbolicate correctly.

Give that a shot if you’ve been having problems and see how it works for you!


Saved Files Alert!

So does your iOS app write any of its working files to NSDocumentDirectory? Yep, pretty much all ours do too. And it looks like that might be a disaster waiting to happen if the situation described here comes to pass:

Game, utility or whatever app you are developing. Know this… as of iOS 5; the USER will have full visibility into your apps Document folder. <- as of beta 2

… Oh and in the new multi-tasking order of things… you guessed it… you can of course DELETE these files WHILE your app is in the background, which again; only YOU know what problems that will cause…

Gleep! Looks like it’s time to start being a lot more careful about file management. If you already were using NSLibraryDirectory where appropriate and writing all your code assuming users could mess with NSDocumentDirectory at will, well our hat (had we a hat) is off to you sir/madam. For the rest of us lazy types for which a rushed update appears in order, the timely warning linked above also includes a code snippet that looks like a good template for a one-time move of your data files and whatever from NSDocumentDirectory to NSLibraryDirectory. Handy, that.

h/t: @gregmeach!