In my current work of developing our organization wide practices for quality, I have made a deep dive into how DET is carried out on a regular basis. What I have seen is that DET is accepted and acknowledged as a valuable practice, however it is not really carried out in its full potential. There are many details and aspects of it to work on, especially regarding reporting and follow-up.

The other day I was asked to help one of our teams with a DET session. As they are familiar with the approach, I wanted to expand their view on its potential through light weight note taking and showed them an example of a very basic session template I like to use. I also explained the intentions of having bugs and issues separated as well as how I do with test notes and the summary. We decided to use a whiteboard instead and put stickies with issues and bugs on there for visualization. We spoke about the mission and decided on two different areas to focus on. The app is an iOS app where a new component is used in the app core functionality for iOS5.

The four of us paired into two teams with some different iOS devices and tested for about 45 minutes. We found quite a few issues and bugs that were put on the whiteboard, but not so much notes about which areas we covered. Of course, by looking at the issues you might get a hint of what areas have been covered, but how much? We also quite quickly noted that we had to tag each issue with the test environment (iOS version and device), since they differed quite a lot. Most of the things found were considered bugs to fix, which is also not always the case in all projects or settings. It usually depends on the customer and the relationship to them, as well as having a decision maker on this present during testing. In this project, the scrum master/tech lead which was present knows the customer well enough to make those judgements.

But what about the learnings?

After the session debrief I got into a meta-debrief, discussing the outcome compared to my introduction about reporting. At first there was not very much understanding of why having test notes is valuable, but this shifted a little during our discussion. "While our smaller projects change that rapidly, even storing test notes might be waste" is a motivation I will take with me. I explained a common scenario of being asked what was tested and with what configuration. It could also be valuable for future test sessions to know what parts of a functionality was covered and when this was tested before. I also like to emphasize the possibility to explain current functionality which might not be explicitly stated in requirements.

The team was happy with the experience and I got some more input on how to improve the value of our DET sessions. I am not going to abandon the reporting, but I need to find a way of combining the fun part of interacting between pairs through the collaborative setting of the whiteboard. This actually helped getting attention on the issues in the debrief.

And then the developers actually got their own ideas of what a session note taking tool should look like to suit their needs, this is how they sketched it out after the session. I would explore some other possibilities before building our own for example RapidReporter or SessionWeb, but it is really cool that the meta-discussion could trigger the further thinking about the problem. Other aspects of the problem with collective knowledge transfers I wrote about here.

This category has served me well, and even got traction in the iOS developer community, so I never bothered to stop and think if there exist an even better solution.

Especially now that GDC exists, and doing an inline block to invoke on the main thread or a background queue is easier than ever before.

Until Today

Traveling home by bus as usual I got a flash of genius; Why not use proxy objects? Calling a method on the main thread should be no harder then this;

[[self.slider mainThreadProxy] setValue:0.5f animated:YES];

The old NSInvocation solutions have a few drawbacks. First of all there is no code completion for the arguments, secondly there is not even basic type checking, and lastly the implementation is quite ABI specific.

The NSObject class already has support for method forwarding, and wrapping method calls up into NSInvocation instances. Why not use seriously battle proven code that Apple provides.

The Skeleton

The implementation for -[NSObject mainThreadProxy] will be childishly simple:

-(id)mainThreadProxy;
{
    // Return self directly if already on main thread.
    if ([NSThread isMainThread]) {
        return self;
    } else {
        return [CWMainProxy proxyWithTarget:self];
    }
}

The CWMainProxy class is a simple private helper, that will perform all of the heavy lifting. The interface and life time code is very small:

@interface CWMainProxy : NSObject {
    id _target;
}
+(id)proxyWithTarget:(id)target;
@end

@implementation CWMainProxy

+(id)proxyWithTarget:(id)target;
{
    CWMainProxy* proxy = [[[self alloc] init] autorelease];
    proxy->_target = [target retain];
    return proxy;
}

-(void)dealloc;
{
    [_target release];
    [super dealloc];
}
@end

The Meaty Parts

Now comes the tricky parts; actually act like a proxy. The proxy is a simple NSObject subclass, first it needs to be able to fake to any caller that it can respond to everything that the proxies target responds to.

-(BOOL)respondsToSelector:(SEL)sel;
{
    return [super respondsToSelector:sel] ||
           [_target respondsToSelector:sel];
}

Next up if the object claims it responds to a selector but do not have an actual implementation, then we must provide a NSMethodSignature so the run-time can create a proper NSInvocation for us.

-(NSMethodSignature*)methodSignatureForSelector:(SEL)sel;
{
    if ([_target respondsToSelector:self) {
        return [_target methodSignatureForSelector:sel];
    } else {
        return [super methodSignatureForSelector:sel];
    }
}

And finally we need to actually forward the NSInvocation call to the main thread, as per the callers request:

-(void)forwardInvocation:(NSInvocation*)invocation;
{
    [invocation performSelectorOnMainThread:@selector(invokeWithTarget:)
                                 withObject:_target
                              waitUntilDone:YES];
}

Conclusions

Given some thought I regard this solution to be much more elegant than my old solution. And it even yields less and more readable code than using GCD on iOS 4 and later:

[[self.slider mainThreadProxy] setValue:0.5f animated:YES];
    // vs
dispatch_async(dispatch_get_main_queue(),
               ^{
                   [self.slider setValue:0.5f animated:YES];
               });

• The implementation is much smaller, and relies on the Foundation framework functionality, not my own Objective-C ABI hacks.
• It is less code to write to use the functionality.
• Xcode can do proper code completion and basic type checking.
• It is compatible all the way back to iPhone OS 2, or Mac OS X 10.0, if you should care.

The CWFoundation project on Github has a more complete implementation. With more support for optional blocking, delays, and more proxies not only for the main thread but also for background threads and operations queue.

You are seldom alone with great ideas, so a nod to Joachim Bengtsson who has written about an invocation grabber before.

Incrementing the version number of your project for every small update is often not feasible, if it involves manual labor it just does not get done. Would it not be nice if Xcode just autoincremented a build number for you every time you build?

This can be done

There are dozens of solution to the problem available by Google. Unfortunately most do not work in both Xcode 3.2 and Xcode 4, and many more require a lot of hacking, even running external Perl or Python scripts. Using avgtool seems to be a major overkill for most use-cases. There must be an easier way, and there is.

What we want to do is to have the build number available in our Info.plist file, so that it can be read and displayed at run-time. And we also want Xcode to automatically increment this number for every build.

Add a key named CWBuildNumber to your Info.plist file, and set it to a sane start value, maybe "0". You can load it at run-time with a short statement like:

NSString* buildNumber = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"CWBuildNumber"];

Both Xcode 3.2 and Xcode 4 allows to add a Run Script phase to any target. Unfortunately Xcode 3.2 and 4 run these scripts with different paths. PROJECT_DIR environment variable to the rescue! Secondly we want to rewrite the target's source Info.plist file, not the file bundled with the application, so make sure to order the script phase before the Copy Resources phase. Then just add this tiny script phase to your target build:

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CWBuildNumber" ${PROJECT_DIR}/MyApp-Info.plist)
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CWBuildNumber $buildNumber" ${PROJECT_DIR}/MyApp-Info.plist 

Conclusions

Happy developers, and happy tester. Maybe even happy users, if you choose to show the full version number including build number in the final product.

The Current State of Affairs

Most Open Source projects for iOS are distributed as a source code repository with an Xcode project. But here the good news stop for most projects. The Xcode project usually only has one target, a sample project, mixing the reusable code in the same bucket as the sample/incubator code around it.

The usage instructions suggest you drag and drop a directory, or even worse a collection of files, into your own project. This is a very primitive solution, passable in the '80s when all we had was disks and BBS:es, not good enough today. All history and connection back to the source is lost, any value added by source control systems is lost the second you decide to use an open source component this way. Any bug-fix or improvement you make will require a manual merge back to the original project. You also loose all tracking information the moment you copy a file, what version of project X did you use, some special branch?

This Need To Change

This affair also highly discourages re-use. Almost every open source project out there that involves network connectivity also uses Apple's Reachability example code as a base for determining network status. Apple's code is not complete for all use-cases, and not free of bugs, so almost every project has a more or less modified variant of the same code causing compiler errors. Ensuring that using several open source project in one application is bound to end up with conflicts. Leaving it up to you to determine which projects version of Reachability that is the master version, often you end up writing a third version of Reachability for your project. And none of these changes and improvements will ever end up in a re-usable way for the iOS community as a whole.

This is not an impossible problem to solve, in the Java world there is for example Maven that solves this very well. Maven is a huge tool, and re-inventing that wheel for iOS would be a mammoth task. Fortunately that is not needed; Xcode already has the basics that we need in order to create iOS projects that are highly extendable and re-usable.

There is a Solution Today

One Xcode project can have one or more targets, usually the target is your application, sometimes you have one target for iPhone and a separate target for iPad. Targets are not limited to applications, you can also have a Unit-test targets, and more importantly static library targets.

A static library target yield a static library that can be linked into any other target, so be applications or other static libraries. A static library is a cruder version of a Framework, like UIKit and Core Data that Apple provide us. Crude as they are, it is still good enough to use for sharing re-usable Open Source project components.

A Xcode project has the notion of sub-projects. A Xcode sub-project is a reference to another Xcode project. You can set the sub-project's Targets as direct dependencies for your targets, and instruct the sub-projects products to be linked with your products. In essence say "Use what that other Xcode project creates to build my project".

The idea of Xcode's sub-projects has a logical one-on-one mapping to sub-modules in Git. Meaning that exposing re-usable iOS Open Source projects as static libraries on for example github is as easy as can be.

Eating Your Own Dogfood

This is actually what I have done for years, ever since I released HessianKit in 2008. Most of the code you write will be re-usable for the next project, having an easy way group your re-usable components into a growing library will save you a lot of work.

Firstly I never have to start with a blank canvas for any project. But more importantly, when working on many applications, any bug fixes and improvements I make to my shared components immediately trickles out to all other projects as well. If I add animated insert of cells in my column table view for project A, then all other projects is only one git pull away from benefiting from this new feature as well.

Jayway have since a few weeks begun the process of publishing our re-usable components for iOS. So far this has resulted in three projects on github:

• CWFoundation - a collection of new classes and categories to add functionality that is commonly missing from Foundation framework.
• CWUIKit - a collection of classes and categories that do the same for UIKit. CWUIKit requires CWFoundation.
• CWCoreData - A collection of categories for Core Data that makes using Core Data in a multithreaded application a breeze.

These are living projects and will be updated with new functionally over time, and large enough to warrant a blog-post for each on their own. There are also a few Componentized forks of popular iOS open source projects at Jayway's github page.

Tutorial for Using a Sub-Project from a Sub-Module

Working with an environment like this have many benefits, but also requires some knowledge of both Xcode and git. There are a few gotchas to be aware of, limitation of Xcode and the linker, best explained with a short tuturial.

CWUIKit has additions to UIAlertView that allows an alert to be created directly from a NSError instance, just like AppKit do on Mac OS X. Lets walk through how to create a new project that uses this functionality from CWUIKit to display the error message from a faulty URL request.

This tutorial is for Xcode 3.2, but works with minor modifications for Xcode 4. Changes for Xcode 4 are written in block quotes like this.

1. Create new "Window-based Application" from Xcode.

I chose a Window-based app because it contains the least amount of template code, and fits the purpose of an example well.

2. Initialize the project directory as a git repo.

git init

We need to initialize the project directory as a proper git-repo in order to use git's sub-modules.

Skip this step if project is created with git-repo in Xcode 4.

3. Add sub-module

git submodule add git@github.com:jayway/CWUIKit.git Components/CWUIKit

This will create a sub directory named Components, this is where I by convention put all my sub-modules/sub-projects, it is not a hard requirement.

4. Update and initialize all submodules

git submodule update --init --recursive

A git-submodule is by default not initialized, this is to avoid downloading large amount of data for a sub-modules you do not need, such as a test project. This is why we must update and initialize the sub-projects to realize them when starting a new repo or cloning an old one.

5. Add sub-project

Locate CWUIKit.xcodeproj and drag and drop into your project.
Highlight the CWUIKit.xcodeproj item and ensure the "Target Membership" column, that has a bullet as symbol, is checked for the libCWUIKit.a product. This is the static library to link against.
Also add the CWUIKit target as a direct dependency to your applications target so that CWUIKit is automatically build before building your application.

It is not required to setup target membership in Xcode 4, only set Target as Target Dependency in Build Phases tab, and add the Product to be linked in the same tab.

6. Recursive Sub-Projects

Static libraries are by their nature linked into your binary, this means that if static lib A and static lib B both define the same global symbol C you will get a duplicate symbol ‘C’ error when linking you app.
CWUIKit uses functionality from CWFoundation, but because of this limitation of the linker it can not explicitly add this functionality to itself. Doing so would make it impossible to use CWUIKit side-by-side with other projects that also uses CWFoundation, such as CWCoreData.
The work around is that any project that includes CWUIKit must also include CWFoundation. So repeat step 5 with the CWFoundation.xcodeproj from /Components/CWUIKit/Components/CWFoundation.

Xcode 4 has full knowledge of recursive sub-projects, so this step can be skipped. Only add CWFoundation sub-projects product to be linked.

7. Add QuartzCore and OpenGLES frameworks to your target.

Static libraries can not enforce linking of frameworks on it’s own, so building the app in it’s current state would result in missing symbols errors.
Using CWUIKit requires the app to be linked against QuartzCore and OpenGLES frameworks for CoreAnimation and OpenGL additions.

8. Setup header search paths.

Unfortunately sub-projects headers are not automatically added to the search path of your projects. So you must add "Components/**" as a header search path for your project.

Xcode 4 considers header search baths to be an advanced setting, to change the build settings display for Basic to All if you can not find it.

9. Setup linker flags

Add "-all_load" to other linker flags.
The GCC and LLVM linker also has a limitation/bug for static libraries that will strip out any methods for categories on a class that is not defined in the static library. For example any method extending UIAlertView in libCWUIKit.a will be stripped out by this bug.

10. Add #import "CWUIKit.h" to you application delegate. And add this small code to the application:didFinishLaunchingWithOptions: method

NSError* error = nil;
[NSData dataWithContentsOfFile:@"wrong path!"
                       options:nil
                         error:&error];
[[UIAlertView alertViewWithError:error] show];

11. There is no step 11.

But there is a screenshot of the running app.

Conclusions

This method of using Xcode sub-projects and git sub-modules for managing shared components works very well, and scales to be even better the more sub-projects and developers you have. The greatest benefit is without any doubt that bug-fixes and new features by default always trickles back to their source and become re-usable for all.

All the downsides are in the limitations of static libraries themselves, and can unfortunately not be overcome unless Apple introduces proper support for third party frameworks in iOS SDK. The two major gotchas are missing symbols caused by missing frameworks required by dependencies, and duplicate symbols caused by implicit inclusion of dependencies from dependencies. I have found that the best solution is to always have a README with your project where you explicitly name each Framework and Component that is required.

Using Xcode sub-project to manage your builds solves the problem of dependency resolution without the need to write a new system, works on the developer's desktop as well as on a build server. Using git sub-modules to manage your dependencies solves the problem of including all recursive dependencies as well as versioning. Any sub-module can by locked at a particular stable version by commit or tag as required, with full history. But best of all; you as a developer is free to just code away knowing that you can later commit and push your changes back, independently of how or where the code originates.

The solution I have found is not yet another tool, or framework, but a simple pattern. I have not found an existing name for the pattern so I call it Sync-Async Pair. The idea is to hide the complexity of asynchronous calls and call-back behind a facade, and have a straightforward synchronous implementation. An implementation that is easy to write, test and extend.

Sync-Async Pair Pattern

As the name suggests the pattern consist of a method pair, one is synchronous, and the other is asynchronous. The asynchronous method is backed by the synchronous implementation, and is only responsible for erecting a simplified facade in front of the sometimes complex concurrent implementation.

The first priority is to expose a clean API, the second priority is an implementation that is simple, testable and maintainable. Turns out that beginning with a clean API design (how to use the code), steers you towards a clean implementation (how to write the code). Most developers do the mistake to first write the code, and then struggle to try to use their own code.

Sync-Asyn Pair begins by defining a public API that then steers towards a clean implementation. Let's assume we are implementing some kind of a book reader. We need two model objects; CWBook and CWChapter. Both books and chapters are fetched from the network, so we need concurrency in order to not block the UI thread.

