Functional code!

Turns out that JavaScript is functional, not as in working but as in a functional programming language. So when calling -[UIWebView stringByEvaluatingJavaScriptFromString:] you do not pass in for example:

return x * y;

But instead:

x * y

Yes even without the trailing ; character! The result returned from -[UIWebView stringByEvaluatingJavaScriptFromString:] will be the value of the last statement, if you add a trailing ; then the last statement will be an empty statement and you will get an empty string as a result. Took quite some time before I figured that one out.

UIWebView must be on screen to execute script

The UIWebView class will not render any content, nor execute JavaScript if it is not potentially on screen. So you must add the UIWebView to the view hierarchy even if you just have it around for executing some JavaScript in the background.

It is perfectly ok to let the web view be 0x0 pixels, or full transparency, but hidden does not seem to work either.

All access must be on the main thread

Not news since the documentation clearly says you should only work with UIKit classes on the main thread (with a few added thread safe additions in IOS 4). But this is a problem if you want to do background tasks with JavaScript, since you must call -[UIWebView stringByEvaluatingJavaScriptFromString:] from the main thread. Any long running JavaScript will block all user input and updates of the screen.

No fear though, you can make your JavaScript asynchronous. But then -[UIWebView stringByEvaluatingJavaScriptFromString:] will return before your script has finished and UIWebView do not have any obvious other way to communicate any results back to you. Obvious way that is. What you instead have to do to get asynchronious results back into the Objective-C world is by fake URL requests. Use a function like this to return results from the JavaScript world:

var returnAsyncResult = function(result, context) {
    window.location = 'result://dummy.com/' + result + '/' + context;
}

And then let the delegate for your UIWebView get the result as such:

