Archive for April, 2009


Testing: Squish!

Something to keep your eye on here: An upcoming GUI testing tool for your Cocoa Touch applications! Yep, the most deliciously named froglogic is promising a version of their Squish testing tool by “the upcoming Squish 4.0 release”, whenever that is.

Squish is a professional, cross-platform GUI and regression testing tool that enables testers to create and execute automated GUI tests for applications based on a variety of different GUI technologies. This includes applications based on Nokia’s Qt, Mac OS X Carbon and Cocoa, Java SWT/Eclipse RCP, Java AWT/Swing, Web/HTML/AJAX, and many other UI technologies. Squish stands out from other GUI test tools thanks to its close integration with each supported GUI technology—a feature which helps ensure that tests created with Squish are very robust and stable.

That’s quite the feature set, isn’t it now. Any of our Gentle Readers have any experience with Squish on this plethora of other platforms and have an opinion of how exciting this news actually is?

h/t: Jeff!


Code: L0SolicitReview

Well, this is an innovative approach to the problem of getting good reviews on the App Store: just go ahead and ask for them!

We all agree that having JUST negative solicitation (that is, Apple’s rate-on-delete) is bad, whether we agree or not that having it is a good thing (I think it is). What we lack is a way to solicit positive reviews from satisfied users to counteract the rate-on-delete ratings slump.

Well, here it is:

Find it on Google Code as part of the author’s UIKitPlus project; dunno if it will actually help with the negative selection problem … but it very likely isn’t going to hurt. One can hope.

h/t: iPhoneSDK!


Here’s another class for the prompt for reviews and ratings kind of thing:

Presenting, Appirater


Tip: iPhone Serial Number

So isn’t it annoying that when you need somebody’s iPhone ID for setting them up for Ad Hoc distribution and the like, there’s no way to easily copy it from iTunes? Well, here’s a handy way to get it as text. Plug it in, and have them go to and enter

system_profiler SPUSBDataType | grep 'Serial Number'

and just tell them to copy the text that appears!

Serial Number: eb2342b2feh5209e845fa7428e60f27a5ef93b7d

Ah, that’s much easier than relying on screenshots or questionable transcription abilities, isn’t it now?