For this example let's focus only on fetching the chapters associated with a book. All other operations would be implemented in a similar fashion. First we need a public API, two methods for the sync-async pair on CWBook, and a delegate protocol.

@protocol CWBookFetchChaptersDelegate <NSObject>
-(void)bookDidFetchChapters:(CWBook*)book;
-(void)book:(CWBook*)book failedFetchChaptersWithError:(NSError*)error;
@end
// ...
-(BOOL)fetchChaptersWithError:(NSError**)error;
-(void)fetchChaptersWithAsyncDelegate:(id<CWBookFetchChaptersDelegate>)delegate;

The synchronous method fetchChaptersWithError: is very straightforward to implement.

-(BOOL)fetchChaptersWithError:(NSError**)error;
{
    NSURL* url = [self URLForFetchingChapters];
    NSData* data = [NSData dataWithContentsOfURL:url
                                         options:0
                                           error:error];
    if (data) {
        return [self parseChaptersFromData:data
                                     error:error];
    }
    return NO;
}

How to construct the NSURL, or possibly NSURLRequest is not important. Nor is it important how you actually parse the resulting data sent from the server, that is totally left to our problem domain. Just make it synchronous and super easy to write automatic unit checks for!

Adding Concurrency

Now to the hard part, that is actually quite manageable; adding the concurrency. For this example I will use performSelectorInBackground:withObject:. Your specific implementation might need NSOperationQueue, or GCD if you have special needs such as queues or cancelable operations. The idea will remain the same.

The most basic, and common, implementation for the public async method simply fires off the concurrent operation:

-(void)fetchChaptersWithAsyncDelegate:(id<CWBookFetchChaptersDelegate>)delegate;
{
    [self performSelectorInBackground:@selector(fetchChaptersWithDelegate:)
                           withObject:delegate];
}

In most cases all it does is request a private method to be performed on a background thread at some point in time. This is also the perfect place to abort operations early, for example a no-op if a request such as fetching a thumbnail is already in progress.

The private method previously launched is where most of the work is done. This is where a NSAutoreleasePool is setup, the synchronous method is called, and the delegate is properly called on the proper thread. The basic implementation for fetching books would be:

-(void)fetchChaptersWithDelegate:(id<CWBookFetchChaptersDelegate>)delegate;
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    NSError* error = nil;
    BOOL success = [self fetchChaptersWithError:&error];
    if (success) {
        [[NSInvocation invocationWithTarget:delegate
                                   selector:@selector(bookDidFetchChapters:)
                            retainArguments:YES, self] invokeOnMainThreadWaitUntilDone:NO];
    } else {
        [[NSInvocation invocationWithTarget:delegate
                                   selector:@selector(book:failedFetchChaptersWithError:)
                            retainArguments:YES, self, error] invokeOnMainThreadWaitUntilDone:NO];
    }
    [pool release];
}

For this example I am using my NSInvocation additions to perform the delegate callbacks to the main thread, but it could just as easily been done using GCD. The additions are described in detail and available for download in this blog post, or from in the CWFoundation repo on github.

As you can see the boiler plate code for managing concurrency is actually very minimal, much less than 10 statements in total. The boilerplate code is almost reduced to only calling other methods, leaving very very few opportunities for bugs to sneak in.

Core Data in the Mix

The Sync-Async Pair pattern also lend itself beautifully for writing multi-threaded Core Data. The hassle of juggling NSManagedObjectID and NSManagedObject instances from different contexts can be completely left up to the private implementation that calls the synchronous method.

The private method responsible for calling the synchronous method and handling callbacks could be implemented as such:

-(void)notifyDelegate:(id)delegate ofSuccess:(BOOL)success withError:(NSError*)error;
{
    self = [[NSManagedObjectContext threadLocalContext] objectWithID:[self objectID]];
    if (success) {
        [delegate bookDidFetchChapters:self];
    } else {
        [delegate book:self failedFetchChaptersWithError:error];
    }
}

-(void)fetchChaptersWithDelegate:(id<CWBookFetchChaptersDelegate>)delegate;
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    self = [[NSManagedObjectContext threadLocalContext] objectWithID:[self objectID]];
    NSError* error = nil;
    BOOL success = [self fetchChaptersWithError:&error];
    [[NSInvocation invocationWithTarget:self
                               selector:@selector(notifyDelegate:ofSuccess:withError:)
                        retainArguments:YES, delegate, success, error] invokeOnMainThreadWaitUntilDone:NO];
    [pool release];
}

Not much extra code, and the ugliness of handling Core Data's managed contexts is neatly hidden for clients at a single point in the code, that is much easier to test, debug, and maintain than most conventional Core Data code.

Conclusions

The simple Sync-Async Pair pattern makes it easy to write robust concurrent code. It is even a pattern that by design yields an elegant public API. It is also very easy to test, extend and even change the internal implementation completely without affecting any clients.

My friend and colleague Christian Hedin gave me tips on iCuke. Cucumber has been widely used for testing web applications, but now it’s also possible to test iOS (iPhone and iPad) apps with help of the iCuke library (https://github.com/unboxed/icuke). iCuke uses AppleScript to drive XCode in order to launch your application into the iOS Simulator. A preloaded library is used to inject a small HTTP server into your application. The HTTP server allows you to see an XML representation of the iOS device screen and to emulate input, such as taps, swipes and pinch gestures.

You can read more about it here:
http://www.unboxedconsulting.com/blog/cucumber-iphone-icuke
http://pragprog.com/magazines/2010-07/bdd-on-iphone-icuke

Really excited about Cucumber on iPhone we decided to give it a try. After installing iCuke and doing some test runs it was clear that some challenges had to be overcome to make this a truly useful tool for Behaviour Driven Development and automated testing of iOS apps.

Challenge 1: Screen returns the previous screen's xml

In our test, we wanted to tap a button, come to another screen and expected to see a text. When the test runs the iPhone is driven to the correct screen, e can see the expected text but the test fails anyway. After little debugging we realized that the method screen.xml returns old xml directly after changing the screen.

Solution:

We needed to refresh screen before checking if the expected text is on the new screen. iCuke has a method to refresh screen but it is private and we could not use it. So we just added a new method to the existing ICukeWorld class.

class ICukeWorld
 def refresh_screen
   refresh
   screen
 end
end

Calling this method before checking for the presence of the text solved this problem.

Later on, I forked iCuke and added this and some other methods.

git://github.com/DavorC/icuke.git

Challenge 2: Timing

Everybody knows that using sleep and delays in code is not so flexible.

sleep 3 # wait 3 seconds

We want to check something on the screen and give it 3 seconds to finish its loading.

Is it enough? Maybe, maybe not. Screen content loading could take 0.1 second or 5 seconds or... - You know what I mean.

In the first case loading is finished quickly and we unnecessarily spend 3 seconds for doing nothing . If we have a lot of delays in our code then our tests would waste a lot of precious time.

In the second case the delay is not long enough and the test fails.

Solution:

We need to write some help functions to wait for different items which are expected: some text, a button, downloading spinner etc.

Example with wait for text:

def wait_for_text(text, timeout = @@timeout)
 puts "#{method_name}(#{text}, #{timeout})" if @@debug
 refresh_screen
 start_time = Time.now
 until(screen.exists?(text)) do
   if Time.now - start_time > timeout
     flunk("#{method_name}: Timed out after #{timeout} seconds")
   end
   sleep 0.1
   refresh_screen
 end
end

As you can see the method is waiting for the text to appear and does checking every 0.1 second. As soon as the text is found the test continues. If, after given timeout, the text is still not found, the test fails.

I prefer to use unit test assertions in my tests (flunk is an assert which always fails). To use assertions with cucumber you need to add assertions to the Cucumber World:

require 'test/unit/assertions'
World(Test::Unit::Assertions)

Challenge 3: Different tappable object on screen can have the same text label.

Identifying objects on the screen only by text is not enough. By default, the first tappable object is tapped. What if we want to tap the second one?

Solution:

I created a set of help functions for:

returning all objects that satisfy some criteria
returning a specific object
waiting for a specific object
checking if a specific object exists

Objects are described in xml by: type, label, traits and index.

Here is an example of getting an array of all elements satisfying given attribute values.

def get_all_elements_by_type_label_and_traits(type, label, traits)
 puts "#{method_name}(#{type}, #{label}, #{traits})" if @@debug
 refresh_screen
 doc = REXML::Document.new(screen.xml.to_s)
 elements = REXML::XPath.match(doc, "//#{type}[@label=#{label.inspect}][@traits=#{traits.inspect}]")
 elements
end

Observe how it is easy to parse xml using ruby's REXML library.

Of course I could write more generic methods and decrease number of code lines - something like:

get_all_elements(type, options = {})

but I like readability so I wrote a set of help functions with more specific naming:

get_element_by_type(type, index = 0)
get_element_by_type_and_label(type, label, index = 0)
get_element_by_type_and_traits(type, traits, index = 0)
get_element_by_type_label_and_traits(type, label, traits, index = 0)
get_all_elements_by_type(type)
get_all_elements_by_type_and_label(type, label)
get_all_elements_by_type_and_traits(type, traits)
get_all_elements_by_type_label_and_traits(type, label, traits)
get_all_static_texts()
get_all_labels_by_type(type)
get_all_labels_by_traits(traits)
element_by_type_exists?(type, index = 0)
element_by_type_and_label_exists?(type, label, index = 0)
element_by_type_and_traits_exists?(type, traits, index = 0)
element_by_type_label_and_traits_exists?(type, label, traits, index = 0)
text_exists?(text)
wait_for_element_by_type(type, index = 0, timeout = @@timeout)
wait_for_element_by_type_and_label(type, label, index = 0, timeout = @@timeout)
wait_for_element_by_type_and_traits(type, traits, index = 0, timeout = @@timeout)
wait_for_element_by_type_label_and_traits(type, label, traits, index = 0, timeout = @@timeout)
wait_for_text(text, timeout = @@timeout)
get_center_of_the_element(element)
tap_coordinates(x, y)
double_tap_coordinates(x, y)
tap_element(element)
double_tap_element(element)
tap_text(text)
double_tap_text(text)

In order to use these functions you need to use iCuke from:

git://github.com/DavorC/icuke.git

Don't forget to use –recursive flag when you clone it:

git clone --recursive git://github.com/DavorC/icuke.git

After building and installing the iCuke gem you need to

require 'icuke/cucumber_ext'

instead of:

require 'icuke/cucumber'

Example of usage

In your feature-file:

Background:
 Given "myApp.xcodeproj" is loaded in the simulator

Scenario Outline: User try to login with different invalid credentials with valid signs
 When I am in "Account" section
  And I paste in username "<user>"
  And I paste in password "<pass>"
  And I tap Login button
 Then I will see alert dialog

 Examples:
 | user            | pass      |
 | test@test.com   | test      |
 | 123456          | qwertyui  |
 | ..@..com        | . . . €<> |

step definitions:

When /I am in "(.*)" section/ do |section|
 wait_for_text(section)
 tap(section)
 wait_for_element_by_type_and_label("UINavigationItemView", section)
end

When /I paste in username "(.*)"/ do |user|
 label = "E-mail"
 refresh_screen
 assert(get_all_static_texts().include?(label), "No text field with label #{label} was found")
 write_to_mac_clipboard(user)
 paste_clipboard_to_text_field("UITextFieldLabel", label)
end

When "I tap Login button" do
 wait_for_text("Login")
 tap("Login")
 wait_for_download_indicator_finish
end

Then "I will see alert dialog" do
 wait_for_element_by_type("UIAlertView")
end

Testing both iPhone and iPad
If you’re testing a universal app that runs on both iPhone and iPad I recommend writing different scenarios for the platforms. iPad in landscape mode is most likely to reuse most of code you have written for iPhone. Place them in different feature files and tag them with e.g. @iphone respective @ipad tags.

In your env.rb file:

$PLATFORM = "iphone"

Before('@ipad') do
 $PLATFORM = "ipad"
end

Before('@iphone') do
 $PLATFORM = "iphone"
end

Use in your feature files:

Given I have started application

Implementation:

Given "I have started the application" do
 # ... some code
 Given "\"myApp\" from \"myApp.xcodeproj\" is loaded in the #{$PLATFORM} simulator"
 # ... more code
end

If you wants to run iPad simulator in landscape mode:

def switch_ipad_to_landscape
 if(get_ipad_orientation == PORTRAIT)
   rotate_simulator_left
 end
end

where get_ipad_orientation is some application specific method to decide if the simulator is in portrait or landscape mode.

Running iCuke tests on Hudson server

It’s really nice to be able to run your test suite at given intervals, or when you commit to the source code repository. To run your iCuke tests on Hudson (which is a popular continuous integration build server) you must start your iPhone simulator from a terminal window. This is easiest to do by launching an AppleScript from Hudson.

Below are two scripts, one AppleScript and one shell script, that I used to run my iCuke tests from Hudson.

- run_cuke.scpt

-- run_cuke.scpt
tell application "Finder"
 set my_folder_path to container of (path to me) as text
 set posixPath to POSIX path of file my_folder_path
 set scriptPath to posixPath & "cuke.sh"
end tell
tell application "Terminal"
 activate
 do script scriptPath
end tell
delay 1200 -- it should be enough to finish all tests
set logscript to "grep -c FAILED " & posixPath & "cuke.log" & " | cat"
set cuke_failed to do shell script logscript
if cuke_failed > 0 then
 error "Cucumber tests failed"
end if
try -- do not leave terminals after test run
 do shell script "killall 'Terminal'"
end try

- cuke.sh

#!/bin/bash
scriptpath=$(cd ${0%/*} && echo $PWD/${0##*/})
SCRIPTFOLDER=`dirname "$scriptpath"`
echo Cucumber script is run in: $SCRIPTFOLDER
cd $SCRIPTFOLDER
cucumber $SCRIPTFOLDER/features --format=html --out $SCRIPTFOLDER/cuke_results.html > $SCRIPTFOLDER/cuke.log

Add these two scripts to your project.
Then, add this Cucumber hook to your env.rb file:

After do |s|
 if(s.failed?)
   puts "Scenario FAILED: <#{s.name}>"
   puts "More info about failure: SCREEN XML"
   puts screen.xml
 else
   puts "Scenario PASS: <#{s.name}>"
 end
end

On Hudson, create a new job and copy the configuration from your project's existing job.
Configure job:
add to description:

<a href="/hudson/job/Helios_Cuke/ws/cuke_results.html">Cucumber Results</a>
<b> | </b>
<a href="/hudson/job/Helios_Cuke/ws/cuke.log">Debug.log</a>

add build step (execute shell):

osascript ${WORKSPACE}/run_cuke.scpt

Of course you can change all scripts according your needs.
At the end you should have your iCuke tests running on Hudson and you will get both a nice test report in HTML and the debug output as a plain text.
There is a lot of potential for doing automated feature tests for iOS using Cucumber and with iCuke and the additions above you’ll hopefully be well on your way for doing BDD in your next iOS project!

Programmer vs. User

Exceptions are intended for signaling programming errors and fatal errors that the application can never recover from. One such error is index out of bounds when accessing an array. There is little reason to catch any exception; if you for example could not calculate a legal array index the first time around your app is in an illegal state. Exceptions are for your own use as a developer, to catch all programming errors in testing before shipping to the end user. Only secondary to inform the user of fatal errors when possible.

Errors are intended for signaling user errors, and conditions that can not be predicted until the end user runs your application. One such error is network timeout. There are many reasons to catch these errors; e.g. the user could be asked to check the network connectivity, and try again. Errors should always be handled, and be properly presented to the user. A user is much more forgiving if your application fails with a clear reason, than if it simply crashes or refuses to work.

Signal and Handle Exceptions

Exceptions are thown in Objective-C, just as in most other programming languages. You can construct your NSException object manually, and throw it using the @throw compiler directive if you like. But the preferred way is to use the NSException convenience class methods.

[NSException raise:NSInvalidArgumentException
            format:@"Foo must not be nil"];

Here we see the first divergence from how for example Java and C# handles exceptions. In Objective-C different exceptions are not normally signaled by different subclasses, but instead the exception is given a name, in the form of a constant string. Exceptions are however handled quite traditionally.

@try {
    // Normal code flow, with potential exceptions
}
@catch (NSException* e) {
    // Handle exception or re-throw
}
@finally {
    // Mandatory cleanup
}

Signal and Handle Errors

Errors do not use any special feature of the Objective-C run-time or programming language. Errors are instead treated as normal method arguments.

For synchronous tasks the error is returned as the last out argument of the method. A typical synchronous method signature with error handling looks like this:

- (id)initWithContentsOfURL:(NSURL *)url
                      error:(NSError **)outError

The client of such a task can always pass NULL to explicitly ignore the details of the error, the method must therefor also signal the error by the return value. This is typically done by returning nil, or NO if no other return value should exist. Ignoring the error is never recommended.

For asynchronous tasks the error is returned as the last argument of a delegate method. A typical asynchronous method signature with error handling looks like this:

- (void)connection:(NSURLConnection *)connection
  didFailWithError:(NSError *)error

The client of such a task can never opt out of receiving the error. It is still never recommended to ignore the error.

The information in an NSError is always localized and phrased in end-user friendly words. This is something you can trust of errors from system frameworks, and a hard requirement on you when you create your own errors. Therefor handling the error is never a burden, in the simplest case you can simply display the localized error message to the end user and call it a day.

- (void)connection:(NSURLConnection *)connection
  didFailWithError:(NSError *)error
{
	[[[[UIAlertView alloc] initWithTitle:[error localizedDescription]
                                 message:[error localizedFailureReason]
                                delegate:nil
                       cancelButtonTitle:NSLocalizedString(@"OK", nil)
                       otherButtonTitles:nil] autorelease] show];
}

There is more to NSError

Cocoa and Cocoa Touch have much in common. Classes not brought straight over from Mac OS X to iOS often have a sibling anyway. One such class is NSAlert from Mac OS X and it's sibling UIAlertView on iOS. They serve the same purpose of displaying an alert message to the end user, optionally with a few choices in the form of buttons.

One convenience method for handling errors on Mac OS X is -[NSAlert alertWithError:], it did not survive the transformation to UIAlertView on iOS. It is a pity, since it is a convenient way to quickly setup an alert with all the localized and human readable information. Basically turning the example code for handling an asynchronous error above from five lines of code, into a single line of code.

But that is not all. NSAlert and NSError on Mac OS X also have standardize facilities for handling recovery options. For example adding a "Retry" button to the alert, and calling the correct methods in response to this user selection.

On iOS NSError still have all the facilities to handle error recoveries, it is only UIAlertView that is lacking the final user facing bits. Fortunately this is easy to add. NSError manages error recovery with information held in it's userInfo dictionary. The following keys are used:

• NSLocalizedRecoverySuggestionErrorKey - A localized text with a general suggestion for how to recover from the error, for example "Check the network connection".
• NSLocalizedRecoveryOptionsErrorKey - An array of localized button titles such as "Retry".
• NSRecoveryAttempterErrorKey - An object conforming to the informal protocol NSErrorRecoveryAttempting.

The informal protocol NSErrorRecoveryAttempting declares one method that is significant for iOS:

- (BOOL)attemptRecoveryFromError:(NSError *)error
                     optionIndex:(NSUInteger)recoveryOptionIndex

The recoveryOptionIndex is the index into the array of button titles, and is the actual choice the user made for recovering from the error.

Adding a -[UIAlertView alertWithError:] convenience method to UIAlertView is made really easy since Objective-C has categories, and classes themselves are object instances so we can use the UIAlertView class as alert delegate for error recovery alerts.

@implementation UIAlertView (CWErrorHandler)

static NSMutableDictionary* cw_recoveryErrors = nil;

+(void)alertViewCancel:(UIAlertView *)alertView;
{
    NSValue* key = [NSValue valueWithPointer:(const void *)alertView];
    [cw_recoveryErrors removeObjectForKey:key];
}

+ (void)alertView:(UIAlertView *)alertView
clickedButtonAtIndex:(NSInteger)buttonIndex;
{
    NSValue* key = [NSValue valueWithPointer:(const void *)alertView];
    NSError* error = [cw_recoveryErrors objectForKey:key];
	NSString* buttonTitle = [alertView buttonTitleAtIndex:buttonIndex];
    NSInteger recoveryIndex = [[error localizedRecoveryOptions]
                                   indexOfObject:buttonTitle];
    if (recoveryIndex != NSNotFound) {
	    [[error recoveryAttempter]
             attemptRecoveryFromError:error
                          optionIndex:recoveryIndex];
    }
    [cw_recoveryErrors removeObjectForKey:key];
}

+(UIAlertView*)alertViewWithError:(NSError*)error;
{
    UIAlertView* alert = [UIAlertView alloc];
    [[alert initWithTitle:[error localizedDescription]
                  message:[error localizedFailureReason]
                 delegate:nil
        cancelButtonTitle:NSLocalizedString(@"Cancel", nil)
        otherButtonTitles:nil] autorelease];
    if ([error recoveryAttempter]) {
    	if (cw_recoveryErrors == nil) {
			cw_recoveryErrors = [[NSMutableDictionary alloc]
                                     initWithCapacity:4];
        }
        NSValue* key = [NSValue valueWithPointer:(const void *)alertView];

        [cw_recoveryErrors setObject:error
                              forKey:key];
        for (id recoveryOption in [error localizedRecoveryOptions]) {
        	[alert addButtonWithTitle:recoveryOption];
        }
        alert.delegate = (id)self;
    }
    return alert;
}

@end

Conclusion

The clean separation of exceptions and errors help you as a developer to catch programming errors during development and with unit tests, and also handle errors of interest to the end users in a standardized and uniform way. The very nature of NSError encourages developers to write descriptive error messages that end users can understand and make informed discussions about. Errors are unavoidable in any application of non-neglectable complexity, gracefully handling these errors gives an aura of quality and ensures happy users. Happy users means better sales.

Full source code to the examples in this post, including some more convenience methods can be downloaded here, and are released under the Apache 2 open source license.

From the testing perspective, I started to look at if testing on iPhone was different from any other software testing. I started off asking a senior app developer about his view on this, and got this answer in an email:

Iphone has very many complete components, which means that the developer doesn't have to invent the wheel all the time. These complete components are well tested by Apple.

Focus on iPhone app testing should be on the levels of
1. Application logic
2. Verifying that the Apple interface guidelines is followed.
3. Input validation

As a tester, this "easy to develop, easy to test" mentality should in my perspective trigger all bells and whistles as warning signs.

To cut to the point, having this background and tested some of the apps developed by my friends, I want to say that testing iphone apps is nothing different nor creates different kind of bugs than when testing other software. Some of the different type of bugs that can be shown through screenshots is shown here. The number of times I have gotten apps to crash is facts that I actually don't know, since it happens all the time.

For clarification, the environment is a regular iPhone 3G with the (at the time of any bug/screenshot) latest iOS3 software. I haven't upgraded to iOS4 yet because of the risk of the phone getting slower than it already is. My dad complained about this just couple of weeks ago after upgrade. Neither have I jailbroken the phone, and I am not a very big consumer of apps, which means that I have a very limited amount of apps on my phone.

The reasons that I point out for the bugs are just guesses from my point, and should be taken like guesses as well =)