-(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType;
{
    NSString* urlString = [[request URL] absoluteString];
    if ([urlString hasPrefix:@"result:"]) {
        NSString* path = [[request URL] path];
        NSArray* pathComponents = [path pathComponents];
        NSString* result = [pathComponents objectAtIndex:1];
        NSString* context = nil;
        if ([pathComponents count] > 2) {
            context = [pathComponents objectAtIndex:2];
        }
        [delegate javaScriptEvaluator:self
                      didReturnString:result
                              context:context];
        return NO;
    } else {
        return YES;
    }
}

Only String results

Turns out that -[UIWebView stringByEvaluatingJavaScriptFromString:] only returns strings as result. No problem for simple types such as said strings and numbers, but a big problem if you try to return a complex value such as an array:

[1,2,3]

This will not work, and will return a NSString of zero length. You must explicitly convert arrays to strings before returning them to the Objective-C world, easiest way would be something like this:

'[' + [1,2,3] + ']'

Conclusion

UIWebView is a blunt tool. Please do use http://bugreport.apple.com and file a request to make JavaScript Core a public framework. The more duplicates, the higher Apple will prioritize this issue on their todo list.

In the meantime UIWebView can be used to your bidding if treated with care.

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.

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.

Dependency injection and early validation is crucial for an enterprise application, and Spring is a boon in this regard. But do not fool yourself, Spring is good, but it is not a universal cure. Especially not in mobile space where startup times, low memory consumption, and avoiding interfaces are virtues.

The bottleneck in an enterprise application is most probably the database, spending a few extra milliseconds here and there seldom matters. On much less performant mobile device those clock cycles are not only time the user has to spend waiting, it will drain the battery. A simple thing as using an interface instead of an abstract superclass will perform at least twice as slow. Even passing an extra argument in the constructors a few nestings deep will have an impact.

Lazy Singeltons by Choice

Class loading in Java is lazy, the Java VM will not load classes until they are referenced. Odds are that the user will not trigger a full coverage of all classes in your app for a short time running mobile app. If the user just checks for incoming messages and quits, then every class involved in composing messages do not need to be loaded. Early dependency injection breaks this, as all classes will be referenced at startup. Most components will be initialized in vain, as they are never actually used.

So what we should do in mobile application is to work more like the Java VM, and less like Spring. If possible do not create a component until it is requested. The best way to do this is using a singleton pattern. Not a normal enforced singleton pattern, but rather a singleton by choice. Let the constructor be public, trust your users, and name the getter getSharedFoo(), not getInstance(). Let me show you using a example of an URL cache component:

public class URLCache {
  private static URLCache sharedCache;

  public static URLCache getSharedURLCache() {
    synchronized (URLCache.class) {
      if (sharedCache == null) {
        sharedCache = new URLCache();
      }
    }
    return sharedCache;
  }

  public URLCache() {
    // More code...
  }
  // Allot more code here...

}

Using this shared URL cache component from our imaginary HTTP provider would then be super easy, but not mandatory:

public class HTTPProvider {

  public InputStream inputStreamForURL(String url) {
    URLCache cache = URLCache.getSharedURLCache();
    // Use the cache...
  }

}

The big win here is that if the code path of this run of the application never tries to open an input stream then the URL cache never has to be created. Saving several hundred milliseconds of reading cache indexes, validation, etc.

But What About Testing?

Are not singletons bad for unit tests and mocking components? They used to be. These days we have PowerMock, you really should use it. Turns out that not even PowerMock is really required, if we just change our singleton pattern very slightly, and allows the outside to set the shared component as well:

public class URLCache {
  private static URLCache sharedCache;

  public static void setSharedURLCache(URLCache cache) {
    synchronized (URLCache.class) {
      sharedCache = cache;
    }
  }

  public static URLCache getSharedURLCache() {
    synchronized (URLCache.class) {
      if (sharedCache == null) {
        sharedCache = new URLCache();
      }
    }
    return sharedCache;
  }

  // Allot more code here...

}

This small addition allows us for setup up our own mock cache in the setup of our unit tests. With something as simple as this:

public class SomeTest extends TestCase {

  public void setUp() {
    URLCache.setSharedURLCache(new NoOpURLCache());
  }

  public void testRemoteResource() {
    assertNotNull(HTTPProvider.getSharedHTTPProvider().inputStreamForURL(TEST_URL));
  }
}

It also allows us for explicitly override a singleton if our application has special needs, perhaps a more aggressive cache on a low bandwidth mobile data connection, or special implementation on a buggy Java ME platform. But most importantly for the normal case it will not waste time creating the component until it is actually needed, vastly improving the user experience for your mobile users.

Take Aways

Do not fear singletons, it is a great way of lazy creations that will greatly improve startup times and memory consumption on mobile applications.

Avoid using interfaces, they are at least twice as slow as classes, and can not have static methods for acquiring the lazy created components.

Do not enforce the singleton pattern, always use singleton by choice. To allow for testing and easy implementation of special cases.

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.

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.

The Anecdotal History

We are developing a custom application framework on top of MIDP, adding a MVC application model, and modern interface components with touch and animation support. All this is build on top of a shared subclass of Canvas, and our own custom drawing with screen transitions, etc. is implemented on top of that.

An interface component is called a View, and any interface component that can host other interface components implements the ViewParent interface. Simple until I introduces the method hasFocus(). All of a sudden the application refused to run on target Sony Ericsson device. The emulator worked nice, our P1i worked, even the Xperia X1 run. But none of the cybershots, or walkmans with JP-7 or JP-8.

"Application error". Oh well, that means that something threw an exception during the MIDlet constructor or appStart() call. So add pedantic catches, and display the error in an Alert; "NoClassDefFoundError".

The Problem

NoClassDefFoundError on the OSE phones, but no other installed with the same jad/jar-files, that is strange. Unfortunately Sony Ericsson has a policy of removing all error messages from exceptions, so no clue as to what class is missing either. Turn off Proguard optimization, still does not work, still NoClassDefFoundError. Head back to the Subversion logs and binary search, what is the latest revision that worked? And what was changed?

Turnes out that the shared Canvas subclass that implement the aforementioned interface ViewParent got the new method hasFocus(), and that is the only change from the working revision, to the broken revision.

- "I'm pretty sure that is working.", one of the half dozen bug-hunting team member said looking at:

public boolean hasFocus() {
    return true;
}

As it turns out the platform implementation of the MIDP class Canvas has a hidden method named hasFocus(). It is not private, but declared as public and final, but not exposed in the public API. So when our subclass is loaded, our public hasFocus() method clashes with the unexposed public final hasFocus() of the platform's implementation.

Solution, and Lesson Learned

The method hasFocus() was renamed to isInFocus(), and now everything works again.

From now on we will:

• Never trust subclasses of MIDP classes.
• Test on device early and often, also for obvious changes.
• Always keep commits small and atomic.

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.

The four corners are coped as is, the four borders scaled in a single direction, and the center is scaled in both directions. Since MIDP do not support image scaling this must be implemented by hand using the ARGB values fetched using Image#getRGB(). The documentation is quite straight forward, but fail to mention one pecularity in many implementation...

Clearing unwanted data

I want to create the target image in a single int[] array to reduce memory usage. No problem copying image data into this structure, it is just what the quite straightforward API is designed to do:

public void getRGB(int[] rgbData,
                   int offset, int scanlength,
                   int x, int y,
                   int width, int height)

Unfortunately the documentation fails to mention that many implementations will not as expected just ignore data in rgbData that is not copied. Instead zeroes, or transparent pixels, will be filled in for any image data that has not been requested on a per row basis. I dare anyone to find where this is mentioned in the MIDP spec.

A solution

The solution is to write your own wrapper method for Image#getRGB() that copies just a single row of image data at a time, and the requested scanline length must be lied about to avoid having the remainder of lines filled with zeroes. Here is tho code ready for copy and paste:

public class ImageUtils {
    public static void getRGBFromImage(Image image, int[] argbData, int offset,
            int scanline, int x, int y, int width, int height) {
        for (int row = 0; row < height; row++) {
            image.getRGB(argbData, offset, width, x, y + row, width, 1);
            offset += scanline;
        }
    }
}

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.

First the preface

I wanted to add a star button to the right side of each row, subclassing UIButton that can manage selected states, images and all I needed, and use it as the accessory view of the UITableViewCell felt natural. It works and is the right thing to do. The simple factory method is:

+(CWFavouritesButton*)favouritesButtonWithTarget:(id)target action:(SEL)action;
{
  CWFavouritesButton* button = [self buttonWithType:UIButtonTypeCustom];
  if (button) {
    [button addTarget:target action:action forControlEvents:UIControlEventTouchUpInside];
    button.frame = CGRectMake(0, 0, 29, 31);
    button.backgroundColor = [UIColor clearColor];
    [button setImage:[UIImage imageNamed:@"star-deselected.png"] forState:UIControlStateNormal];
    [button setImage:[UIImage imageNamed:@"star-selected.png"] forState:UIControlStateSelected];
  }
  return button;
}

Now if this had been all then, simply adding the factory method with a category on UIButton would have been enough. But as it is, a UIButton uses the alpha mask of its' image as hit target. That hit target is quite small, at least 44 pixels should be used with fingers on a touch screen. Therefor I subclass UIButton so that I can override the hit test as this:

-(BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;
{
  CGRect bounds = self.bounds;
  bounds = CGRectInset(bounds, -32, 0);
  return CGRectContainsPoint(bounds, point);
}

This would allow for an extra 32 pixels to hit on the left and right side of my star button. But now problems arise! Turns out that the overridden implementation of pointInside:withEvent: is never called.

Many hours of troubleshooting later I figured out that the buttonWithType: factory method is the culprit; it do not respect subclasses. Meaning that it will always return instances of UIButton, and thus always call the original implementation of pointInside:withEvent:. Unfortunetely this is the only public factory or init method that can be used to create a button with images only. What to do?

Objective-C to the rescue

With Objective-C we can change the class of an already live object instance, one nice feature of having a dynamic run-time.

All books will tell you that all classes inherits from NSObject. This is not quite true, there is among others NSProxy as well, and you could actually introduce your own root classes if you like. All of them will inherit from the run-time class id. The run-time class id do not implement a single class method, nor instance methods, all it has is a single instance variable: isa of type Class.

As we all should know classes in Objective-C are also object instances, instances of their meta-classes. The isa instance variable is the reference to the object instance's class instance. And here is the gold nugget; it is write-able. So we can change an object instance's class by simply assigning a new value to isa.

So lets update the previous factory method to this:

+(CWFavouritesButton*)favouritesButtonWithTarget:(id)target action:(SEL)action;
{
  CWFavouritesButton* button = [self buttonWithType:UIButtonTypeCustom];
  if (button) {
    button->isa = [CWFavouritesButton class];
    // More init code...
  }
  return button;
}

Some precaution

This might look dangerous, and it is. But not so dangerous that you should shun it, the Cocoa frameworks uses it to it's advantage, and so should you. The only thing you need to be aware of is that the instance size of the original and new classes must be the same. This is easily done by importing runtime.h, and use class_getInstanceSize().

#import <objc/runtime.h>
+(CWFavouritesButton*)favouritesButtonWithTarget:(id)target action:(SEL)action;
{
  CWFavouritesButton* button = [self buttonWithType:UIButtonTypeCustom];
  if (button && (class_getInstanceSize([button class]) == class_getInstanceSize([CWFavouritesButton class]))) {
    button->isa = [CWFavouritesButton class];
    // More init code...
  }
  return button;
}

And finally our factory method safely return a new button of the correct subclass, and pointInside:withEvent: is called as expected.

The full source code for SC68 Player where I implemented this is available for download here.

The sessions are confidential so I will keep this post vague on the technical parts, not revealing any thing that might or might not come to an iPhone or iPod touch near you in the future. And I can not mention any specific sales numbers, but I do can say that any predicted numbers you might have seen; is probably an underestimation with a margin and then some.

The sessions where on a high level, not going too deep on technical details. Instead the sessions concentrated on the overall design philosophies, and common gotchas. For the nitty gritty details Apple engineers where available, and I missed half a session discussing the ins and outs of the UIToolbar class with Alberto Arauz. Alberto is one of the european software evangelist, and was most impressed, and interested, when I described the successful Mobile 2.0 track at Øredev 2008. Apple's overall impression with Scandinavia has so far been a mostly cold hand regarding anything with Apple, going as far as only six people registering for a Tech Talk in Oslo two years ago.

Apart from the speakers and engineers, Apple also brought a video-team. So yours truly has been intervjued about the applications I have on App Store, and my experience with the iPhone SDK. The video will be cut and edited for promotional purposes, and hopefully me mentioning both Malmö and Jayway will not be cut out. The odds of my short talk being included is quite good, as most developers seems to be focusing on games, not utilities as I and Jayway has done.

The best part to take home is not technical, just solid advice for any development, not even under NDA, and the sole point repeated by Apple over and over: Developing great applications is not about adding features! The trick is not to cram in as many features as you can, the trick is to know what features to leave out, so that time can be well spend on the key features that do make the cut. And this is tenfold as important on a mobile device where real estate is limited. A quote from Mark Twain:

I apologize for writing you a long letter, but I did not have the time to write a short.

Writing short, and cutting features is hard. How to decide on the features to drop or implement? Apple uses a simple technique, called a product statement. The product statement for the Photos application is for example; "An easy to use photo sharing application for all iPhone users". Any feature that do not help fulfilling this statement do not make it. How about simple photo-editing? Nope, does not comply with statement. The wording of the product statement is important, by simply changing it to "An easy to use photo sharing application for professional photographers", would be a completely new application. Only when the product statement is agreed upon, can an approved list of features be made. An omnipresent Steve Jobs approving and dismissing features, is an exaggeration, this simple method is what do the trick.

Now this might sound both obvious, and counterintuitive. Surely adding that last nice feature would add value? Not at the expense of a cluttered user interface, that is meant to be used while standing in line for 30 seconds. Features thought to be must haves, most of the time are not. Some features thought to be must haves are MMS and video recording. Looking at the raging success of the iPhone, it is very obvious that they are not must haves. We as software engineers must at long last learn that it truly is quality over quantity.

And lastly a personal reflection; from a developer's point of view the best part about iPhone SDK is that it is not an UI framework, it is an Application framework. It do not settle with providing the tools for collections, persisting data, displaying a UI, and then leave the rest of the architecture to the developers. The iPhone SDK supports all three parts of the Model-View-Controller paradigm equally well, and that is what makes it so productive.

So I took out my laptop during the next 60 minutes of Panel Debate, and wrote an iPhone app, and as I expected the code landed on 46 lines of code for the actual application logic, physics, grits and all. Or 112 lines of code if headers and boiler-plate should be counted as well.

This blog post will describe what I did, in a quite nice model-view-controller fashion (Model and Controller is implemented in the same class).

• First of all I needed a view to display my bouncing ball on, I choose to subclass UIViewController to handle this view.
• A standard UIView instance with a UIImageView sub-view for the ball is all I need for my view, this I setup using Interface Builder.
• And the model/logic is handled by one CGPoint for the current location, and one CGPoint with the current delta movement of the ball.

First the custom view controller sets up itself as the accelerometer delegate when awakening from it's nib-file.

-(void)awakeFromNib;
{
  self.location = CGPointMake(160, 230);
  UIAccelerometer* accelerometer = [UIAccelerometer sharedAccelerometer];
  accelerometer.updateInterval = 0.02;
  accelerometer.delegate = self;
}

Then comes a private function for the quite faked physics, it is responsible for detecting if a value with a given delta movement has hit a min or max edge. If it do hits an edge, it flips it's delta movement with some deceleration, and corrects it's value.

static inline BOOL bounce(float* val, float* delta, float min, float max) {
#define FLIP(val, c) (c - (val - c))
  if (*val < min || *val > max) {
    *delta = -(*delta * 0.75);
    float loc = *val < min ? min : max;
    *val = FLIP(*val, loc);
    return YES;
  }
  return NO;
}

And lastly the delegate method that is called by the accelerometer. Here we update the delta movement, and use the bounce-function to detect and compensate location+delta when the ball hits any edges. If an edge it hit, a vibration is also triggered.

-(void)accelerometer:(UIAccelerometer*)accelerometer
       didAccelerate:(UIAcceleration*)acceleration;
{
#define CAP(val, max) (val < -max ? -max : (val > max ? max : val))
  CGPoint delta = CGPointMake(CAP(self.delta.x + acceleration.x, 32),
                              CAP(self.delta.y - acceleration.y, 32));
  CGPoint location = CGPointMake(self.location.x + delta.x,
                                 self.location.y + delta.y);
  if (bounce(&location.x, &delta.x, 8, self.view.bounds.size.width - 8 ) ||
      bounce(&location.y, &delta.y, 8, self.view.bounds.size.height - 8))
  {
      AudioServicesPlayAlertSound(kSystemSoundID_Vibrate);
  }
  self.delta = delta;
  self.location = location;
  self.ballView.center = self.location;
}

In conclusion Cocoa Touch requires surprisingly little code for accessing and using the accelerometer and trigger a vibration. Triggering a vibration is literary done with a single line of code. The lines of code needed to setup and listen to the accelerometer can literary be counted on the fingers of one hand.

On the downside there is no finer control of the vibration, and if you like to have the rotation angles of the device instead of simple gravity forces of the x, y and z axis, then you must do the math for yourself. Simple enough, but it would had been nice to have to current rotations around each axis as well.

The full source code can be downloaded here.

ps. I dare Mike Jennings to best this . ds.

HessianKit is available for Mac OS X 10.5 and later, and iPhone OS 2.0. The three main goals are:
* To be as compliant and forgiving as possible.
* Provide seamless Objective-C experience against web services implemented in Java.
* Avoid glue-code.

This is done by allowing clients to define proxy and value object as Objective-C protocols, and let HessianKit generate conforming classes on the fly. HessianKit is design to be similar to Distributed Objects in Mac OS X Cocoa (not available for iPhone OS). Re-inventing the wheel is avoided by building on available technology in Cocoa (Touch) such as key-value-coding, introspection, and invocation forwarding.

HessianKit is currently 1.0beta, but is production ready, and is used for implementing iPhone clients for web services previously designed for JavaME applications.

So how does it work? Lets assume we have a hessian web service publishing the following Java interface:

 
public interface HelloService {
  public String helloWorld();
}

The Objective-C implementation would then need to define the same Java interface as an Obj-C protocol.

 
@protocol CWHelloService
-(NSString*)helloWorld;
@end

With the interface/protocol defined the client creates proxies to the web service as follows.

 
NSURL* url = [NSURL URLWithString@"http://www.mydomain.com/helloservice"];
id<CWHelloService> proxy = (id<CWHelloService>)[CWHessianConnection proxyWithURL:url protocol:@protocol(CWHelloService)];
NSLog(@"hello: %@", [proxy helloWorld]);

And that is it.

Since Java and Objective-C differ in the naming of methods, some translation must be done when sending call tho the hessian web service. Method names are first looked up using the class method CWHessianArchiver methodNameForSelector:], if a method name is not returned, the method name to use will be generated to match Java and Obj-C conventions as closely as possible. Some examples.

doFoo      ==>  doFoo
getFoo:    ==>  getFoo__1
doFoo:bar: ==>  doFooBar__2
doFugly::: ==>  doFugly__3

Data will be serialized using standard Hessian types; boolean, int, and double. All Obj-C classes that implements NSCoding can be serialized for transports as Maps. Some classes are getting some special treatment for convinience on both sides.

NSArray      - Maps to Java array or java.util.List, tansfered as Hessian list.
NSDictionary - Maps to Java java.util.Map, or domain class, trabsfered as Hessian map.
NSData       - Maps to Java byte array, transfered as Hessian binary data.
NSDate       - Maps to Java long or java.util.Date, transfered as Hessian date.
NSString     - Maps to Java java.lang.String, transfered as Hessian string.
NSXMLNode    - Maps to Java org.w3c.dom.Node, transfered as Hessian xml.

That is it, now off to coding HessianKit 1.0 Final Candidate.

Not only the provided Frameworks are polished even in beta, so are the tools. Mac OS X 10.5 Leopard, and Xcode 3.1 is required! If you can live with that works perfectly, with zero setup; double click install package and you are done. Several project templates provided as starting points. Only drawback I find is that the Simulator is not an emulator of the actual hardware, eg. it is running 32-bit x86 not ARM, which makes an Java JIT-compiler undebuggable on the Simulator. Good news is that there is transparent on-device debugging, bad news again; it requires the 2.0 beta software on the phone.

My second reaction is that it is complete. The SDK, as well as the underlying system. It truly is the same system as on desktop Macs running on the device. The same kernel, the same Frameworks. Just a bit more restrictive memory, and screen size.

The documentation is impressive, ranging from conceptual books and a wide range of subjects such as as Human Interface Guidelines, Memory Management, introduction to Objective-C for beginners, writing games using Open GL | ES, security, and much more.

It is obvious by looking at the documentation provided that special care has been taken to cater for the needs of developers without previous experience of Cocoa, or Mac OS X development. Two thirds of the documentation is very basic for anyone with more then a few months experience with Cocoa. And the last third is in depths iPhone OS specific. Most of the documentation is also shared between iPhone OS and desktop Mac OS X, my gut feeling is that Apple want to use iPhone as a lure for developers to embrace Cocoa on Mac OS X as well.

Apart from documentation there is also over 4 hours of video tutorials, ranging from basic overview to optimizing OpenGL | ES games. As well as over 40 example projects, including complete applications. Bot the "show a feature" type that Android have in bounty, and "show a solution" that gives a better feel for how an application should be organized.

And organizing an application is important. Just as with Cocoa for Mac OS X, Cocoa Touch for iPhone OS gives the developer allot for free, provided you follow a few guidelines, and best practices. These are however few, and clear, so anyone can get the hang of it in a matter of hours. Cocoa's inherent talkative API:s with descriptive class, method and constant names, encourages developers to both use and follow "good style". A method named applicationDidLaunch is very hard to misinterpret (It is however misspelled as ApplicationDidLaunch in the iPhone OS Development Introduction ).

And my last reaction; it is beta! Interface Integration is not yet included. That means that you will have to create your UI in code, not using the drag-n-drop as shown on the Keynote last thursday. I miss it dearly, but try to tell myself it is a good thing to first learn how it works under the hood . That and a short list of known bugs, is really the only things I can see standing in the way of a 1.0 release.

I have as a tutorial for myself rewritten the URLyBird assignment for my Java Developer certification with the iPhone OS SDK. Minus the remote server it is up and running beautifully in less than 8 hours of coding.