[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.

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.

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

An Ugly Solution

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

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

What Apple Recommends

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

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

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

Other Solutions

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

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

A Pretty Solution

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

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

Setting Up RegexKitLite

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

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

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

Using RegexKitLite

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

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

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

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

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

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

And you can extract more complex data using capture groups:

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

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

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

Introduction

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

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

Objective-C from a Java perspective

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

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

Classes

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

@interface MyClass {
}
@end

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

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

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

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

@interface MyClass : NSObject {
} 

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

Naming conventions

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

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

Access Control

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

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

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

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

Methods

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

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

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

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

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

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

[myObject add:5 to: 2];

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

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

Constructors

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

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

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

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

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

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

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

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

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

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

Protocols

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

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

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

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

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

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

Where’s my garbage collector?

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

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

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

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

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

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

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

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

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

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

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

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

Conclusions

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

Christian Hedin
Stefan Li

Originally published in JayView.

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

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

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

New Categories on NSArray and NSMutableArray

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

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

Base Implementation

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

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

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

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

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

Sort Using Selector

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

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

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

Sort Using Sort Descriptors

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

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

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

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

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

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

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

Conclusions

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

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

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

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

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.