Application UI issues

Application UI issues include Tweetdeck where sending a tweet progress bar is shown on top of the tweet search column header. Another UI issue which I have seen in many other apps include that the default(?) error popup message has been left as default without describing the usage error that the user in this case forgot to fill out some mandatory fields.

Application logic

I am actually not sure if these logic issues should be on client or server side, but my guess is that its client side. The question here is if its a coincidence that two different apps encounter null as profile name when looking at the profile pages. A wild guess is that they both use the same kind of ”complete components” in development.

Server issues

Very often you need to serve your client app with data from a server. Having incorrect or inconsistent data creates these kind of issues. Like when I use this app for showing when the tram leaves my location. You might expect that the data source is the same for both iphone client and monitor at the station. But comparing them showed clearly that this was not the case. Do you see it?

Showing a wordpress site with an embedded picture within the tweetdeck UI looks more challenging than you might think of. Maybe CSS issues on the server side?

Native apps

If we take a look beyond the 3rd party apps from app store, I also want to highlight some native apps. I have actually no clue why my alarm time disappears sometimes, but it does quite often. It could be noted that it has nothing to do with the modules that carry out screenshots. Gut feeling says that it has something to do with having many alarms in the list.

Also App store reveals that there are humans behind all this. Not thinking of the text length when listing the ”Top paid iPhone apps” is of course not a very serious bug, but there is a lot of trust to be lost from sceptical customers that are just about to open their wallet for getting their first paid app.

So with a background of a software tester, I would like to state that testing iPhone/iPad software is no different than testing other software. Take into account that my most recent experiences come from testing large enterprise systems integrated with each others. Software is software, and it is programmed by humans.

NSOperation do not have any facilities for returning a result when done as the Future do, you are left to implement this on your own. Which I have done a few times, and as a rule of thumb, make the solution generic when needed for the third time.

Operations works perfectly for background network activities. One common network activity is search-as-you-type, in this case you need to also cancel the previous operation if it has not yet been completed, so lets built this behavior into the generic solution as well.

API Design

What we want is an subclass of NSOperation that provides a future result, lets call this class CWFutureOperation. It is abstract, so users are supposed to subclass and implement main method just as for NSOperation, only difference is that the main method implementation must call setResult: before exiting.

The result that is set in the main method implementation can then be fetched using the blocking method result, equivalent to get() from the Java Future. As an alternative we would also like to be handed the method upon completion via a target-action pair. If the target-action pair is only called for finished operations that are not cancelled, then we get the search-as-you-type behavior for free.

It is also nice to be able to wrap up any method returning an object in a future operation as a convenience, so lets add that as well to our class interface:

@interface CWFutureOperation : NSOperation {
@private
    id _result;
    BOOL _isResultSet;
    id _completionTarget;
    SEL _completionSelector;
}

-(id)result;
-(void)setCompletionTarget:(id)target selector:(SEL)selector;
-(void)setResult:(id)result;

+(CWFutureOperation*)operationWithTarget:(id)target
                                selector:(SEL)selector
                                  object:(id)object;

+(CWFutureOperation*)operationWithInvocation:(NSInvocation*)invocation;

@end

Implementation

The client of the code must be able to fetch the result and the CWFutureOperation subclass must be able to set the result. The result method should block until the operation is finished if needed, and must properly return a result that can survive the operation that might be in a release pool. The implementation for this is straight forward, only minor complexity added in order to allow the result to be set multiple times:

-(id)result;
{
    if (![self isFinished]) {
        [self waitUntilFinished];
    }
    if ([self isCancelled]) {
        return nil;
    }
    return [[_result retain] autorelease];
}

-(void)setResult:(id)result;
{
    _isResultSet = YES;
    if (_result != result) {
        [_result autorelease];
        _result = [result retain];
    }
}

The reason that we flag if the result has been set is because we want to throw an exception if the subclass implementation of the main method failes to set the result before exiting, we add this behavior by overriding the start method in CWFutureOperation.

The start method will also call the target-action pair upon completion if the operation has not been cancelled. The target selector is always called on the main thread, this is so that we safely can update any UI using the calculated result without adding even more threading code.

-(void)start;
{
    [super start];
    if (![self isCancelled]) {
        if (!_isResultSet) {
            [NSException raise:NSInternalInconsistencyException
                        format:@"%@ did not set result.", self];
        }
        [_completionTarget performSelectorOnMainThread:_completionSelector
                                            withObject:self
                                         waitUntilDone:NO];
    }
}

Conclusion

The total amount of code is not muFuturesch, but this generic class adds a pattern to follow making design decisions for new application easy and consistent.

Solving the age old search-as-you-type problem can be as simple as this (Many assumptions, but you get the idea):

-(NSArray*)performSearchWithString:(NSString*)str;
{
    NSMutableArray* searchResults = nil;
    // Do actual search over the interwebz.
    return searchResults;
}

-(void)searchOperationDidComplete:(CWFutureOperation*)op;
{
    self.currentSearchOperation = nil;
    self.currentSearchResult = [op result];
    [self.searchDisplayController.searchResultsTableView reloadData];
}

-(BOOL)searchDisplayController:(UISearchDisplayController*)controller
  shouldReloadTableForSearchString:(NSString*)searchString;
{
	CWFutureOperation* op = [CWFutureOperation operationWithTarget:self
                                                          selector:@selector(performSearchWithString:) object:searchString];
    [op setCompletionTarget:self
                   selector:@selector(searchOperationDidComplete:)];
    [[NSOperationQueue defaultQueue]
    		replaceOperation:self.currentSearchOperation
               withOperation:op];
    self.currentSearchOperation = op;
    return NO;
}

The full source code including unit tests, and some additional categories for making operation queue life easier, can be downloaded here.

Modal View Controllers are Easy

Displaying a modal view controller is quite straight forward as this small example shows:

-(void)showDetails:(CWDetails*)details {
  UIViewController* vc = [[CWDetailsViewController alloc] initWithDetails:details];
  [self presentModalViewController:vc animated:YES];
  [vc release];
}

Popover View Controllers Can be Complex

Displaying the same details view controller in a popover on iPad is not quite as straight forward:

-(void)showDetails:(CWDetails*)details fromBarButtonItem:(UIBarButtonItem*)item {
  UIViewController* vc = [[CWDetailsViewController alloc] initWithDetails:details];
  self.popoverController = [[[UIPopoverController alloc]
                                  initWithContentViewController:vc] autorelease];
  self.popoverController.delegate = self;
  [self.popoverController presentPopoverFromBarButtonItem:item
                                 permittedArrowDirections:UIPopoverArrowDirectionAny
                                                 animated:YES];
  [vc release];
}

-(void)popoverControllerDidDismissPopover:(UIPopoverController*)popoverController {
  self.popoverController = nil;
}

As you see presenting a popover requires an extra object instance, this instance is not automatically retained while presenting the popover, like a modal view controller is, so the instance must be saved somewhere. In this example I saved the instance as a property. Notice that I also register as a delegate for the popover in order to remove this instance when the popover is dismissed. Here is another detail that is not obvious; this delegate callback is only called if user action dismisses the popover, not if you programmatically dismiss the popover. In the end using popovers quite quickly introduces a lot of code, and also coupling between view controllers for no other reason but to manage the popover instance.

Would it not be nice if you could instead do like this, and be done with it:

-(void)showDetails:(CWDetails*)details fromBarButtonItem:(UIBarButtonItem*)item {
  UIViewController* vc = [[CWDetailsViewController alloc] initWithDetails:details];
  [self presentPopoverViewController:vc fromBarButtonItem:item animated:YES];
  [vc release];
}

In fact what we want is to have these methods added to the public API of UIViewController:

@interface UIViewController (CWPopover)

@property (nonatomic, retain, readonly) NSSet* visiblePopoverControllers;

-(void)presentPopoverViewController:(UIViewController*)controller
                  fromBarButtonItem:(UIBarButtonItem *)item
                           animated:(BOOL)animated;
-(void)presentPopoverViewController:(UIViewController*)controller
                           fromView:(UIView *)view
                           animated:(BOOL)animated;

-(void)dismissPopoverController:(UIViewController*)controller animated:(BOOL)animated;
-(void)dismissAllPopoverControllersAnimated:(BOOL)animated;

-(void)setContentSize:(CGSize)size forViewInPopoverAnimated:(BOOL)animated;

@end

But That Requires Rewriting Existing Classes?

Yes it does, in an ideal world we want new methods and properties on the existing UIViewController class, and all subclasses, just as if Apple had put them there. This can easily be done thanks to the dynamic nature of Objective-C.

The view controller that is going to present other view controllers in a popover needs to have access to all UIPopoverController instances currently visible. The view controllers that are going to be presented in a popover need to have access to their container UIPopoverController, and for consistency with modal view controller its parent view controller.

Categories can only add and replace methods on an existing class, not modify instance variables. So we need to store this information in another way. I choose to tuck them away in a helper class called CWViewControllerPopoverHelper. With this small interface:

@interface CWViewControllerPopoverHelper : NSObject {
@private
    UIViewController* parentViewController;
    UIPopoverController* containerPopoverController;
    NSMutableSet* visiblePopoverControllers;
}
@property (nonatomic, assign) UIViewController* parentViewController;
@property (nonatomic, assign) UIPopoverController* containerPopoverController;
@property (nonatomic, retain) NSMutableSet* visiblePopoverControllers;

@end

The implementation is just synthesized properties, so no need to duplicate that one here.

So now all we do is to stuff one instance of CWViewControllerPopoverHelper into a global map using the UIViewController as key for each view controller that needs these extra instance information.