[EDIT: Well, ok then ... apparently sometime since I did my first provisioning, iTunes got smart enough to actually copy the phone's ID when displayed. See first comment. My, you readers are so clever!]

[EDIT 2: No, wait -- there's actually an app, Ad Hoc Helper, from the redoubtable Erica Sadun up on the App Store for free to have your intended tester just email it to you directly. There you go. Brandon wins for that tip!]

Ad Hoc Helper


Code: SCListener

Here’s a good start for you if you’re interested in putting some microphone-activated features into your iPhone app:

Voice activation. Sounds cool, doesn’t it? And all the cool people are using it! Nintendo was on to something with their DS and its microphone: Wario’s little games were no match for a little heavy breathing. With the iPhone, Smule is using it up a storm! And iSteam? Yes! These guys get it: people love doing stuff with their mouths! If there’s some kind of reward involved, well then, now you’re talking. Blowing out candles, kissing, outright yelling up a scene—these are the things of life, right?

Yes, indeed. We’ll just lightly skip past that mouths bit, for the sake of our gentler readers, and focus on the code: it’s called SCListener and it’s on github for you to download. That’ll get you the input set up and metered … and off to the races with your blowing application. Er, we mean the application that you blow … er, no, we mean … yeah, well, you know.


OpenAL resources

So if you’re an old school Mac programmer, you’re probably vaguely aware that OpenAL is a fully Apple-supported API on the iPhone as well as desktop OS X these days, but haven’t looked into it all that much yet … hey, there’s all that CoreAudio code of yours sitting around that works fine, right? Well, yes, but there are good cross-platform reasons, particularly if you’re into that gaming thing and have a use for multitrack positional audio, to get familiar with it. The canonical destination is the above linked home, but here’s some iPhone-specific links of interest:

iPhone Programming Part 6: Multiple Sounds with OpenAL

This provides a handy-dandy Cocoa singleton wrapper class for your OpenAL management.

iPhone, OpenAL, and IMA4/ADPCM

How to decompress IMA4 audio files and pass them to OpenAL for playback. Smaller is always better!

OpenAL FAQ for iPhone OS

Never overlook the technical notes! It’s always worthwhile doing a full text search for those to catch stuff that isn’t in the formal documentation for a given API. As well, don’t miss the various Apple-blessed OpenAL sample code:


Basic example showing OpenAL usage in a 2D OpenGL environment. This sample demonstrates how to bind OpenAL sources to OpenGL objects to create an audio environment.


The code uses OpenAL to play a single audio source. Move source or listener position by dragging icons around on the grid. Turn accelerometer functionality on to set listener orientation by tilting the device.

Anything else to add to this list, Dear Readers?


UITableView Tips

Here’s a couple useful discussions on UITableView for you:

Resizing a UITableViewCell to Hold Variable Amounts of Text

In part one, I demonstrated how to use a UITextView and a UITableViewCell to create a field for users to enter large amounts of text. After the text is saved, I’d like to display that text in a different table. The problem is I don’t know the height of the text. I’ll tackle that problem now…

Organizing a complex UITableView by using a dispatch table

One problem with the table view is that the controller class tends to get very large and complex, especially if you have a multiple section table view that has different types of custom cells and behaviors … I’ve developed a technique that can make use of this technique but that goes beyond it by allowing you to delegate the handling of each section in a table view to its own class. It is also easily configurable if you need to add or remove a section type from your controller later, and allows you to localize your changes so that you don’t have to remember to modify code in several places.

Good stuff!


Code: Google Docs

Now here’s an interesting idea: Use Google Docs to provide free data sharing in your iPhone app.

In September, my small software company shipped our first iPhone app, a grocery list program called Grocophile. One of the most common requests from our users was the ability to exchange data over the Internet. Greg Robbins of Google’s Mac team suggested that the Google Docs API might be useful, so I jumped in and took a look.

This turned out to be a great way to give our users access to free Internet storage, letting them back up their data and share it across multiple devices…

…  If your app can store and retrieve its data in text, HTML or a spreadsheet, then Google Docs will work well for you. 

That does cover a wide variety of data, indeed. There’s source code here to check out if this sounds like something you’d want to look into!

h/t: iPhoneKicks!


Snippet: Building mailtos

Ever got some strange results trying to send emails on the iPhone? Yeah, us too. Here’s a workaround that may help — use the Core Foundation utilities instead of using NSString for everything:

This simple approach ensures that your full message will arrive properly at the iPhone mail program after you have your application open the merged URL. Escaping the html body text ensures that mailto: specific characters will not confuse the URL handler and that your e-mail will be built with the proper headers and body.

NSString *htmlBody = @"you probably want something HTML-y here";  
// First escape the body using a CF call  
NSString *escapedBody = [(NSString*)CFURLCreateStringByAddingPercentEscapes(kCFAllocatorDefault, (CFStringRef)htmlBody, NULL,  CFSTR("?=&+"), kCFStringEncodingUTF8) autorelease];

// Then escape the prefix using the NSString method  
NSString *mailtoPrefix = [@"mailto:?subject=Some Subject&body=" stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];  
// Finally, combine to create the fully escaped URL string  
NSString *mailtoStr = [mailtoPrefix stringByAppendingString:escapedBody];  

// And let the application open the merged URL  
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:mailtoStr]];

Now you know!


The Objective-C Runtime