Fetching the Popover Helper

Let's implement a helper method that lazily creates a CWViewControllerPopoverHelper instance and puts it into the global map when needed. This way any view controller that do not need to support popovers will never be bothered, and those who do manage popovers gets one instance with no fuzz:

static NSMutableDictionary* popoverHelpers = nil;

-(CWViewControllerPopoverHelper*)popoverHelper;
{
    NSValue* key = [NSValue valueWithPointer:self];
    if (popoverHelpers == nil) {
        popoverHelpers = [[NSMutableDictionary alloc] initWithCapacity:16];
    }
    CWViewControllerPopoverHelper* helper = [popoverHelpers objectForKey:key];
    if (helper == nil) {
        helper = [[[CWViewControllerPopoverHelper alloc] init] autorelease];
        [popoverHelpers setObject:helper forKey:key];
    }
    return helper;
}

Proper Memory Management

There is one problem with storing the extra information in a global map; no view controller would ever be released from memory, since the map will hold on to the references. No problem, lets not use the actual view controller instance as a key, but a NSValue with the pointer to the instance. This solves the problem of releasing objects, but also means that the map will contain dangling pointers to released objects. We need to remove the dangling pointers whenever a UIViewController is deallocated.

Subclassing is not an option, since it would defeat our purpose of requiring the public API. It turns out we can replace the -[UIViewController dealloc] method with our own, and still call the original implementation. Each class and category that is loaded into the Objective-C run-time will call their own method +[? load] method, it is the public hook for further modifying a class or category before use. We want to use this hook to replace the default deallocation method with our own:

+(void)load;
{
    Method m1 = class_getInstanceMethod(self, @selector(dealloc));
    Method m2 = class_getInstanceMethod(self, @selector(cwPopoverDealloc));
    method_exchangeImplementations(m1, m2);
    m1 = class_getInstanceMethod(self, @selector(parentViewController));
    m2 = class_getInstanceMethod(self, @selector(cwPopoverParentViewController));
    method_exchangeImplementations(m1, m2);
}

As a bonus we also replace -[UIViewController parentViewController], to return the parent as would be expected for anyone who has ever presented a modal view controller. The implementations of our overrides are just as short and sweet:

-(void)cwPopoverDealloc;
{
    [self dismissAllPopoverControllersAnimated:NO];
    NSValue* key = [NSValue valueWithPointer:self];
    [popoverHelpers removeObjectForKey:key];
    [self cwPopoverDealloc];
}

-(UIViewController*)cwPopoverParentViewController;
{
    UIViewController* parent = [self popoverHelper].parentViewController;
    if (parent == nil) {
        parent = [self cwPopoverParentViewController];
    }
    return parent;
}

Wrapping Up

From here on it is just a tedious work to implement all 50 more lines of code needed to actually present the popovers, the first method as an example:

-(void)presentPopoverViewController:(UIViewController*)controller
                  fromBarButtonItem:(UIBarButtonItem *)item
                           animated:(BOOL)animated;
{
    UIPopoverController* pc = [[[UIPopoverController alloc]
                                initWithContentViewController:controller] autorelease];
	[self addPopoverViewController:pc passthroughViews:views];
    [pc presentPopoverFromBarButtonItem:item
               permittedArrowDirections:UIPopoverArrowDirectionAny
                               animated:animated];
}

The rest of the implementation, and a few other nice to have methods can be downloaded here.

Conclusions

The dynamic nature of Objective-C means that you can rewrite any existing API to suit your needs, without having access to the original source code. Sometimes just to add a new utility function where it belongs; a "sort by first name" method should probably be added to the actual people collection class, not as a spurious utility class.

Or as shown in this example to make a public API more convenient to use.

[someTextField performSelectorOnMainThread:@selector(setText:)
                              	withObject:@"A new text"
                             waitUntilDone:YES];

But not everything is an object

Since Objective-C is a superset of C, there are still all the types from C available. Such as all the primitives, including enums, and more complex struct types. Cocoa Touch is pragmatic and will use the most proper type for the use-case, not forcing everything into a square OOP hole.

This makes it quite hard to call for example -[UIView setHidden:], that takes a single BOOL argument. Same for -[UIView setFrame:], that takes a single CGRect struct argument, that in turn consists of one CGPoint and one CGSize struct.

Every type imaginable in C can be bundled in an NSValue instance. So we could bundle up the BOOL primitive, or the CGRect struct in a NSValue object. Then pass that object to the main thread, where it is unbundled and passed to the desired method. Quite cumbersome as it requires us to bundle, and unbundle types manually, and implement at least one extra method.

There must be an easier way

It turns out that NSInvocation can also handle any imaginable C type, or else it would not be able to invoke any imaginable Objective-C method. Making a NSInvocation invoke its method on the main thread is easy enough. Just add a category to the NSInvocation class, with a new method like this:

-(void)invokeOnMainThreadWaitUntilDone:(BOOL)wait;
{
  [self performSelectorOnMainThread:@selector(invoke)
                         withObject:nil
                      waitUntilDone:wait];
}

So now all you need to do is to create a NSInvocation object, fill it in with the primitive or struct types, and invoke it on the main thread. But creating and setting up a NSInvocation object is also a bit on the boring side...

There must be an even easier way!

We could use variable argument lists from plain old C. Too bad that they are untyped?
No despair, we know the target object for our invocation, and we know what method to call. So we have what we need to fetch the NSMethodSignature object for the call, that contains all the type information we need to safely process the va_list.

Our target machine is a Mac running 32- or 64-bit Intel CPU, or an iPhone OS device with a 32 bit ARM CPU. Turns out that on both platforms va_list is simply a void* pointer, to the stack frame. Even better va_start() will always flush any argument passed into the register on the stack frame. So we can skip most of the boring argument handling, by treating the arguments like a byte buffer, only advancing and aligning the buffer according to the information in the NSMethodSignature object.

A convenience method for creating a NSInvocation object for a particular target, selector, and list of variable arguments, would turn out like this:

+(NSInvocation*)invocationWithTarget:(id)target
                            selector:(SEL)aSelector
                     retainArguments:(BOOL)retainArguments, ...;
{
  va_list ap;
  va_start(ap, retainArguments);
  char* args = (char*)ap;
  NSMethodSignature* signature = [target methodSignatureForSelector:aSelector];
  NSInvocation* invocation = [NSInvocation invocationWithMethodSignature:signature];
  if (retainArguments) {
    [invocation retainArguments];
  }
  [invocation setTarget:target];
  [invocation setSelector:aSelector];
  for (int index = 2; index < [signature numberOfArguments]; index++) {
    const char *type = [signature getArgumentTypeAtIndex:index];
    NSUInteger size, align;
    NSGetSizeAndAlignment(type, &size, &align);
    NSUInteger mod = (NSUInteger)args % align;
    if (mod != 0) {
      args += (align - mod);
    }
    [invocation setArgument:args atIndex:index];
    args += size;
  }
  va_end(ap);
  return invocation;
}

Conclusion

And now we can easily call any method on the main UI thread.

An example where a CGRect struct is used to update the UI components frame;

// Set new frame of a label.
[[NSInvocation invocationWithTarget:someLabel
                           selector:@selector(setFrame:)
                    retainArguments:NO, CGRectMake(40, 40, 200, 100)]
 invokeOnMainThreadWaitUntilDone:NO];

A slightly more complex example, where we send a primitive int, and also waits for and fetches the result from the main thread:

// Query a UITableView for the number of rows in section 2.
NSInvocation* i = [NSInvocation invocationWithTarget:tableView
                                            selector:@selector(numberOfRowsInSection:)
                                     retainArguments:NO, (NSUInteger)2];
// Block this thread until method has been invoked and result is available.
[i invokeOnMainThreadWaitUntilDone:YES];
NSInteger numberOfRows;
[i getReturnValue:&numberOfRows];

Download full source code here: NSInvocation+CWVariableArguments.zip

Update: Example 2 was not 64-bit compatible as David Remahl pointed out to me. Added type cast to fix the error.

Update 2: A new version with some more features and small bug-fixes to BOOL, float and uint16_t types, plus proper unit tests can be downloaded here: CWFoundationAsyncAdditions.zip

The iPad as presented by Apple on the special january 2010 event is a showcase of how Apple has been given this luxury. Not just once but over and over again. Allowing for iterating, and improving with each restart.

The origins

The evolution of the software running the iPad can be traced back along with Steve Jobs himself. With the first Macintosh from 1984 he was one of the many talented people behind ushering the graphical user interface into the world of normal people.

Not entirely by his own choice he founded NeXT in 1985, and got the luxury of starting over, equipped with the experience from the Macintosh project. The lessons learned resulted in the NeXT computers in 1989, a system way ahead of it's time, with NextStep's object oriented frameworks, before OOP had even caught on with the main stream. Remember this was before Windows 3.0.

In late 1996 Apple bought NeXT and all their assets, including Steve Jobs as the CEO. Now the experience learned from developing the NeXT computers and the NextStep operating system could be used again. With the luxury of a reset once again, throwing out anything that did not work, and clean up the parts that worked well. The new operating system rising from the ashes would be named Mac OS X, and the application development frameworks be called Cocoa.

The tech as used today

Cocoa is the primary application development framework for Mac OS X to this day. It is an umbrella framework, containing:

• Foundation - For the non-visual low level components.
• AppKit - For the components to create a desktop application with mouse and keyboard
• Core Data - For managing application data as a graph database.

The application development framework for iPhone OS is called Cocoa Touch. It is basically all the nice parts from Foundation, and since iPhone OS 3.0 also Core Data. But AppKit is missing, instead replaced by UIKit. UIKit are the components needed to create a graphical user interface based on multitouch. Not a dumbed down version of AppKit, but a rewrite that is re-using the experience from AppKit. Refining what works well, removing what did not turn out so well, and adding what could not easily be added to AppKit.

Apple gave themselves the luxury of starting over yet again, not burdened by backward compaitibility. The new form factor of the iPhone can not inspire any realistic hopes for application compatibility with the Mac computers.

Where can this lead?

Mac OS X and the Cocoa frameworks where good from a tech standpoint, and for us nerds. But not ready for prime-time by the average user until at least version 10.2, or 10.3 if you are really honest. Many dismissed the first versions of Mac OS X, while others saw the potential. I see the same thing with iPad and iPhone OS, it will be dismissed for now, and others will see a great potential.

I think that the iPad is Apple's vision for the future of computing. Mice to be replaced by multi-touch. The keyword being multi-touch. A touch device is to a multi-touch device what a black and white TV is to a modern color HD TV. Sure they both display pictures, the basic idea is there, but the execution is on a different level. In 1984 with the first Macintosh a computer mouse was a novelty. Apple want to replace the secondary input of the mouse, with direct input and manipulation using your very fingers. Making the mouse computer mouse a parenthesis in the history of computing.

The iPhone OS is the successor to Mac OS X.

There I said it. There will never be a Mac OX X 11.0, and probably not a Mac OS X 10.8 either. That line of succession is over, the new blood line to reign is the offspring that is iPhone OS. A fresh start, a luxury in our industry, and also a necessity in order to take the great leaps to the future.

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

That means that test cases are written before any production code. Not all tests are written up front, it's rather that a small test is written, then a small piece of production code is written that only allows that test to pass. This is repeated in many small iterations: test, fail, code, pass, test, fail, code, pass...

Many people consider TDD to encourage clean code, simple architectures and a stable system that's actually testable. Plus, it's also fun! We've previously written about various aspects of TDD, but in this tutorial we'll focus on how it works for XCode projects, where you write apps for Mac and iPhone. We will create a simple XCode project, do some special configuration steps and then demonstrate how TDD can be used to write your app. We're going to use OCUnit and its framework SenTestingKit, which nowadays is included with Apple's XCode tools.

Creating the Calculator project

Let's start by creating a new project in XCode. You can pick any template, since we aren't going to touch the generated code. I picked a Window-based iPhone project. Name the project Calculator. Select New Target from the Project menu. Under Cocoa select Unit test Bundle. Call it UnitTests (I've had problems with space in the target name so avoid that) and add it to the project. We now need to change some small settings for this target. Select the UnitTests target and hit Command-I for Info. Select the Build tab and locate Other Linker Flags. Replace Cocoa with Foundation. Also remove the entry for GCC_PREFIX_HEADER.

Now it's time to create your test suite. Create a new group in your project and call it "Test Classes". Add a new File to this group and make sure it's a Cocoa->Objective-C test case class. Name it CalculatorTest.m. Uncheck "Also create CalculatorTest.h" since we don't need a header file. Don't add it to the Calculator target, but check it to be included in UnitTests. Open CalculatorTest.m file and above the @implementation declaration add:

#import <SenTestingKit/SenTestingKit.h>
#import "Calculator.h"
@interface CalculatorTest : SenTestCase
{

}
@end

This is just because we don't want a rather empty header file. All your test classes will look like this.

Following TDD, we should build right away. First make sure that the active target is "UnitTets" and then press the "Build" button. This will not only do a normal build, but also perform some shell script magic and actually execute the unit tests. Now the build fails of course, since Calculator.h can't be found.

So let's add a file which represents production code. Create a new empty Cocoa Touch Objective-C class called Calculator.m (also create the .h file), this is the class that we want to test. Don't forget to check that they should be included in both your targets. Notice that we mix Cocoa and Cocoa Touch, that's is fine - all code is executed on your Mac. Build again, and this time you'll see in the build log that everything built and the test suite was executed, but contained 0 test cases. Let's remedy that.

Writing test cases

Next we want to write our first test case. Open up CalculatorTest.m and add the following method:

-(void)testAdd
{
        Calculator* calculator = [[Calculator alloc] init];
        int result = [calculator add:5 to:6];
}

All methods that start with "test" will be recognized as being a test case, and automatically run when building the target. Try and build and you'll unsurprisingly get the erro "unrecognized selector sent to instance...". That's all good. Let's add the add method to our Calculator class. In Calculator.h add:

-(int)add:(int)a to:(int)b;

Then in Calculator.m add:

-(int)add:(int)a to:(int)b
{
        return 0;
}

That should be enough to let it compile and run, right? Try it out! You'll see that it indeed build and executes the tests.

Now we change the test so that it actually checks that we get the expected value back. We want to "assert" that the returned value is what we expected. Change the test case to look like this:

-(void)testAdd
{
        Calculator* calculator = [[Calculator alloc] init];
        int expected = 11;
        int result = [calculator add:5 to:6];
        STAssertEquals(expected, result,
                @"We expected %d, but it was %d",expected,result);
}

Build and you see that the test runs and fails since our calculator always returns 0 regardless of the input. Change the production code so that it returns a+b and rerun the test. Nice, we have a successful build and our test works! Notice the fast cycle of test, code, fix, rerun. The point of TDD is to write tests and production code in small iterations so that you always have something stable (= the tests pass). If you follow the rules of TDD you'll have a growing amount of test cases and you'll right away know when something breaks.

Let's write one more test. Now we want to add the functionality to allow one number to be divided by another. Start up like before with a new test case like this:

-(void)testDivide
{
        Calculator* calculator = [[Calculator alloc] init];
        float expected = 2.5;
        int result = [calculator divide:5 by:2];
        STAssertEquals(expected, result,
                @"We expected %d, but it was %d",expected,result);
}

You see, this time we expect to get back a float. Add the corresponding divide method to Calculator.h and Calculator.m. If you need help see the full code listing at the end of this article. You might notice that just returning a/b gives you 2.0. Type cast the return value to (float)a/b and you'll be fine. Go ahead when you got it working.

What happens if you try to divide something with zero? Well, why not add a test case for this scenario? If you're into maths you know that the result of this operation is undefined. How do you expect something to be undefined? This is tricky. Start off by just expecting any number and see what you get back. As you see, the float value "inf" is returned. It seems like Objective-C treats the zero as "a value approaching zero" and that will indeed result in infinity in a division. But, hey, that might not be what we want our calculator to do. Let's change the test case to expect an exception to be raised instead:

-(void)testDivideByZero
{
        Calculator* calculator = [[Calculator alloc] init];
        STAssertThrows([calculator divide:5 by:0],
                @"We expected an exception to be raised when dividing by 0");
}

Build and notice the error message when no exception was raised. Now change the production code to something like this:

-(float)divide:(int)a by:(int)b
{
        float result =  (float)a/b;
        if (result==INFINITY) {
                [NSException raise:@"Cannot divide by zero!"
                            format:@"Not possible to divide %d with %d", a,b];
        }
        return result;
}

Rerun and smile as the test passes! There are many different variants of asserts you can do with SenTestingKit. Compare objects with STAssertEqualObjects. STAssertTrue to check that a returned boolean is true. Open up SentTestCase_Macros.h if you want to see what you can play around with. By the way. You might have tried using NSLog in your test cases (just to experiment). This is nothing you would do in real life, as you want all necessary information in the fail message and output nothing if the test passes. Anyway, since the tests are actually run using a separate shell script for the UnitTest target you won't see the log in your console as usual. Instead check the build log and click the "text" icon to the right for the "Run test suite" step.

Wrapping up

Finally, if you look at your test class you might notice that we're allocating a new Calculator for every test case, and we never release them. That's no good. Luckily there are setUp and tearDown methods that will be launched automatically before and after each test case. Change your implementation to look like this (this is the final listing):

#import <SenTestingKit/SenTestingKit.h>
#import "Calculator.h"
@interface CalculatorTest : SenTestCase
{
        Calculator* calculator;
}
@end

@implementation CalculatorTest

- (void) setUp
{
        calculator = [[Calculator alloc] init];
}

-(void)tearDown
{
        [calculator release];
}

-(void)testAdd
{
        int expected = 11;
        int result = [calculator add:5 to:6];
        STAssertEquals(expected, result,
                @"We expected %d, but it was %d",expected,result);
}

-(void)testDivide
{
        float expected = 2.5;
        float result = [calculator divide:5 by:2];
        STAssertEquals(expected, result,
                @"We expected %f, but it was %f",expected,result);
}

-(void)testDivideByZero
{
        STAssertThrows([calculator divide:5 by:0],
                @"We expected an exception to be raised when dividing by 0");
}
@end

For completeness, here's the listing for Calculator.h:

#import 

@interface Calculator : NSObject {

}

-(int)add:(int)a to:(int)b;
-(float)divide:(int)a by:(int)b;

@end

and for Calculator.m:

#import "Calculator.h"

@implementation Calculator

-(int)add:(int)a to:(int)b
{
        return a+b;
}

-(float)divide:(int)a by:(int)b
{
        float result =  (float)a/b;
        if (result==INFINITY) {
                [NSException raise:@"Cannot divide by zero!"
                            format:@"Not possible to divide %d with %d", a,b];
        }
        return result;
}

@end

Next blog post we'll see how to automate the running of test cases on a build server called Hudson!

Google Translate to the rescue

Turns out that Google Translate has a nice AJAX API, feed it a URL request and get a JSON response. Admittedly the translations are not always perfect, even quite humorous at times, but good enough if you provide the user a warning.

So let us create a sibling to NSLocalizedString() called CWTranslatedString(). It should take two arguments; the string to translate, and the source language ISO code. We should also be able to get the users currently selected language, that will be used as the destination language when translating. So this is our header:

NSString* CWCurrentLanguageIdentifier();
NSString* CWTranslatedString(NSString* string, NSString* sourceLanguageIdentifier);

Currently your iPhone application must be terminated in order for the user to change the language. And even when Apple adds multitasking for third-party apps we can assume the user do not go about and switch languages too often, so we let CWCurrentLanguageIdentifier() cache the language code:

NSString* CWCurrentLanguageIdentifier() {
    static NSString* currentLanguage = nil;
    if (currentLanguage == nil) {
        NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
        NSArray* languages = [defaults objectForKey:@"AppleLanguages"];
        currentLanguage = [[languages objectAtIndex:0] retain];
    }
    return currentLanguage;
}

Now for the CWTranslatedString() function. The JSON response from Google Translate is well formatted with no line breaks, so let's not bother with a proper JSON-parser. We can use a simple NSScanner, and just return the source string for any unexpected result. We also short circuit and return the source string if the source and dest language as equal.

NSString* CWTranslatedString(NSString* string, NSString* sourceLanguageIdentifier) {
    static NSString* queryURL = @"http://ajax.googleapis.com/ajax/services/language/translate?v=1.0&q=%@&langpair=%@%%7C%@";
    if (sourceLanguageIdentifier == nil) {
        sourceLanguageIdentifier = @"en";
    }
    if ([sourceLanguageIdentifier isEqual:CWCurrentLanguageIdentifier()] || string == nil) {
        return string;
    }
    NSString* escapedString = [string stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    NSString* query = [NSString stringWithFormat:queryURL,
                       escapedString, sourceLanguageIdentifier, CWCurrentLanguageIdentifier()];
    NSString* response = [NSString stringWithContentsOfURL:[NSURL URLWithString:query]
                                                  encoding:NSUTF8StringEncoding error:NULL];
    if (response == nil) {
        return string;
    }
    NSScanner* scanner = [NSScanner scannerWithString:response];
    if (![scanner scanUpToString:@"\"translatedText\":\"" intoString:NULL]) {
        return string;
    }
    if (![scanner scanString:@"\"translatedText\":\"" intoString:NULL]) {
        return string;
    }
    NSString* result = nil;
    if (![scanner scanUpToString:@"\"}" intoString:&result]) {
        return string;
    }
    return result;
}

And that is it. Not perfect, but nice to have.

Creating a perfect Default.png is impossible, especially if you have different setup of navigation and tab bars in different parts of your app. And even harder to adjust for the different sizes of the status bar. With the advent of tethering the size of the status bar is even more sure to be random at startup. This adds to a small jerk, or ugly jump of the user interface at start up.

Create a smooth startup

The easiest way to counter this small jerk is to let your user interface fade in. It is pleasing to the eye, and easy to do. So easy that this blog post pretty much ends after a small code block you can cut&paste into any of your projects.

If you create your UI using Interface Builder, or create it in code, you still have an implementation of applicationDidFinishLaunching: that ends like this:

-(void)applicationDidFinishLaunching:(UIApplication*)application;
{
// ...more code...
  [window makeKeyAndVisible];
}

This is where we will add our own code that will slide in a new view, above the root view, mimicking the Default.png look. This view is then quickly faded out and removed, creating the appearance of fading in our real user interface.

-(void)applicationDidFinishLaunching:(UIApplication*)application;
{
// ...more code...
  UIImage* backImage = [UIImage imageNamed:@"Default.png"];
  UIView* backView = [[UIImageView alloc] initWithImage:backImage];
  backView.frame = window.bounds;
  [window addSubview:backView];
  [UIView beginAnimations:@"CWFadeIn" context:(void*)backView];
  [UIView setAnimationDelegate:self];
  [UIView setAnimationDidStopSelector:
      @selector(animationDidStop:finished:context:)];
  [UIView setAnimationDuration:0.5f];
  backView.alpha = 0;
  [UIView commitAnimations];
  [window makeKeyAndVisible];
}
 
-(void)animationDidStop:(NSString*)animationID finished:(NSNumber*)finished
    context:(void*)context
{
  UIView* backView = (UIView*)context;
  [backView removeFromSuperview];
  [backView release];
}

And that is it, instant better first impression.

Any sane developer avoids premature optimization, so the task we later want to execute in a separate thread is almost always available in our current context. I am sure all Java-developers has seen something like this:

 new Thread() {
    public void run() {
        OuterClass.this.someMethod(arg);
    }
}.start();

And often an anonymous Runnable is involved as well. Executing a task in a separate thread with Cocoa and Cocoa Touch is ridiculously easy given the dynamic nature of Objective-C. This is done with Cocoa with this one-liner:

[self performSelectorInBackground:@selector(someMethod:) withObject:arg];

The performSelectorInBackground:withObject: is a companion method for performSelector:withObject:, and will create a new NSThread instance, and execute the specified method there. There are more companions such as performSelectorOnMainThread:withObject: that is used to execute a method on the main UI thread.

This easy access to executing in new threads often can result in code that spawns too many threads. In Cocoa on Mac OS X this is seldom a problem, not for Cocoa Touch applications under development when running in the iPhone simulator either. But on the more resource constrained iPhone and iPod Touch devices this will be a problem. Spawning a dozen background threads to download images will bring the iPhone OS to a staggering mess.

Update: I have removed CWSelectorOperation from this post, since using NSInvocationOperation is preferred.

Operation Queues

The solution is to use a NSOperationQueue, that as the name implies handles a queue of operations. The max number of concurrent operations can be set, as well as dependencies and priority. The downside is that NSOperationQueue can only handle instances of NSOperation.

NSOperation is an abstract class, where you as a developer override the main method to execute your task. In short NSOperation is programatically the equivalent of the Java Runnable interface. It is even worse as Objective-C do not support anonymous classes, so we will be required to actually implement our queued tasks as separate classes.

Not as neat as one would like, and definitely not even very Cocoa-like.

What is Missing

As a Cocoa developer I expect that executing a task on background queue, would be just as easy as executing a task on a background thread. The expected needed code is something like this:

[self performSelectorOnBackgroundQueue:@selector(someMethod:) withObject:arg];

To make this work we need:

1. A category on NSObject to add performSelectorOnBackgroundQueue:withObject:.
2. Implement a concrete subclass of NSOperation to support execution of a selector on any target.Use NSInvocationOperation to perform selector.
3. A category on NSOperationQueue to add a shared operation queue.

This is in the order of how a client developer would see it (most developers will only care for the NSObject category). For us this is the reverse order when implement this functionality.

A Shared Operation Queue

Cocoa and Cocoa Touch used many shared instances, for example a shared UIAccelerometer instance, and a shared NSURLCache instance. So this pattern of single point dependency injection is common in Cocoa and works very well. So let us follow suit by introducing an interface like this:

@interface NSOperationQueue (CWSharedQueue)
+(NSOperationQueue*)sharedOperationQueue;
+(void)setSharedOperationQueue:(NSOperationQueue*)operationQueue;
@end

The shared operation queue will be created lazily if it do not exist, and the client can easily swap it out at startup if needed. The implementation is very small, and a good example of how we should implement class variables with proper memory handling.

@implementation NSOperationQueue (CWSharedQueue)
 
static NSOperationQueue* cw_sharedOperationQueue = nil;
 
+(NSOperationQueue*)sharedOperationQueue;
{
  if (cw_sharedOperationQueue == nil) {
    cw_sharedOperationQueue = [[NSOperationQueue alloc] init];
    [cw_sharedOperationQueue setMaxConcurrentOperationCount:3];
  }
  return cw_sharedOperationQueue;
}
 
+(void)setSharedOperationQueue:(NSOperationQueue*)operationQueue;
{
  if (operationQueue != cw_sharedOperationQueue) {
    [cw_sharedOperationQueue release];
    cw_sharedOperationQueue = [operationQueue retain];
  }
}
 
@end

Enter CWSelectorOperation

Update: CWSelectorOperation is no longer needed, our implementation instead uses NSInvocationOperation.

Wrapping up NSObject

And at last we reach the category on NSObject, that is what we initially wanted, and what 95% of all use cases will be limited to.

@interface NSObject (CWSharedQueue)
 
-(NSInvocationOperation*)performSelectorInBackgroundQueue:(SEL)aSelector
    withObject:(id)arg;
-(NSInvocationOperation*)performSelectorInBackgroundQueue:(SEL)aSelector
    withObject:(id)arg dependencies:(NSArray*)dependencies
    priority:(NSOperationQueuePriority)priority;
 
@end

Most performSelector* methods do not have a return value, I have chosen to return the resulting NSInvocationOperation so that it can be used to setup dependencies for future queued operations. I have also added a second method performSelectorInBackgroundQueue:withObject:dependencies:priority: so that such dependencies can easily be setup, as well as prioritisation of operations.

The actual implementation is a simple wrapper around the NSInvocationOperation class, and category on NSOperationQueue that we implemented above:

@implementation NSObject (CWSharedQueue)
 
-(NSInvocationOperation*)performSelectorInBackgroundQueue:(SEL)aSelector
    withObject:(id)arg;
{
  NSInvocationOperation* operation = [[NSInvocationOperation alloc]
      initWithTarget:self selector:aSelector object:arg];
  [[NSOperationQueue sharedOperationQueue] addOperation:operation];
  return [operation autorelease];
}
 
-(NSInvocationOperation*)performSelectorInBackgroundQueue:(SEL)aSelector
    withObject:(id)arg dependencies:(NSArray*)dependencies
    priority:(NSOperationQueuePriority)priority;
{
  NSInvocationOperation* operation = [[NSInvocationOperation alloc]
      initWithTarget:self selector:aSelector object:arg];
  [operation setQueuePriority:priority];
  for (NSOperation* dependency in dependencies) {
    [operation addDependency:dependency];
  }
  [[NSOperationQueue sharedOperationQueue] addOperation:operation];
  return [operation autorelease];
}
 
@end

And that is it, if you want to avoid cut and paste of all this code to your own project just download the source code here. And happy concurrent hacking.

Download the older source code here, with a concrete subclass of NSOperation called CWSelectorOperation.

Or are regular expressions really missing? Regular expressions can be used with NSPredicate that is part of Core Data, available since Mac OS X 10.4 and officially announced for iPhone OS 3.0. Cocoa's WebView and the equivalent UIWebView in Cocoa Touch both support JavaScript with regular expressions. So there sure is regular expressions available on the platforms, but how do you make it available for your own code?

An Ugly Solution

You can actually get access to the regular expression engine through JavaScript, unfortunately this requires a roundtrip through WebKit. On an iPhone this means you have to use an off-screen instance of UIWebView, and delegate execution of regular expression to it.

The complexity of an off-screen WebView or UIWebView could be hidden by a utility class. But the extra glue code needed to make something useful out of the single method stringByEvaluatingJavaScripFromString:, would be allot.

What Apple Recommends

For most problems the official stance is correct; do not use regular expressions. Instead use NSScanner, that is perfect for sequentially parse texts. It is very fast and can substitute any regular expressions that only relies on:

• Character sets
• Exact string matches
• Numerical matches
• Uniform input text

These conditions hold true to 95% of everything regular expressions is ever used for. For the other 5%, Apple leaves you to fend for your own.

Other Solutions

PCRE compiles perfectly with Cocoa, since it is written in C, one of the many advantages of Objective-C. PCRE is very capable, and almost a standard, but also very large. For an iPhone application the PCRE implementation could end up as the majority of your executables file-size. If this is something you can live with, then the open source RegexKit framework wraps PCRE in Cocoa and Cocoa Touch friendly Objective-C.

Another regular expressions framework is OgreKit. The advantage of OgreKit is full unicode support, with the same disadvantage of size. And the fact that the documentation is in Japanese.

A Pretty Solution

It turns out that Mac OS X for years, and iPhone OS since inception, has been shipped with a perfectly good regular expressions engine. This engine is based on the ICU specification, so it works perfectly with unicode and is well on par with PCRE for functionality. This framework is simply called ICU Core, and has a C interface. But for a Cocoa programmers the C interface is not nice enough, and thankfully John Engelhart has done this work for us, with RegexKitLite. RegexKitLite is a little brother to RegexKit that wrapps ICU Core instead of PCRE.

RegexKitLite is published under BSD license, and is simply two files you add to your project, fully compatible with all available versions of both Mac OS X and iPhone OS. The tricky part is that ICU Core is not a public API officially supported by Apple, even though it has existed unchanged for years. Good news is that using ICU Core is not a show stopper for publishing on the iPhone App Store, application out there already uses it, both well known and not so well known.

Setting Up RegexKitLite

1. Download the latest version from the sourceforge webpage, or SVN.
2. Add RegexKitLite.h and RegexKitLite.m to your project.
3. Link your project against ICU Core, by adding the linker flag -licucore to Other Linker Flags under your projects build settings.

Optionally you can also add the documentation to Xcode with these easy steps:

1. Open Help -> Documtantion.
2. Press the Gears button in the lower left corder, and select New Subscription....
3. Enter feed://regexkit.sourceforge.net/RegexKitLiteDocSets.atom as URL.

Using RegexKitLite

This post is not a tutorial on regular expressions, but a tutorial on a partical API for executing regular expressions. If you want to learn more about regular expressions themselves I would recomend you look at Regular Expressions.info.

RegexKitLite provides it's functionality as categories on NSString and NSMutableString. This way using regular expressions with Cocoa is just as easy and normal string manipulation. This is best described using examples.

A simple example that normalizes a text with single white spaces, kind of like how a HML renderer would do, so this is handy when scraping web pages:

NSString* source = @"One\t Two \nThree ";
NSString* result = [source stringByReplacingOccurancesOfRegex:@"\\s+"
    withString:@" "];
NSLog(source);
NSLog(result);

Or you can split a text, such as semi-colon delimeted data:

NSString* source = @"Test;12;Y";
NSArray* columns = [source componentsSeparatedByRegex:@";\\s*"];
NSLog([columns description]);

And you can extract more complex data using capture groups:

NSString* source = @"<foo no=\"12\">Name</foo>";
NSString* regex = @"<foo no=\"(.+?)\">(.*?)</foo>";
int no = [[source stringByMatching:regex capture:1] intValue];
NSString* data = [source stringByMatching:regex capture:2];
NSLog(@"no: %d data: %@", no, data);

This may look like it could be slow to perform matches on the same regular expression twice, but it is not. RegexKitLite is very smart, and will cache your previous matches for very high performance.

RegexKitLite is a very capable, and also much active open source project, with version 3.0 as a release candidate in SVN. Use it, and use it well.

Introduction

Just recently, iPhone sales figures surpassed all windows mobile phones combined and in several markets the iPhone has been a top selling phone model. Together with the launch of App Store, Apple has managed to create a service delivery platform that attracts not only the hardcore users, but also the average Joe. A testament to this is the fact that App Store has had over one billion application downloads with over 50 000 applications available. This large potential customer base, combined with the advantage of having virtually no device fragmentation, makes it quite an attractive platform for mobile application developers. The business model is also lucrative, with Apple offering 70% of revenues from the store to instantly go to the seller of the app without having to pay for distribution or anything else than a one time fee. In this regard, the iPhone has certainly helped Apple put the Objective-C language in the limelight.

For the developer, the transition from higher level languages such as Java may
not be so simple as Objective-C has quite a unique syntax. The goal of this
article is to remedy that by going through the main concepts of Objective-C
from a Java perspective. Hopefully this will help you to get a quicker start in your
iPhone development. You should however be aware that it is equally important
to understand how to use the iPhone’s application frameworks in order to create
applications, this article only scratches the surface of the language you will use.

Objective-C from a Java perspective

If you are used to both working in C/C++ and Java you might soon recognize
Objective-C as a middle-ground language, meaning that it provides lower-level
mechanisms than Java while being a more manageable and higher-level language
than C/C++. The language is a strict superset of C, which means it’s possible
to write and compile normal C code using the Objective-C compiler. We also
use pointers (signified in code with an asterisk, *) to objects and not references,
like in Java. For object orientation Objective-C uses a syntax similar to that of
Smalltalk, which might take a little time to get used to if you haven’t seen it
before. Objective-C is a highly dynamic language, much like Ruby and Python,
where it’s possible to change the behavior at runtime. The compiler is quite
forgiving and before getting used to this you will likely discover more problems
during runtime than when using Java.

While some of the features in Objective-C are unique, many of them are
similar to those of Java only named differently. In order to ease the transition,
we will use Java terminology as much as possible and step by step build up a
small example in Objective-C that covers the basic features. In some cases the
examples will keep code from previous examples and in some only the change
will be presented to save space. Regardless, the new code is always in bold font.
Let’s get started.

Classes

Unlike Java which uses a single .java file, Objective-C separates class declaration
and definition into two files: .h and .m. The .h file is called the interface, which
shouldn’t be confused with Java interfaces (more on this later). Most importantly,
the interface file lists the methods and member variables that the class contains.
A minimal compilable .h file would look like this:

@interface MyClass {
}
@end

This piece of code simply declares an empty interface named MyClass which
you preferably should put in a file named “MyClass.h”. The space between the
“{}” signs is where we will put our member variable declarations and the space
right before the @end tag is where method declarations go. The .m file looks like
this:

#import ”MyClass.h”
@implementation MyClass
@end

It’s between the lines starting with @implementation and @end that we will
put our actual method implementations. Notice that there are no “{}” signs
since member variables are declared in the interface file. This minimal example
obviously doesn’t do much but it will compile and it it gives us something to
start with.

Similarly to Java, Objective-C has a superclass that most classes inherit from:
NSObject. But while we in Java are used to an implicit inheritance from this
class, we must here explicitly declare this in our .h files. To inherit a class, we
simply add a colon after the class name in our .h file followed by the name of
the class we wish to inherit:

@interface MyClass : NSObject {
} 

Conceptually, NSObject has similarities to java.lang.Object. But it is also more
powerful in the sense that it provides some features that are only possible with the
reflection API in Java. As an example, NSObject allows you to take advantage of the
runtime and determine which methods are implemented. It also contains methods
that are needed for proper memory management such as retain and release which
we will look closer at later on.

Naming conventions

Objective-C does not provide any type of namespace functionality like Java does
with packages. Instead, to avoid name clashes, the best way is to use prefixes.
You will see this used heavily throughout the official APIs. NSString (a Foundation
class) and UITextField (of the UIKit framework) are two examples. This makes
it easy to see which classes are written by Apple. We recommend that you use
an abbreviation of your company as two upper case characters and prefix your
classes with that. If your company name is Acme, you could use AC as a prefix.

When programming in Objective-C it is advisable to follow the guidelines from
Apple about naming classes, methods and other building blocks. Typically we
want naming to be very expressive and also highly consistent. This contrasts
Java where, for example, some collection classes use addElement(...) and
sometimes add(...) to add new objects. Consistency makes it a lot easier to
learn the frameworks because they follow the same conventions. We also want
to be expressive and really explain in naming what the class or method does.
Java enforces conventions through JavaBeans standards, but Apple goes far
beyond that. For example, ACPeopleTableViewController would be a suitable
name for a Controller (MVC pattern) class that controls a TableView (standard
component) which contains People. When it comes to methods getters should
not be prefixed by “get” but rather have similar name as the property they are
fetching. If there is a property called defaultColor then the method to get it
is called -(NSColor*)color; not getColor();. There are many other naming
conventions and you’ll rather quickly get used to the standard ones.

Access Control

There are three types of access control you can set on your member variables:
private, protected, and public. They have the same effect as in Java. The syntax
for doing this is a bit different tough. Let’s add two member variables to our
header file and make these private:

@interface MyClass
{
    @private
    int firstNumber, secondNumber;
}
@end 

We simply use the compiler directive “@private” and everything beneath it will
be private until either a “}” or another directive is found.

So how do I make my instance methods private? The answer is that you don’t
have to worry about that, since the language doesn’t formally support changing
the access type on methods. All methods are public!

Methods

The equivalent of calling methods in Java is defined as sending messages in
Objective-C. This is one of the big differences between the languages. On the
surface it may appear as we are doing the same thing only with different syntax:

Java:         myObject.doSomething(myParameter);
Objective-C:  [myObject doSomething:myParameter]; 

But there is in fact a big underlying difference. The doSomething method in
the Java example must exist at compile time or the compilation will fail. The
same does not apply in the Objective-C case. The notion of sending a message
to an object implies that we will send something regardless of whether there is
a receiver or not and how the message together with parameters are handled is
determined at runtime.

Now let’s declare a method in our header file that will add two numbers:

@interface MyClass {
  @private
  int firstNumber, secondNumber;
}
-(int)add:(int)a to:(int)b; 

The syntax may seem confusing at first but the elegance is displayed once the
method is used to pass a message:

[myObject add:5 to: 2];

Notice the readability of that method. Instead of guessing or reading
documentation for method signatures we know right away which parameter
goes where. Now lets add the implementation in the .m file:

-(int)add:(int)a to:(int)b
{
    return b + a;
} 

Constructors

Objective-C doesn’t have the same concept of constructors as Java. Instead,
object creation is divided into two parts: allocation and initialization. There is
no special syntax reserved for object creation (i.e. new in Java). The methods
handling this are regular methods and are named alloc and init respectively. The
two calls are usually nested to allocate and initialize an object on a single line:

MyClass *myObject = [[MyClass alloc] init];

Notice the star in front of myObject. This is regular C syntax for declaring
a pointer. Now pointers are usually something that Java people like to avoid
since it can be the source of all kinds of troubles. Fortunately, if you stick to
using Objective-C you almost never have to use the star or any dereference
mechanism when actually using the objects. Just keep in mind that it has to be
there in the declaration.

The alloc method is a static method that resides in NSObject and should never
be overridden. It allocates memory and returns a new instance of the receiving
class. The init method on the other hand is an instance method and should be
overwritten. In fact, the default implementation does nothing but return itself.
The simplest form of init implementation usually looks like this:

- (id)init
 {
     if ((self = [super init])) {
         /* class-specific initialization goes here */
 }
     return self;
 } 

We always call the parent’s init method and make sure we get something back.
Then we execute our initialize code and return self which is the Objective-C
equivalent of Java’s this.

Just like you often have multiple constructors in Java, you will likely have
more than one initializer in your Objective-C class that takes different types of
arguments. According to convention you should start the name of these methods
with “initWith”. Here’s an initializer that takes two numbers as parameters:

- (id) initWithNumberA:(int)numberA numberB:(int)numberB
 {
     if ((self = [super init])) {
        firstNumber = numberA;
        secondNumber = numberB;
     }
     return self;
 } 

The convention also says that only one initializer should make the call to super.
It is often convenient to do this in the initializer with the most arguments, and
let the other initializers call that one. Let’s change the first initializer so it looks
like this:

- (id)init
 {
     return [self initWithNumberA:0 numberB:0];
 } 

Protocols

Protocols are essentially the same thing as Java interfaces but with added flexibility.
A class is not always required to implement all methods just to conform to the
protocol, some can be marked as optional. Furthermore, a class can conform to a
protocol by just implementing the required methods, even if it hasn’t explicitly
declared that it is implementing it. Let’s create our own protocol to indicate that
the example class can calculate something, and suitably call it Calculator. We
enter the following in a new .h named CalculatorProtocol.h.

@protocol Calculator
@required
-(int)calculate;
@end 

The protocol declaration is pretty straight forward. The @required attribute
signifies that the method is mandatory to implement. We could also have written
@optional if we don’t want to force an implementation. It’s also possible to mix
required and optional methods. Now to show that our example class conforms
to this protocol we first change the .h file:

#import ”CalculatorProtocol.h”
@interface MyClass : NSObject 
{ ... 

And then we add the implementation of our getCalculation method in the .m
file:

-(int)calculate
{
    return [self add:firstNumber to:secondNumber];
} 

Where’s my garbage collector?

Unlike Java and desktop Objective-C development there is no garbage collector
available when creating applications for the iPhone. The reason for this is to
allow the best possible performance. This means that you will have to clean up
after yourself manually. Fortunately, the NSObject class contains functionality
to make manual memory management easier. Every object whose class inherits
from NSObject contains a so called retain count which is used to indicate how
many other objects that are using or “owning” it. If you own an object, you are
also responsible for releasing it when you are done, at which point the retain
count willl go down. When the retain count reaches 0 the system will assume it’s
safe to deallocate the memory for your object. So when is the object considered
“used”, i.e. when does the retain count go up? First of all, the retain count will
implicitly increase if you you create the object yourself by using a method name
beginning with “alloc”, “new” or contains “copy”. Secondly, you must explicitly
add one to the retain counter by calling the NSObject method “retain” whenever
you wish to take ownership of an object that you receive by other means, i.e. as
a parameter or from a getter method.

To reduce the retain count, or say that you no longer need the object in question,
you use [myObject autorelease] or [myObject release], where autorelease
signifies that the object should release later. To show how this works we add the
following to our example:

-(void) setName: (NSString*) newName
{
    [newName retain]; // get ownership, increases retain count for newName
    [name release]; // in case name is already set, we don’t need it anymore
    name = newName; // set name to the new value
} 

We need to retain newName in case we are passing the same object that is
currently assigned to name, or it might be deallocated. When releasing name it’s
possible that it’s not set, but it’s fine to call release on a nil object.

There are situations when you want to autorelease objects. For instance, if you
have a method that returns a NSString that is created inside the method:

//PROBLEMATIC CODE
-(NSString*)formattedName
{
  NSString *formatted = [[NSString alloc] initWithFormat:@”Name: %@”,name];
  [formatted release];
  return formatted;
} 

If you run this code there’ll be problems. The formatted variable will be released
before it’s returned which means that whoever requested the NSString will get
a pointer to a freed object. The solution is to replace release with autorelease.
Objects that are sent autorelease will be added to an autorelease pool. When
the pool is deallocated release is sent to all objects it contains, including our NSString. The pool is created before events and deallocated when the event has
been handled. That way the formatted variable won’t be deallocated right away.

-(NSString*)formattedName
{
  NSString *formatted = [[NSString alloc] initWithFormat:@”Name: %@”,name];
  [formatted autorelease];
  return formatted;
}

All objects that are not created using alloc, new or copy are automatically added
to the current autorelease pool. So if you don’t want to loose those objects you
need to retain them.

Many objects have convenience methods that return autoreleased objects, so
the easiest solution to our problem would be to avoid the alloc and instead use
a convenience method:

-(NSString*)formattedName
{
  return [NSString stringWithFormat:@”Name: %@”, name];
} 

Manual memory management is usually one of the tougher parts to get used to
when coming from a “friendlier” language such as Java. It is important however
to get a good understanding in this area as it often can be the source of nasty
bugs.

Conclusions

That concludes our example and short introduction to Objective-C, the
language you need to master - or at least learn to use - in order to write great
iPhone applications. The syntax and some concepts differ a bit from Java, but
it’s relatively easy to pick up and get started with. There are many other areas
we haven’t even touched upon, such as the frameworks and tools provided by
Apple. Fortunately there’s a wealth of information available online at the iPhone
Dev Center, where you can read API references, download sample code, watch
tutorial guides and videos as well as discuss with other developers. In order to
develop applications for iPhone you need a Mac computer running Mac OS X
and register as a developer (for free) on Apple’s website. Good luck!

Christian Hedin
Stefan Li

Originally published in JayView.

NSArray admits to sorts being a slow operation, and adds a method pair for comultive sorts using hints. This way the operation is done in O(P*LOG(P)+N) time, instead of O(N*LOG(N)). Where N is number of elements, and P is number of additions and deletions since the last sort. Unfortunately that do not work on NSMutableArray. So even if memory consumption will not hit the roof, release retain cycles will take it's toll.

So why not add methods to find the insertion points, and insert new objects into already sorted NSArray and NSMutableArray object? Best case for inserting single elements should be O(LOG(N)^2), so lets hit that target. And on the way there, we will learn how to;

• Add functionality to standard classes using categories.
• Implement high performant Obj-C code for tight loops.

New Categories on NSArray and NSMutableArray

This will become a bit complex on the inside, but the public front should be as simple as this:

#import <Foundation/Foundation.h>
 
@interface NSArray (CWSortedInsert)
 
-(NSUInteger)indexForInsertingObject:(id)anObject
    sortedUsingfunction:(NSInteger (*)(id, id, void *))compare
    context:(void*)context;
-(NSUInteger)indexForInsertingObject:(id)anObject
    sortedUsingSelector:(SEL)aSelector;
-(NSUInteger)indexForInsertingObject:(id)anObject
    sortedUsingDescriptors:(NSArray*)descriptors;
 
@end
 
@interface NSMutableArray (CWSortedInsert)
 
-(void)insertObject:(id)anObject
    sortedUsingfunction:(NSInteger (*)(id, id, void *))compare
    context:(void*)context;
-(void)insertObject:(id)anObject sortedUsingSelector:(SEL)aSelector;
-(void)insertObject:(id)anObject sortedUsingDescriptors:(NSArray*)descriptors;
 
@end

Base Implementation

We want to follow suit with NSArray and NSMutableArray, so we too shall support inserts based on functions, selectors, and an array of sort descriptors. In practice we only need to implement indexForInsertingObject:sortedUsingfunction:context:, the other methods can use this one, each with a private compare method of their own. So we begin by implementing this method.

#import "NSArray+CWSortedInsert.h"
#import <objc/runtime.h>
 
@implementation NSArray (CWSortedInsert)
 
-(NSUInteger)indexForInsertingObject:(id)anObject
    sortedUsingfunction:(NSInteger (*)(id, id, void *))compare
    context:(void*)context;
{
  NSUInteger index = 0;
  NSUInteger topIndex = [self count];
  IMP objectAtIndexImp = [self methodForSelector:@selector(objectAtIndex:)];
  while (index < topIndex) {
    NSUInteger midIndex = (index + topIndex) / 2;
    id testObject = objectAtIndexImp(self, @selector(objectAtIndex:), midIndex);
    if (compare(anObject, testObject, context) < 0) {
      index = midIndex + 1;
    } else {
      topIndex = midIndex;
    }
  }
  return index;
}
 
// More code here...
 
@end

The Objective-C runtime header is included so we can go around the usual method dispatch, and instead use the method implementations as function pointers. In most cases this is a neglectable optimization, for this case we will be the bottle neck since we are intended to be the low level API.

The algorithm is a simple binary search, and we have a worst case O(LOG(N)^2) time for index search. Using this for implementing the sibling method in NSMutableArray is as simple as this:

@implementation NSMutableArray (CWSortedInsert)
 
-(void)insertObject:(id)anObject
    sortedUsingfunction:(NSInteger (*)(id, id, void *))compare
    context:(void*)context;
{
  NSUInteger index = [self indexForInsertingObject:anObject
      sortedUsingfunction:compare context:context];
  [self insertObject:anObject atIndex:index];
}
 
// More code here...
 
@end

Sort Using Selector

With functions in place, writing a utility compare function that uses selectors, and can be used with our indexForInsertingObject:sortedUsingfunction:context: method is a breeze.

static NSComparisonResult cw_SelectorCompare(id a, id b, void* aSelector) {
  return (NSComparisonResult)objc_msgSend(a, (SEL)aSelector, b);
}
 
-(NSUInteger)indexForInsertingObject:(id)anObject
    sortedUsingSelector:(SEL)aSelector;
{
  return [self indexForInsertingObject:anObject
      sortedUsingfunction:&cw_SelectorCompare context:aSelector];
}

Notice that objc_msgSend(id, SEL, ...) is used instead of the performSelector:withObject: method. This is a small performance improvement, as what performSelector:withObject: do behind the scene is just a call to objc_msgSend() anyway. We have removed one method invokation per compare.

Sort Using Sort Descriptors

Or rather sort with an array or NSSortDescriptor objects. This will be the least performant, but also the most flexible sort. An array of sort descriptors is used because we want to be able to sort using several criteria, one sort descriptor per criteria. For example when sorting on last name, then first name, or even more complex sorts.

A NSSortDescriptor is initialized with a key, sort order (ascending or descending) and optionally a selector to do the comparison with, by default compare:. There are quite a few method invokations involved, and it will be good for performance to avoid as many as we can.

Just as performSelector:withObject: uses objc_msgSend() behind the scene, so do objc_msgSend use a function pointer internally. After doing a hash-table lookup with the selector as key that is. This look-up is cached and very fast, but avoiding it all together is always faster. So let us fetch those when the category is first loaded, and do our calls straight through the functions pointers avoiding at least two or more function calls for each compare operation.

static IMP cw_compareObjectToObjectImp = NULL;
static IMP cw_ascendingImp = NULL;
 
+(void)initialize;
{
  cw_compareObjectToObjectImp = [NSSortDescriptor
      instanceMethodForSelector:@selector(compareObject:toObject:)];
  cw_ascendingImp = [NSSortDescriptor
      instanceMethodForSelector:@selector(ascending)];
}

The class method inilialize is kind of magic, it is called once for each class and category, when the class or category is loaded into the run-time. It is the Obj-C equivalent of static initializers.

With the function pointers to the hot-spot method implementations in hand, here is the fast implementation:

static NSComparisonResult cw_DescriptorCompare(id a, id b, void* descriptors) {
  NSComparisonResult result = NSOrderedSame;
  for (NSSortDescriptor* sortDescriptor in (NSArray*)descriptors) {
    result = (NSComparisonResult)cw_compareObjectToObjectImp(sortDescriptor,
        @selector(compareObject:toObject:), a, b);
    if (result != NSOrderedSame) {
      if (!cw_ascendingImp(sortDescriptor, @selector(ascending))) {
      	result = 0 - result;
      }
      break;
    }
  }
  return result;
}
 
-(NSUInteger)indexForInsertingObject:(id)anObject
    sortedUsingDescriptors:(NSArray*)descriptors;
{
  return [self indexForInsertingObject:anObject
      sortedUsingfunction:&cw_DescriptorCompare context:descriptors];
}

Conclusions

The fact that Objective-C is a strict superset of C have some good benefits. The obvious one is that your Obj-C code is both source-code and binary compatible with the vast collection of code that has been written in C over the past 30+ years.

The second benefit is that when performance is needed, Obj-C gives us as developers full access to the internals of the dynamic run-time.

But best of all, most developers never need to care. They can, blissfully unaware, reap the benefits of the performance tuning under the hood. Tuning by both Apple and considerate third party library developers willing to go the extra mile (or a few metres at least).

The code is released under BSD license, and works on both Mac OS X and iPhone OS. You can download it here.

Here I will use a small example that is easy and natural for Ruby, but equally hard for Java and Obj-C. That way both languages stand on equal grounds for comparison.

This article explains the Objective-C parts in detail, and Java in brief. It is assumed that you as a reader understands Java well. Many concept in Java and Obj-C are identical, but with different names. I will be using the Java names in Java context, and the Obj-C names in Obj-C context. Therefore; memorize this short glossary:

Java      -> Obj-C
interface -> protocol
this      -> self
null      -> nil

Cocoa relies heavily on features in the Obj-C langauges, so even if Cocoa apps can be written, and is so supported by Apple, in Ruby or Python; Obj-C is the only language that can tap into the full power of Cocoa.

Cocoa on Mac OS X is an umbrella framework for Foundation and AppKit. Cocoa Touch on iPhone OS is an umbrella framework for Foundation and UIKit. This post only uses features from the shared Foundation framework, and this is applicable for both Mac OS X and iPhone OS.

The Ruby Problem

Ruby makes it extremely easy to work with arrays. For the sake of this post I want to convert an array of numbers into an array of strings. Performing the same operation on an arbitrary list of objects, and then resturn a list with the results.

list = [12, 42, 366]
results = list.collect { |item| item.to_s }
puts results

First line sets up an array of numbers, and the second line creates a new array by executing a block against each element, and then we print it out. The block can be seen as a closure, Java nor Obj-C have closures, at least not yet. Objective-C 2.1 will be public this summer and introduce blocks, that can be seen as closures.

With no closures at hand today, both Java and Obj-C will have to solve the problem by executing a method on each element. In this example toString() in Java and the Cocoa equivalent description.

Java Implementation

For the Java implementation we need to introduce a utility class. This utility class I call ListCollector, and it uses generics to allow for different kinds of inputs and results. This utility class could be implemented like this:

public class ListCollector {
 
    public interface Collector<R, E> {
        public R collect(E element);
    }
 
    public static <R, E> List<R> collect(List<E> list, Collector<R, E> collector) {
        List<R> results = new ArrayList<R>(list.size());
        for (E item : list) {
            R result = collector.collect(item);
            results.add(result);
        }
        return results;
    }
 
}

Our utility function collect takes two arguments; a List with elements, and a Collector implementation to invoke on each element. This do not use a closure as in the Ruby example.

A simple example of how to use this utility in the same veine as in the previous Ruby example:

public class Example {
    public static void main(String[] args) {
        List<Number> list = new ArrayList<Number>();
        list.add(12);
        list.add(42);
        list.add(366);
 
        List<String> results = ListCollector.collect(list,
                new ListCollector.Collector<String, Number>() {
                    public String collect(Number element) {
                        return element.toString();
                    }
                });
 
        System.out.println(results);
    }
}

Cocoa Interaface

In Cocoa you never have utility classes, instead you use categories to add new functions to already existing classes. A category can be seen as a mix-ins, it allows us to add and replace class and instance methods, as well as protocol conformance on already existing classes.

That is the good stuff, the bad stuff is that Obj-C do not know of final. So if an implementation is brittle, the only safety against bad programmers is the documentation you write. In fact Obj-C do not know of visibility, all methods are public. You can only hide a method by not displaying it in the public interface of your classes (your users may still guess at the names and use it anyway).

That leads us to interfaces, Obj-C just as C and C++ uses interface files; .h files. So lets define our category:

#import <Foundation/Foundation.h>
 
@interface NSArray (CWCollect)
 
-(NSArray*)resultsFromMakingObjectsPerformSelector:(SEL)aSelector
        withObject:(id)anObject;
 
@end

First thing we note here is that the method name is quite long; resultsFromMakingObjectsPerformSelector:withObject:, and that arguments are interleaved. At first glance it might look like named arguments, this is an illusion, they are merely interleaved with the : character. Looks strange, but the result is surprisingly readable and self describing code.

Note that is do not use a closure as in Ruby, nor an inner class as in Java, but a reference to a method identifier in the form of the SEL argument.

Cocoa Implementation

Just as C and C++ has interface files, so do Obj-C have implementation files; .m files, or .mm for Objective-C++ where you can mix C++ with Objective-C.

The implementation is quite familiar:

#import "NSArray+CWCollect.h"
 
@implementation NSArray (CWCollect)
 
-(NSArray*)resultsFromMakingObjectsPerformSelector:(SEL)aSelector
        withObject:(id)anObject;
{
    NSMutableArray* results = [NSMutableArray arrayWithCapacity:[self count]];
    for (id<NSObject> item in self) {
        id result = [item performSelector:aSelector withObject:anObject];
        [results addObject:(result != nil) ? result : [NSNull null]];
    }
    return [[results copy] autorelease];
}
 
@end

First we create a NSMutableArray, in Cocoa there are two classes for arrays; NSArray that is immutable, and the subclass NSMutableArray that is mutable. Then we use the for each statement to iterate over our input array. Then comes the first real difference from Java, and a clear display of the dynamic nature. Obj-C, nor Cocoa have support for generics. The use of the generic id object type avoids the need for most typecast, but you should be aware that they implicitly are there.

Methods are first class citizens in Obj-C, not tucked away in a utility package. A method in Obj-C consists of two parts; the selector and the implementation. The selector has the type SEL, and the implementation is IMP. Both can be passed around just as any other primitive type or object instance.

The selector is the identification of the method, think of it as the name. The selector is shared for all classes implementing a method with the same signature. If one class implements someMethod: and another class, in a completely other even dynamically loaded framework, also implements someMethod: both are guaranteed to be equal. The root object NSObject in Cocoa implements methods for dynamically invocing methods baseds on selectors, one of them is the one used in the code above performSelector:withObject:.

The implementation of a method is a function pointer to the actual executable code that implements the method. It can be shared between classes, as is often the case for subclasses. But can also be freely passes around, and exchanged for some quite powerful and useful tricks.

Cocoa Use-case Example

Obj-C is a strict superset of C, so just as you have a main function in C, so do Obj-C. For most Cocoa application you never need to worry about this, the template from Xcode will generate the main function and all you see is OOP goodnes. For this small example I will do the test code in a main function of my own. If you cut and paste code from this example, be sure to create a project from the "Command Line Utility"->"Foundation Tool" template in Xcode.

#import <Foundation/Foundation.h>
#import "NSArray+CWCollect.h"
 
int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
 
    NSArray* list = [NSArray arrayWithObjects:[NSNumber numberWithInt:12],
            [NSNumber numberWithInt:42], [NSNumber numberWithInt:336], nil];
 
    NSArray* result = [list
            resultsFromMakingObjectsPerformSelector:@selector(description)
            withObject:nil];
 
    NSLog([result description]);
 
    [pool drain];
    return 0;
}

The NSAutoreleasePool is part of Cocoa, and is used to seemingly garbage collected framework. Cocoa for Mac OS X can be garbage collected, Cocoa Touch for iPhone OS is not garbage collected.

The second statement created an array instance with three NSNumber objects. NSNumber is equivalent to java.lang.Number and all of it's subclasses, Cocoa do not have a separate subclass of NSNumber for each primitive type. NSNumber is a subclass of NSValue, that can hold any C type value including structs and unions.

The third statement is where we call the method we defined and implemented above. Note how we call this on a stock Cocoa class, not on a utility class. We use the @selector() compiler directive to retrieve a selector of SEL type from a human readable name, and pass nil the Objective-C equivalent of null as argument.

Lastly we send the result converted to a string to NSLog() function. NSLog() is a C macro with printf syntax that is used to send text to standard out. NSLog() can be removed from release builds.

Last Words

It is important to understand the concept of selectors, and how passing around SEL arguments works. In Java libraries callbacks are often handles using listener interfaces, where the listener implements an interface and a specific method is called. In Cocoa listeners are implemented using the target-action paradigm, where the intended listener is passed along with the SEL specifying which method to send the callback to.

As an example when setting up the event listener for user tapping a control in Cocoa Touch on iPhone OS:

[myButton addTarget:self action:@selector(buttonTapped:)
        forControlEvents:UIControlEventTouchUpInside];

What this means is that the need for anonymous inner classes is removed, and the same class can in a natural way receive the same event from different senders.

For more complex, or grouped event handling protocols are used. The classes conforming to the listeners protocols are not referred to as listener, but as delegates, yet again different name but same concept. But even now the dynamic language come into play, as a class is not required to implement all methods from a protocol in order to conform to it (Think of it as if some methods in a Java interface could be optional, and then are treaded as no-ops).

A protocol in Obj-C can have optional methods. Implementor of the NSTableViewDataSource protocol may for example choose to implement, or not to implement the method tableView:setObjectValue:forTableColumn:row:. If not implemented the table is read-only, by implementing this single method the table is editable and functionality such as pasting into the cells is provided for free.

It is very important for developers new to Cocoa and Obj-C to grasp the concepts of target-action, and delegates. This is the core principles that drive the application frameworks for Mac OS X and iPhone OS.

The Problem

The most intuitive way to create and use a UIToolbar is to add it manually for each of your view controllers. If your application is very simple this could be the right thing to do, but if our application uses a UINavigationController then it is the wrong way to do it.

If you look at the Mail application you will notice how the toolbar stays in place, and the items on the toolbar cross fades when you navigate the application hierarchy. You might also have noticed that the toolbar do not cross fade, but rather is pushed, if you add a toolbar to each of the view trees of your own view controllers. This is because your toolbar is then part of the wrong three hierarchy, as shown in this image.

Screen estate as owned by different view controllers.

You will find a few solutions if you Goole on the topic, all of them that I have found are dead wrong. They tend to use self.view.superview on the view controller instance to slide the toolbar up one level in the hierarchy. It works, most of the time, but is an ugly hack that is not future proof.

A Better Solution

The reason the toolbar is pushed off screen is that the toolbar is owned by the navigation controller,as we saw in the image above, and a navigation controller pushes it's content. The view hierarchy we would like to have is instead something like this.

Screen estate as owned by different view controllers.

In this setup the navigation controller can push the content, as it is intended to do, and the custom toolbar controller can manage a static UIToolbar with cross fades. Only problem is; this custom toolbar controller do not exist, and we must implement it on our own. Luckily not many lines of code is needed.

Custom Toolbar Conroller Requirement

The custom toolbar controller should be a subclass of UIViewController, that way it's fits nicely into the Cocoa Touch framework, and can nicely be fitted into any well written application.

The custom toolbar controller should manage a view consisting of a UIToolbar instance, and a view that is fetched from another view controller. This is modelled after how a UINavigationController manages a view that consists of a UINavigationBar and the view fetched from other view controllers. This way any well written view controller can be used with our custom toolbar controller.

Lastly our custom toolbar controller should implement the UINavigationControllerDelegate protocol, so that we can listen to events as view controllers are pushed and poped from the navigation stack, and update the toolbar with contextual toolbar items. Just as the navigation controller updates it's title by fetching the title property of the managed view controllers, so will our custom toolbar controller update the toolbar items by fetching the toolbarItems property if available.

Toolbar Controller Interface

The interface will be sparse, all we need is an initializer for creating a toolbar controller with another view controller providing the main content, and for sports two properties to access the content view controller, and the toolbar itself.

#import <UIKit/UIKit.h>
 
@interface CWToolbarController : UIViewController <UINavigationControllerDelegate> {
@private
    UIViewController* _contentViewController;
    UIToolbar* _toolbar;
}
 
@property(nonatomic, retain, readonly) UIViewController* contentViewController;
@property(nonatomic, retain, readonly) UIToolbar* toolbar;
 
-(id)initWithContentViewController:(UIViewController*)contentViewController;
 
@end

Toolbar Controller Implementation

The grunt work for implementing the toolbar controller do not need any further explanation.

#import "CWToolbarController.h"
 
@implementation CWToolbarController
 
@synthesize contentViewController = _contentViewController;
@synthesize toolbar = _toolbar;
 
- (id)initWithContentViewController:(UIViewController*)contentViewController;
{
    self = [super init];
    if (self) {
        _contentViewController = [contentViewController retain];
        if ([_contentViewController isKindOfClass:[UINavigationController class]]) {
            ((UINavigationController*)_contentViewController).delegate = self;
        }
    }
	return self;
}
 
// More code here...
 
- (void)dealloc;
{
    [_contentViewController release];
    [super dealloc];
}
 
@end

The first interesting code is to setup the view that is managed by our toolbar controller. This view have two subviews, a UIToolbar, and a view that we fetch from the content view controller we where given. We do this setup in the loadView method.

- (void)loadView;
{
    UIView* contentView = _contentViewController.view;
    CGRect frame = contentView.frame;
    UIView* view = [[UIView alloc] initWithFrame:frame];
 
    frame = CGRectMake(0, 0, frame.size.width, frame.size.height - 44.0f);
    contentView.frame = frame;
    [view addSubview:contentView];
 
    frame = CGRectMake(0.0f, frame.size.height, frame.size.width, 44.0f);
    _toolbar = [[UIToolbar alloc] initWithFrame:frame];
    [view addSubview:_toolbar];
 
    self.view = view;
    [view release];
    [_toolbar release];
}

This code reuses the screen setup already done by the content view controller, and re-layouts our subviews. It is a simple solution, and you will need a custom class for the root view with an overloaded layoutSubviews if you want to properly handle orientation changes. But I have left this out, as it is not within the scope of this post.

Next up we need to update the toolbar with contextual toolbar items, when our content changes. This is only supported if the content view controller is a UINavigationController, as can be seen in the initializer above. This could be made more flexible, but is also outside the scope of this post. We have set our toolbar controller to be the delegate for the content navigation view controller, so all we need to do is to respond to navigation events as they occur.

- (void)navigationController:(UINavigationController *)navigationController
        willShowViewController:(UIViewController *)viewController
        animated:(BOOL)animated;
{
    NSArray* items = nil;
    if ([viewController respondsToSelector:@selector(toolbarItems)]) {
        items = [viewController performSelector:@selector(toolbarItems)];
    }
    [_toolbar setItems:items animated:animated];
}

Conclusion

As shown with this code, doing the correct way with Cocoa Touch almost always means doing it in the easiest way as well. The hard part is knowing what the correct way is. My hope is that this post can guide you in the right direction. Rule of thumb is to always try to follow the same pattern as similiar things in Cocoa, it might feel like it is harder to do, but at the end of the day you will end up with less code, with more features.

The code above for implementing the custom toolbar controller, is much less code than what is needed to write a small application to demonstrate it being used. I have therefor made a small demonstration application with this complete code. It is a tree of table views, where each item opens up a new table view tree with one less toolbar item.

The source code is released under BSD license, and you can download it here.

A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.

This is true as it stands, but I think the main reason why Apple can keep a pace and a high standard of inovation is because of how they manage the Lowest Common Denominator. And iPhone OS with App Store is the crown jewel.

Technology vs. User Base

The lowest common denominator is always of interest when developing applications and services for the end user with profit interests. The lowest common denominator is what defines your user base, and it is a hard game of balance. Sticking to the newest technology will allow you to progress faster with more elegant solutions, whereas using a more commonly available technology will give you a larger user base.

So the lowest common denominator should be as high as possible, while still economical. With Java ME a bold effort to rise the bar of the lowest common denominator is the MSA JSR-248. An effort to give Java ME developers a guarantee minimum of features. A noble effort, but in reality up to a year ago only Sony Ericsson was MSA compliant, making the aged MIDP 2.0 the de-facto lowest common denominator for any developer targeting a the majority of Java ME devices.

The lowest common denominator for an average Java ME developer is the MIDP 2.0 spec from 2002.

iTunes as a Hub

Apple has a different situation, largely due to it's decision to use iTunes as the hub for all mobile devices, iPods as well as iPhones. All iPods and iPhones charges the battery by plugging in the USB-cable to your computer, this have some large but not obvious benefits.

Most notably Apple knows with 100% certainty that all users will have their devices on a reliable and controlled connection often, in most cases on a daily basis. As the users also use iTunes to synchronize their media, any other synchronization is not a hassle but rather a bonus on top of something they already requested.

Adding software updates on top of synchronizing media and data content through iTunes is just genius. It is a two click operation for the user, and as a result Apple virtually guaranteed that all iPod and iPhone users have the very latest software installed on their device.

Back-porting Software

Apart from the technology decision with iTunes as a hub, Apple have also made a business decision by always back porting their latest software to all iPhone OS powered devices. iPhone OS 2.0 can be installed on any first generation iPod Touch or iPhone, and with iPhone OS 3.0 this summer all three generations will be supported.

This back-porting model is the total oposite of almost all competitors, where instead new features are explicitly locked to the latest hardware in order to sell devices. So if the end users can get all the new iPhone 3.0 as a free download, why should they buy new hardware? Will not Apple loose revenue on unsold third generation iPhone devices?

In short term probably will, but the big win is the Lowest Common Denominator. Whereas the competition have a common lowest denominator of several years, almost a decade, Apple and all of Apple's third party developers have a lowest common denominator of virtually weeks.

Conclusion

With a simple software distribution model that guarantees the lowest common denominator Apple has guaranteed that the common lowest denominator is the current software, period. This allows Apple, and all third party developer creating applications and services for their devices, the luxury of discarding all effort for backward compatibility, and technological compromises.

Apple and we are allowed to innovate with full steam ahead.

Simply replacing the original delegate will break the default functionality. We need to somehow insert our own code to execute before the original delegates call. Or in AOP speak; a before advice.

The Wanted Solution

What we want is a proxy that can forward invocations both to our own delegate, and to the original delegate. The interface for said class looks looks like this:

@protocol CWDelegateOverrideProxyDelegate
@required
-(BOOL)shouldCallOriginalImplementationForSelector:(SEL)aSelector;
@end
 
@interface CWDelegateOverrideProxy : NSProxy {
@private
  id<NSObject> _originalDelegate;
  id<NSObject> _overrideingDelegate;
  id<CWDelegateOverrideProxyDelegate> _delegate;
}
 
@property(nonatomic, retain, readonly) id<NSObject> originalDelegate;
@property(nonatomic, retain, readonly) id<NSObject> overridingDelegate;
@property(nonatomic, assign) id<CWDelegateOverrideProxyDelegate> delegate;
 
-(id)initWithOriginalDelegate:(id<NSObject>)originalDelegate
     overridingDelegate:(id<NSObject>)overridingDelegate;
 
@end

And then we could use this class to replace an existing delegate with a short piece fo code like this:

UITabBar* tabBar = (UITabBar*)[self.tabBarController.view
    viewWithKindOfClass:[UITabBar class]];
CWDelegateOverrideProxy* proxy = [[CWDelegateOverrideProxy alloc]
    initWithOriginalDelegate:tabBar.delegate overridingDelegate:self];
tabBar.delegate = (id<UITabBarDelegate>)proxy;

See my previous post for the implementation of viewWithKindOfClass:.

Easy enough to use, only thing left is to implement CWDelegateOverrideProxy.

Enter NSProxy

Java only have one root class; java.lang.Object. Objective-C can have many, and Cocoa defines two; NSObject and NSProxy. Both of them conforms to the protocol NSObject, wich can be confusing. What we need to know is that class names, and protocol names have two different name spaces in Objective-C. Imagine it as if you could have a class and an interface with the same name in Java; in Objective-C you can. NSObject class is the root class for all concrete classes, and NSProxy class is the root class for proxies, both implements NSObject protocol allowing them to be interchangeable.

Without much ado, here is the base implementation for the initializer:

#import "CWDelegateOverrideProxy.h"
 
@implementation CWDelegateOverrideProxy
 
@synthesize originalDelegate = _originalDelegate;
@synthesize overridingDelegate = _overridingDelegate;
@synthesize delegate = _delegate;
 
-(id)initWithOriginalDelegate:(id<NSObject>)originalDelegate
     overridingDelegate:(id<NSObject>)overridingDelegate;
{
  _originalDelegate = [originalDelegate retain];
  _overridingDelegate = [overridingDelegate retain];
  return self;
}
 
// More code goes here!
 
@end

Introspection

In Objective-C, just as in Java, an instance can be queried for its class, and conformance to protocols (interface in Java speak). But as a bonus an instance can also be queried for specific methods per instance.

Our CWDelegateOverrideProxy class inherits from NSProxy. And it makes a simple assumption; if the original delegate, or the overriding delegate is capable of something, then so it is. So if queried for type of class, protocol conformance, or implemented methods, then we reply with whatever our managed delegates replies.

The NSObject protocol defines methods, equivalent of the java.lang.reflect package, that allows us to implement this as such:

#pragma mark --- Testing Object Behavior, and Conformance
 
-(BOOL)isKindOfClass:(Class)aClass;
{
  return [self.overridingDelegate isKindOfClass:aClass] ||
         [self.originalDelegate isKindOfClass:aClass];
}
-(BOOL)conformsToProtocol:(Protocol *)aProtocol;
{
  return [self.overridingDelegate conformsToProtocol:aProtocol] ||
         [self.originalDelegate conformsToProtocol:aProtocol];
}
-(BOOL)respondsToSelector:(SEL)aSelector;
{
  return [self.overridingDelegate respondsToSelector:aSelector] ||
         [self.originalDelegate respondsToSelector:aSelector];
}

Invocation Forwarding

The NSObject protocol also defines methods for functionality equivalent of java.lang.reflect.InvocationHandler and hooks to act as a java.lang.reflect.Proxy. The details are different as Objective-C do not enforce calls to only known methods at compile time, which means that at run-time unimplemented methods can be called.

When an unimplemented method is called the run-time will call methodSignatureForSelector:, that can return a NSMethodSignature instance, sort of the equivalent of a java.lang.reflect.Method. The run-time will then use the information from the NSMethodSignature instance to create a correct NSInvocation (other half of a java.lang.reflect.Method) instance, and set the correct arguments. This NSInvocation instance is then used as argument to call forwardInvocation:.

And thus our implementation is completed with:

#pragma mark --- Handling Proxy Methods
 
-(NSMethodSignature*)methodSignatureForSelector:(SEL)aSelector;
{
  if ([self.overridingDelegate respondsToSelector:aSelector]) {
    return [self.overridingDelegate methodSignatureForSelector:aSelector];
  } else if ([self.originalDelegate respondsToSelector:aSelector]) {
    return [self.originalDelegate methodSignatureForSelector:aSelector];
  } else {
    return [super methodSignatureForSelector:aSelector];
  }
}
 
-(void)forwardInvocation:(NSInvocation*)anInvocation;
{
  BOOL shouldCallOriginal = YES;
  SEL aSelector = [anInvocation selector];
  if ([self.overridingDelegate respondsToSelector:aSelector]) {
    [anInvocation setTarget:self.overridingDelegate];
    [anInvocation invoke];
    if (self.delegate != nil) {
      shouldCallOriginal = [self.delegate shouldCallOriginalImplementationForSelector:aSelector];
    }
  }
  if (shouldCallOriginal && [self.originalDelegate respondsToSelector:aSelector]) {
    [anInvocation setTarget:self.originalDelegate];
    [anInvocation invoke];
  }
}

And that rounds up how to implement a class that handles proxy based AOP, in order to introduce a before advice for delegate methods. For a more complex code base you can look at HessianKit, a framework that uses proxies, invocation forwarding and dynamic class creation in order to use a web service as distributed objects.

It is often nice to be able to reuse existing functionality when you subclass UITableViewCell. Properties such as image and textColor maps directly to the embedded UILabel and UIImageView subviews, and reimplementing them all when introducing a custom layout is tedious and error prone. Would it not be better to be able to get access to the original subview instances and just add a custom layout to them?

You can find subviews by class

Would it not be nice if the Cocoa Touch framework had a method such as this:

- (UIView*)viewWithKindOfClass:(Class)aClass;

Kind of like what viewWithTag:, does but instead of searching for a subview matching a tag, it searches for a subview matching a class.

Good news for us is that this is very easy to implement, by just adding a new category to UIView. Add a new .h/.m file pair to your Xcode project and type this down in the header file:

#import <UIKit/UIKit.h>
 
@interface UIView (CWViewWithKindOfClass)
 
- (UIView*)viewWithKindOfClass:(Class)aClass;
 
@end

Now we have to implement it. The existing viewWithTag: method is not documented as such, but my experimentation tells me that it uses a breadth first search algorithm. Quite logical as the wanted subview most commonly is close to the root view, and we want to find it fast. Since viewWithTag: always returns the first found matching view, we can do the same assumption.

The quite short implementation goes like this:

#import "UIView+CWViewWithKindOfClass.h"
 
@implementation UIView (CWViewWithKindOfClass)
 
- (UIView*)viewWithKindOfClass:(Class)aClass;
{
  NSMutableArray* nodeQueue = [NSMutableArray arrayWithObject:self];
  while ([nodeQueue count] > 0) {
    UIView* node = [nodeQueue objectAtIndex:0];
    [nodeQueue removeObjectAtIndex:0];
    if ([node isKindOfClass:aClass]) {
      return node;
    } else {
      [nodeQueue addObjectsFromArray:node.subviews];
    }
  }
  return nil;
}
 
@end

And that is it, not you can use it with something like for example this:

UITabBar* tabBar = [myTabBarController.view viewWithKindOfClass:[UITabBar class]];

Wich is an introduction to a future post, where I will discuss how to access the managed UITabBar of a UITabBarController, and introduce a UITabBarDelegate without interfering with the delegate already in place from the Cocoa Touch framework.

Update: Buttons created with UIButtonTypeRoundedRect is a special case returning a private subclass of UIButton, this bugfix can therefor not safely be used with rounded buttons. Good news is that they already have a large nice touch area.

With Objective-C you can

In short the problem is that the implementation of the factory method buttonWithType: in UIButton do not respect subclasses, so it will always return instances of UIButton. This is bad since it is the only method available to use to get custom buttons. Without access to the source code for UIButton changes can not be made to the implementation, so in order to fix the bug in UIKit we must wrap the original implementation of buttonWithType: with our own method that applies the bugfix.

Adding a category with a new implementation will not work, since that would shadow the original implementation. What is need is some sort of AOP, and Objective-C gives us enough of this but under the name of method-swizzling.

We can intercept method calls to buttonWithType: by swizzling the implementation with the implementation of our own method. In Objective-C all method implementations are called by name, that name is what is know as a selector. By swizzling the implementations we can make messages with the old selector call our new implementation, and vice versa.

We do this by adding a category to UIButton with this class method:

#import <objc/runtime.h>
+(void)load;
{
  Method oldMethod = class_getClassMethod(self, @selector(buttonWithType:));
  Method newMethod = class_getClassMethod(self, @selector(__buttonWithType:));
  method_exchangeImplementations(oldMethod, newMethod);
}

The class method load is called once for each class and category as they are loaded into the run-time, and is the optimal place to add initialization code. Think of it as static initializer blocks in Java.

And that is it, apart from implementing the actual bugfix in our __buttonWithType: method.

A better bugfix

The fix I did in my previous post only worked if the new subclass of UIBUtton did not introduce any new instance variables. This is a limitation, and not quite as obvious to new users of our bugfix, so this time around the bugfix will work with any subclass.

The trick here is allocate a new instance of the correct subclass if needed, and copy over the instance variables. Implementation:

+(UIButton*)__buttonWithType:(UIButtonType)type;
{
  UIButton* button = [self __buttonWithType:type];
  Class buttonClass = [button class];
  if (button && buttonClass != self && buttonClass == [UIButton class]) {
    size_t oldSize = class_getInstanceSize([button class]);
    size_t newSize = class_getInstanceSize(self);
    button->isa = self;
    if (oldSize < newSize) {
      UIButton* newButton = [self alloc];
      memcpy(newButton, button, oldSize);
      button = [newButton autorelease];
    }
  }
  return button;
}

At first glance the first statement might look like a recursive call, but remember that we have swizzled the implementations so it will call the original implementation of buttonWithType:.

Also note that we must autorelease the new instance that we allocated, and that we must not release the original instance as that one is already owned by an auto release pool.

And that is how you go about fixing bugs in Objective-C for code that you do not have access to the source code for.