So chances are that you’ve never delved into the Objective-C runtime too deeply … and even better that you can’t imagine any particularly good reason you’d want to. But since we here Under The Bridge suffer from terminally insatiable curiosity, whenever we hear of something like that off we go. We’ll skip over the gory details, but there’s some interesting suggestions for useful things to do,

  1. Automatic ivar/method searches. Apple’s Key-Value Coding does this kind of thing already: you give it a name, and it looks up a method or ivar based on that name and does some stuff with it. You can do that kind of thing yourself, in case you need to look up an ivar based on a name or something of the sort.
  2. Automatically register/invoke subclasses. Using objc_getClassList you can get a list of all classes currently known to the runtime, and by tracing out the class hierarchy, you can identify which ones subclass a given class. This can let you write subclasses to handle specialized data formats or other such situations and let the superclass look them up without having to tediously register every subclass manually.
  3. Automatically call a method on every class. This can be useful for custom unit testing frameworks and the like. Similar to #2, but look for a method being implemented rather than a particular class hierarchy.
  4. Override methods at runtime. The runtime provides a complete set of tools for re-pointing methods to custom implementations so that you can change what classes do without touching their source code.
  5. Automatically deallocate synthesized properties.  The @synthesize keyword is handy for making the compiler generate setters/getters but it still forces you to write cleanup code in -dealloc. By reading meta-information about the class’s properties, you can write code that will go through and clean up all synthesized properties automatically instead of having to write code for each case.
  6. Bridging. By dynamically generating classes at runtime, and by looking up the necessary properties on demand, you can create a bridge between Objective-C and another (sufficiently dynamic) language.

#5 is particularly interesting, as  it certainly would be convenient if that long list of IBOutlets you just added would clean themselves up automatically, wouldn’t it? And in the comments, there is a fellow who’s done just that:

Here’s a category of NSObject that can simplify a dealloc method. It adds the method setEveryObjCObjectPropertyToNil that sets every property of the receiver to nil. (Properties that are readonly or not an Objective-C object are ignored.) This frees the underlying object, if the property is declared copy or retain; and it does no harm if it was declared assign.

Nifty, indeed. Even if you’re quite sure you’re conscientious enough to have no need of relying on this in your own code, the implementation is still worth taking a look at to figure out just how the magic happens when you want to do introspective stuff like this!

h/t: iPhoneKicks!


Snippet: Debug Macros

[EDIT: Revised to highlight the drama!]

Here’s a couple handy tips for your collection of Objective-C debugging macros which made it to the front page of iPhoneKicks where we noticed it, but it appears — see comments below! — were lifted wholesale from this post a month earlier, and the apparent real author is on a mission to set the Internet straight. Heh. That’s kinda amusing in a goths-on-LJ kind of way, isn’t it now? But seriously, this does look like a rather tacky case of blog plagiarism, so we’re happy to spotlight the controversy. Stay tuned for rebuttals!

That said, wherever credit is properly due, these are still worth appropriating for yourself:

Tip #1: __PRETTY_FUNCTION__ will provide the Objective-C class name and method call.

#define ALog(format, ...) NSLog(@"%s:%@", __PRETTY_FUNCTION__,[NSString stringWithFormat:format, ## __VA_ARGS__]);
#define MARK	ALog(@"%s", __PRETTY_FUNCTION__);  
Use like
ALog ( @"My iPhone is an %@, v %@",
    [[UIDevice currentDevice] model],
    [[UIDevice currentDevice] systemVersion]);
and you get nicely readable output like this
2008-24-12 12:34:56.789 MyApp00000:000] -[MyAppDelegate applicationDidFinishLaunching:]:My iPhone is an iPhone Simulator, v 2.2

Tip #2: Easy timer integration with NSTimeInterval.

#define START_TIMER NSTimeInterval start = [NSDate timeIntervalSinceReferenceDate];
#define END_TIMER(msg) 	NSTimeInterval stop = [NSDate timeIntervalSinceReferenceDate]; ALog([NSString stringWithFormat:@"%@ Time = %f", msg, stop-start]);
Use like
  // do time intensive stuff
  END_TIMER(@"did time intensive stuff");
and get a log message like
2008-24-12 12:34:56.789 MyApp[00000:000] -[MyAppDelegate myFunction:]:did time intensive stuff Time = 1.2345678
Also check out  The Evolution of a Replacement for NSLog for another take on handy macro tricks!

h/t: iPhoneKicks!