• bluewoki
• Cortito
• CoreTextWrapper
• dotfiles
• eBook-Template
• iPhoneWebServicesClient
• nib2objc
• Senbei
• Teaching Editor

Feel free to fork and enjoy!

Similar Posts:

• A nicer cortito, courtesy of Zerofee
• Senbei 1.3 hits the App Store!
• Introducing the Teaching Editor
• More nib2objc fun
• bluewoki 2.0 Hits the App Store!

It is built exclusively in JavaScript, using the following libraries:

• Ace
• Ext.js
• Node.js
• Express

Requirements

Server

Use Homebrew to install Node.js in your system. Also, install npm and install Express and Socket.IO with npm.

The install.sh script performs all the required operations to install external dependencies in your system.

Client

The client has been tested successfully on several combinations of operating systems and browsers:

• Cross-platform browsers:
  • Firefox 10
  • Chrome 17
  • Opera 11
• OS X “Lion”
  • Safari 5.1
• Windows 7
  • Internet Explorer 9
• iOS
  • Mobile Safari for iOS 5.1 on the iPad (in this case, however, scrolling is not possible)

Pay attention to the fact that the mobile libraries themselves might not be compatible with some of these browsers (in particular, Sencha Touch only works on Webkit-based browsers).

How to Use

• ./install.sh (this will download the required libraries, only required once)
• ./launch.js (this launches the Node.js app and opens a browser window)
• Students can browse to the IP shown in the dialog of the “Project / Show Share URL” menu entry.

License

This project is released under the GPLv3 license. Please check the LICENSE file for details.

[13]:http://akosmasoftware.github.com/TeachingEditorSimilar Posts:

• Attending SenchaCon 2011
• Our Open Source Projects
• Mobile Web Training in Zürich!
• Announcing EERV cal, an iPhone, Android and Web Application!
• Integrating iOS Applications with Backend REST Services

Of course, you can’t just ++ on the current NSIndexPath, because these objects have both a section and a row component, and the math required to jump from one to the other can be quite cumbersome; instead, it would be useful to have a reusable set of methods, and avoid the clutter in our controllers.

I have created a very simple category on the NSFetchedResultsController class that retrieves the “next” and the “last” NSIndexPath given any other NSIndexPath; this can be dropped and reused in your projects and is very simple to use.

Interface

#import <CoreData/CoreData.h>
@interface NSFetchedResultsController (AKOLibrary)
- (NSIndexPath *)ako_incrementIndexPath:(NSIndexPath *)oldIndexPath;
- (NSIndexPath *)ako_decrementIndexPath:(NSIndexPath *)oldIndexPath;
@end

Implementation

#import "NSFetchedResultsController+AKOLibrary.h"
@implementation NSFetchedResultsController (AKOLibrary)
- (NSIndexPath *)ako_incrementIndexPath:(NSIndexPath *)oldIndexPath
{
    NSIndexPath *nextIndexPath = nil;
    id <NSFetchedResultsSectionInfo> sectionInfo = [[self sections] objectAtIndex:oldIndexPath.section];
    NSInteger rowCount = [sectionInfo numberOfObjects];
    NSInteger nextRow = oldIndexPath.row + 1;
    NSInteger currentSection = oldIndexPath.section;
    if (nextRow < rowCount)
    {
        nextIndexPath = [NSIndexPath indexPathForRow:nextRow inSection:currentSection];
    }
    else
    {
        NSInteger sectionCount = [[self sections] count];
        NSInteger nextSection = currentSection + 1;
        if (nextSection < sectionCount)
        {
            nextIndexPath = [NSIndexPath indexPathForRow:0 inSection:nextSection];
        }
    }
    return nextIndexPath;
}
- (NSIndexPath *)ako_decrementIndexPath:(NSIndexPath *)oldIndexPath
{
    NSIndexPath *previousIndexPath = nil;
    NSInteger nextRow = oldIndexPath.row - 1;
    NSInteger currentSection = oldIndexPath.section;
    if (nextRow >= 0)
    {
        previousIndexPath = [NSIndexPath indexPathForRow:nextRow inSection:currentSection];
    }
    else
    {
        NSInteger nextSection = currentSection - 1;
        if (nextSection >= 0)
        {
            previousIndexPath = [NSIndexPath indexPathForRow:0 inSection:nextSection];
        }
    }
    return previousIndexPath;
}
@end

How to use

To use this class, just do the following:

NSIndexPath *indexPath = [NSIndexPath indexPathForRow:19 inSection:4];
NSIndexPath *next = [controller ako_incrementIndexPath:indexPath];
NSIndexPath *previous = [controller ako_decrementIndexPath:indexPath];

If the NSIndexPath (19,4) was the last of whole table, next would be nil. The same, if NSIndexPath was the first (0, 0), then previous would be nil. In all other situations, the next and previous index paths will correspond to the cells immediately above or below from the current table.

Hope this helps!Similar Posts:

• Objective-C Categories as Stylesheets
• Determining Delegate Object Method Call Order in Objective-C with NSProxy
• Smart Pointers in Objective-C++
• Advanced iOS 4.2 Training Course – Zürich, February 7th and 8th 2011 – Enroll now!
• nib2objc Featured on The Changelog

Many developers new to the iOS platform have trouble understanding the delegate architecture, in the sense that many other OO toolkits use properties to configure the characteristics of UI elements, instead of having a separate object doing the job.

When using delegates, the sequence of calls for each method is important: most Cocoa developers know that UITableView instances call delegate and data source methods roughly in this order:

• numberOfSections:
• numberOfRows:inSection:
• cellForRowAtIndexPath:
• configureCellAtIndexPath:

…mixing up in the middle some calls to headers and footers and cell sizes as well. Which prompts the following question: what is really going on behind the scenes? Can we know exactly the order in which those delegate methods are called?

To answer that question, here’s a small project in Github that uses all the delegate and datasource methods in the same project, and that uses NSLog to show which calls happen first, and when.

Delegate Methods

But first, a quick recap on delegate methods in Objective-C.

In many (if not most) object oriented toolkits, properties tend to be used when setting up an object such as a table view, for instance in .NET, as shown in this example from Microsoft

<%@ Page language="c#" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<script runat="server">
void Page_Load(Object sender, EventArgs e)
{
   SqlConnection cnn = new
       SqlConnection("server=(local);database=pubs;Integrated Security=SSPI");
   SqlDataAdapter da = new SqlDataAdapter("select * from authors", cnn);
   DataSet ds = new DataSet();
   da.Fill(ds, "authors");
   Repeater1.DataSource = ds.Tables["authors"];
   Repeater1.DataBind();
}
</script>
<html>
<body>
   <form id="WebForm2" method="post" runat="server">
      <asp:Repeater id="Repeater1" runat="server">
         <ItemTemplate>
         <%# DataBinder.Eval(Container.DataItem,"au_id") %><br>
         </ItemTemplate>
      </asp:Repeater>
   </form>
</body>
</html>

In the code above (a classic ASP.NET page) the Repeater1 instance (of the Repeater class, which is a view component) is “bound” (a classic example of “databinding”) to an instance of a DataSet. In this case, we just call the .DataBind() method on the repeater object, and the view component is filled with the data inside.

The advantage of this approach is that it is simpler from the point of view of the developer; a couple of lines of code are usually enough. However, this design tends to break the MVC model, because it creates a direct dependency between the model and the view component. This coupling makes it hard to modify the model of the application without breaking the view layer.

In Objective-C this pattern is seldom used. Instead, an object will opt to let someone else do the job for them. That other object is known as the delegate object, and the methods to be implemented (sometimes optionally) are referred to as a protocol. In this model, there is a controller object that acts as intermediate between the view and the model, effectively creating a decoupled MVC architecture.

In Objective-C, an object tells the compiler that it implements a protocol using this syntax:

@interface MyAppDelegate : NSObject <UIApplicationDelegate>
@end

The inclusion of <UIApplicationDelegate> signals that this class conforms to the UIApplicationDelegate protocol. Meanwhile, in UIApplication.h, you will see this:

@protocol UIApplicationDelegate <NSObject>
@optional
- (void)applicationDidFinishLaunching:(UIApplication *)application;
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_3_0);
...
@end

Thus, MyAppDelegate.m may optionally respond to -applicationDidFinishLaunching: and -application:didFinishLaunchingWithOptions:. (In this particular case, be aware that the former method is used by apps prior to iOS 3.0, and that the latter method should now be used instead.)

More about Delegates

It is up to the class in question to determine when to call a delegate method, and in what order. This order is of particular interest when it comes to iOS Table Views. In fact, go ahead and press Cmd-Shift-O in Xcode right now. Search for and open UITableView.h.

Look inside. There’s a lot to take in here! In fact, that’s a good idea - take a moment to browse this header. (Go ahead. We’ll wait.) A Cocoa developer can write apps and never look once inside these header files. To borrow (abuse?) a classic Apple mantra, we code different. We want to get our hands dirty and look inside at the engine … or at least as much of it as possible. The instance variables are out of our reach, but there are plenty of other things to take in.

UITableView is unusual in that it declares two protocols, whereas most classes you come across will only declare one.

The UITableViewDelegate is responsible for mediating all table cell display and behavior. A quick look at the protocol makes this abundantly clear. There are methods covering custom display, variable height, headers and footers, accessories, selection, editing, reordering, and indentation.

@protocol UITableViewDelegate <NSObject, UIScrollViewDelegate>

UITableViewDataSource represents the data model object. While it supplies no information about appearance — of the cells or otherwise – this doesn’t mean it avoids cells altogether. There are methods covering cell view creation (and, more importantly, reuse), the number of sections and rows, titles for headers and footers, index titles along the right-hand side, plus cell editing, insertion, deletion, and moving.

In this protocol, two methods are required:

- (NSInteger)tableView:(UITableView *)table numberOfRowsInSection:(NSInteger)section;
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;

The rest are optional. That’s right, even -numberOfSectionsInTableView:, which you almost always see implemented like so:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return 1;
}

However, the header tells us that the default value is 1 if this is not implemented! If all you have is one section, save yourself some extra coding and leave it out. Aren’t well-documented header files great?

Now there has to be some degree of bootstrapping involved with setting up these delegates. This is accomplished via properties:

@property (nonatomic,assign) id <UITableViewDataSource> dataSource;
@property (nonatomic,assign) id <UITableViewDelegate>   delegate;

… and usually set to self:

// Set the table view and data source delegates:
myTableView.delegate = self;
myTableView.dataSource = self;

If you use a UITableViewController, this is done for you automagically, in addition to several other niceties. (We heart UITableViewController. Use it early. Use it often!)

Delegate Method Call Order

Great. So we have two delegate objects that can receive almost 30 method calls combined. Not five. Not ten. Thirty. Helpful as the delegate design pattern is, it’s easy to get confused knowing which method will be called at which time. Thus, it can also be instructive to know what order these methods are called.

You can probably guess a few of them right off the bat. For instance, -tableView:numberOfSections: is likely called before -tableView:numberOfRows:inSection:. It’s not always so clear cut, though.

So how do we trace Objective-C messages anyway? One possibility is to set up an Xcode breakpoint and declare this as an action (borrowed from StackOverflow):

while 1
printf "[%s %s]", (char *)object_getClassName($r0), (char *) $r1
c
end

Hmm … maybe not.

Is it possible to trace Objective-C messages en masse? As a matter of fact, it is:

On the iPhone Simulator, you can compile with the NSObjCMessageLoggingEnabled Foundation environment variable set to YES, then look in /tmp/msgSends-<pid> (where is your running app’s process id).

You’ll also get a deluge of messages, accent on deluge.

What else? You could use (the undocumented) -instrumentObjcMessageSends: to toggle logging on and off.

Hmm. This isn’t looking so good. “There’s got to be a better way!”

We can certainly drop breakpoints in each of our delegate methods and trace through them, but wouldn’t it be nice to just log the call order of our class delegates in one swell foop, without resorting to undocumented or cumbersome means?

Using an NSProxy

Of course there is. That’s why we wrote this blog post, after all, so we’re going to show you how it’s done. Best of all, you can use this technique for any class. Roll up your sleeves and let’s get started.

[This code is adapted from http://blog.jayway.com/2009/03/06/proxy-based-aop-for-cocoa-touch/]

Remember, we’re operating under the notion that you know your way around Xcode and have already built a project or two! In Xcode, create a new “Master-Detail” iOS Application called DelegateOrder. We’re going to use a PTV prefix for all of our classes (why? Long story

Thanks to the wonders of modern template technology, our root view controller happens to be a table view. How convenient!

Time to create a new class. Right-click on the Classes group in Xcode, and choose New File… from the popup menu. Add an Objective-C Cocoa Touch subclass of NSObject, and name it PTVControllerProxy. Open PTVControllerProxy.h and change it to look like this:

@interface PTVControllerProxy : NSProxy
+ (id<UITableViewDataSource, UITableViewDelegate>)proxyWithTableViewController:(UITableViewController *)controller;
- (id)initWithTableViewController:(UITableViewController *)controller;
@end

Notice anything different?

We have not so secretly replaced the NSObject Xcode usually serves with a dark, sparkling NSProxy object. (Footnote: This is a cultural reference to a famous Folgers coffee commercial that ran in the US in the ’80s. Not sure if it aired worldwide though!) Like NSObject, NSProxy is a root class, except it also conforms to NSObject, plus it adds a few methods of its own. Here’s the header:

#import <Foundation/NSObject.h>
@class NSMethodSignature, NSInvocation;
@interface NSProxy <NSObject> {
    Class   isa;
}
+ (id)alloc;
+ (id)allocWithZone:(NSZone *)zone;
+ (Class)class;
- (void)forwardInvocation:(NSInvocation *)invocation;
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel;
- (void)dealloc;
- (void)finalize;
- (NSString *)description;
+ (BOOL)respondsToSelector:(SEL)aSelector;
@end

NSProxy objects act as stand-ins for other objects. In our case, we’ll use PTVControllerProxy as our table view’s dataSource and delegate. It will also know about our actual Table View Controller (and table view) so that it can pass messages down the line.

The next item of interest is our private instance variable, _controller, a pointer to a UITableViewController object.

Following the Coding Guidelines for Cocoa, we always make our instance variables private. We also add a leading underscore — just like Apple does with their own headers — so as to distinguish them from properties. This further enforces class interaction through properties and methods. Meanwhile, on the implementation side, sometimes you want to access the instance variable. Other times, you need to use the property. Underscores make it clear which is which.

In this case, we’re not creating a property … at least not one that’s publicly available. More on that later.

We’ve also defined one class method and one instance method:

+ (id<UITableViewDataSource, UITableViewDelegate>)proxyWithTableViewController:(UITableViewController *)controller;

Our class method takes a UITableViewController and returns an object that conforms to both the Table View Data Source and Delegate protocols.

- (id)initWithTableViewController:(UITableViewController *)controller;

Our designated initializer method (called by the class method) does the deed of setting our controller property.

Did we mean _controller instance variable? No, we meant property. Now press Cmd-Option-Up-Arrow to switch to the implementation file and make it look like this:

#import "PTVControllerProxy.h"
@interface PTVControllerProxy ()
@property (nonatomic, assign) UITableViewController *controller;
- (void)logInvocation:(NSInvocation *)invocation;
@end
@implementation PTVControllerProxy
@synthesize controller = _controller;
@end

Ah-ha! So that’s where the property went.

We have included yet another interface declaration for PTVControllerProxy, and this time we’re extending it beyond what we originally declared in the header. The parentheses after @interface PTVControllerProxy signify that this is a class extension. In this case, we’ve declared a property and a method that isn’t exposed to the outside world. It’s not private per se, but it’s not visible in the header either. Next, in the implementation, we’ve synthesized a property named controller, which is represented by the instance variable named _controller.

Due to the architecture of Objective-C, you could make a few end-runs around this and still get at the property and methods. You just have to know how they’re defined. Be careful of doing this with Apple’s classes though. Them’s grounds for App Store rejection!

You can even override extensions previously defined in the header, making this technique quite handy for exposing readwrite properties as readonly. Read more about Categories and Extensions in The Objective-C Programming Language.

We’ll discuss -logInvocation: in a moment, but you probably have a good idea of what it will do just by looking at the name.

Time to add our methods. Heads up: Some of these may — or will — be a bit unfamiliar. All we are doing here is implementing the minimum number of methods to handle proxying for our table view controller, and then some.

The following should be added between @synthesize and @end in our class implementation. First, we add our previously defined initializers, and our lone NSObject method:

#pragma mark - Initializers
+ (id<UITableViewDataSource, UITableViewDelegate>)proxyWithTableViewController:(UITableViewController *)controller
{
    return [[[[self class] alloc] initWithTableViewController:controller] autorelease];
}
- (id)initWithTableViewController:(UITableViewController *)controller
{
    self.controller = controller;
    return self;
}
#pragma mark - NSObject
- (void)dealloc
{
    [_controller release];
    [super dealloc];
}

Our class method takes a table view controller and sends it along to the designated initializer, which in turn assigns it to the property controller, and returns itself. As there is no superclass to worry about, there is no use of [super init] here.

There’s one more benefit to our use of private instance variables beginning with underscores. Our method parameters do not conflict with like-named instance variables! Look at this line again:

self.controller = controller;

This dot notation is 100% equivalent to:

[self setController:controller];

Very clean, consistent, and easy to read. Contrast this with the scenario where our instance and method variable named matched. We would have to code methods like this:

- (id)initWithTableViewController:(UITableViewController *)theController
{
    self.controller = theController;
    return self;
}

It should also be pointed out that these method names are not haphazard. Apple does in fact provide a method (pun intended) for naming methods! The previously mentioned Coding Guidelines for Cocoa tells all. Take the time to name your instance variables, properties, and methods according to the guidelines. It’s worth the effort!

The dealloc method is also standard-issue. Notice that we work with the instance variable at this point. After dealloc, the show’s over for this class, so we don’t even bother setting _controller to nil. In other cases, you would likely want to clear it, using the property to take advantage of its retain/release smarts in one step:

// This setter (-setController:) releases _controller for us!
self.controller = nil;

Continuing with our NSObject methods, add the following:

- (BOOL)isKindOfClass:(Class)aClass;
{
    return [self.controller isKindOfClass:aClass];
}
- (BOOL)conformsToProtocol:(Protocol *)aProtocol;
{
    return [self.controller conformsToProtocol:aProtocol];
}
- (BOOL)respondsToSelector:(SEL)aSelector;
{
    return [self.controller respondsToSelector:aSelector];
}

Be careful here. There are class methods with the same signature like NSProxy’s +respondsToSelector:! We’re responding to NSObject’s protocol methods instead, passing (well, proxying) the parameter over to our table view controller. This takes care of establishing our proxy as having the same class, protocol conformance, and selector response. That, in turn, assures us an opportunity to tap in to the deluge of table view delegate traffic.

Now, so we just discussed how you can avoid naming collisions between method parameters and instance variables, and here we have aClass, aProtocol, and aSelector! This leads us to an important maxim: “You have to know the rules before you can break them.” Use discretion! Here, we’re honoring the naming convention established by the authors of NSObject.h, in particular the NSObject protocol.

As it turns out, the Protocol and Base Class declarations of -conformsToProtocol: are ever so slightly different:

// Protocol
- (BOOL)conformsToProtocol:(Protocol *)aProtocol;
// Base Class
+ (BOOL)conformsToProtocol:(Protocol *)protocol;

Go figure. (It’s OK. We still love Cocoa. Tasty Cocoa …)

Let’s add two more, slightly longer methods, this time from NSProxy’s protocol:

#pragma mark - NSProxy
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
{
    if ([self.controller respondsToSelector:aSelector])
    {
        return [self.controller methodSignatureForSelector:aSelector];
    }
    else
    {
        return [super methodSignatureForSelector:aSelector];
    }
}

Method signatures help us forward along messages we otherwise wouldn’t respond to. Here, the message is either bound for our table view controller or the superclass.

- (void)forwardInvocation:(NSInvocation *)invocation
{
    SEL selector = [invocation selector];
    if ([self.controller respondsToSelector:selector])
    {
        [self logInvocation:invocation];
        [invocation setTarget:self.controller];
        [invocation invoke];
    }
}

-forwardInvocation: is used by subclasses to send Objective-C messages-as-objects (or Invocations) to other objects. For the proxy, it’s just a matter of passing the message along to whatever object we aim to represent. That object, of course, is the table view controller.

First, we ensure the controller responses to the selector represented by the invocation. Then, just before we dispatch the invocation using -invoke, we call – ta-dah – our private -loginvocation: method. With that, we can now log every single solitary table view controller message that comes our way, all from one place.

Oh, and look, it’s invocation and not anInvocation. (You’re not going to let us live this one down, are you.)

At last, we come to the coup de grace of our controller proxy class. Add this to the implementation:

#pragma mark - Private
- (void)logInvocation:(NSInvocation *)invocation
{
    SEL selector = [invocation selector];
    NSString *currentMethod = NSStringFromSelector(selector);
    NSString *argument = @"";
    NSMethodSignature *methodSignature = [invocation methodSignature];
    NSInteger argCount = [methodSignature numberOfArguments];
    for (NSInteger index = 3; index < argCount; ++index)
    {
        const char *argType = [methodSignature getArgumentTypeAtIndex:index];
        if (strcmp(argType, "@") == 0)
        {
            id object = nil;
            [invocation getArgument:&object atIndex:index];
            if ([object isKindOfClass:[NSIndexPath class]])
            {
                NSIndexPath *indexPath = (NSIndexPath *)object;
                argument = [NSString stringWithFormat:@"{%d, %d}", indexPath.section, indexPath.row];
            }
        }
        else if (strcmp(argType, "i") == 0)
        {
            NSInteger section;
            [invocation getArgument:&section atIndex:index];
            argument = [NSString stringWithFormat:@"%d", section];
        }
    }
    NSLog(@"%@%@", currentMethod, argument);
}

OK! A lot to take in here. Let’s talk through it.

Just like in -forwardInvocation:, we grab our selector, or in this case our delegate message. In preparation for logging, we turn it into a string called currentMethod. This gives us, for example, @”tableView:cellForRowAtIndexPath:” – ready for logging.

Perhaps that would be enough, but we can do better. NSInvocation contains a NSMethodSignature object with all the arguments, so let’s grab a few of those while we’re at it.

If you were to look at the method signature’s arguments, you would soon discover the first two arguments are always claimed by a few behind-the-scenes players, (id)self and (SEL)_cmd. Argument indices are zero-based, so that places us at index 2 for the start of our delegate methods. Meanwhile, following best practices for delegate method conventions, the table view is always passed back as the first argument, in this case index 2. Thus we want to start at index 3, which should explain this loop construct:

for (NSInteger index = 3; index < argCount; ++index)
{
    const char *argType = [methodSignature getArgumentTypeAtIndex:index];
...

Next, we look at the argument type, returned as constant C string representing an Objective C argument type. “@” represents an object, and “i” represents an integer. Easy enough.

If we have an object, we check to see if it’s of class NSIndexPath. If so, good! We grab the index path’s row and section, and use that in the log message. If we have an integer, we simply grab the integer value instead.

What if we have no such argument, as in -numberOfSectionsInTableView? No worries, we’ll still log the message. We just won’t have any of these parameters to go along with it.

Finally, we log our method and our (possible) lone argument. At last, the controller proxy is complete.

We now turn our attention to our table view controller, represented here by PTVRootViewController. Open the header file first, and change it to look like this:

#import <UIKit/UIKit.h>
@interface PTVRootViewController : UITableViewController
{
@private
    id<UITableViewDataSource, UITableViewDelegate> _proxy;
}
@end

We’ve merely added a private instance variable for the proxy object. Notice that there is no publicly exposed property. We will only be using the proxy within the confines of the class.

Now switch to the implementation file and … remove everything. Nothing wrong with the pre-fab code here. We’re just going to start over. Add this for starters:

#import "PTVRootViewController.h"
#import "PTVControllerProxy.h"
static NSInteger SECTION_COUNT = 25;
static NSInteger ROW_COUNT = 5;

We first import our class header, as well as the proxy header. Next, because we’re testing out the proxy, we can keep the data source rather sparse and simple, but we still want a good number of rows and sections to work with. We define a few constants to this effect, giving us 25 table view sections, each one with five rows.

Time for another private extension:

@interface PTVRootViewController ()
@property (nonatomic, retain) id<UITableViewDataSource, UITableViewDelegate> proxy;
@end
@implementation PTVRootViewController
@synthesize proxy = _proxy;
@end

There it is, our internal proxy property, and a bare-bones implementation, complete with synthesized methods. Next up is our requisite NSObject method:

#pragma mark - NSObject
- (void)dealloc
{
    [_proxy release];
    [super dealloc];
}

Nothing earth-shattering there. Next up, a bunch of UIViewController methods:

#pragma mark - UIViewController
- (void)viewDidLoad
{
    [super viewDidLoad];
    self.proxy = [PTVControllerProxy proxyWithTableViewController:self];
    self.tableView.dataSource = self.proxy;
    self.tableView.delegate = self.proxy;
    self.title = @"Delegate Call Order";
    self.navigationItem.rightBarButtonItem = self.editButtonItem;
}

In -viewDidLoad, we create and connect the proxy object. We also take a moment to set the associated navigation bar’s title and add a stock edit button on the right side.

- (void)viewDidUnload
{
}
- (void)viewWillAppear:(BOOL)animated
{
    [super viewWillAppear:animated];
}
- (void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
}
- (void)viewWillDisappear:(BOOL)animated
{
    [super viewWillDisappear:animated];
}
- (void)viewDidDisappear:(BOOL)animated
{
    [super viewDidDisappear:animated];
}
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}

We’ll disable autorotation for now, so we only respond to portrait orientation requests.

- (void)didReceiveMemoryWarning
{
    [super didReceiveMemoryWarning];
}

At last! Time to add the delegate methods. All of them. That’s right, we will respond to every single one. In doing so, the proxy will get a chance to work its logging magic. Add the following for starters:

#pragma mark - UITableViewDataSource
- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return SECTION_COUNT;
}
- (NSArray *)sectionIndexTitlesForTableView:(UITableView *)tableView
{
    NSMutableArray *array = [NSMutableArray arrayWithCapacity:SECTION_COUNT];
    for (NSInteger index = 0; index < SECTION_COUNT; ++index)
    {
        NSString *sectionTitle = [NSString stringWithFormat:@"%d", index];
        [array addObject:sectionTitle];
    }
    return array;
}

Our table view has SECTION_COUNT sections. The section index titles (along the right side of the table view) will be represented by our section numbers 0 through 24. This will make it easy to see the effects of changing our vantage point.

Let’s add a few more:

- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
{
    return YES;
}
- (BOOL)tableView:(UITableView *)tableView canMoveRowAtIndexPath:(NSIndexPath *)indexPath
{
    return YES;
}

We allow editing and moving of all rows.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil)
    {
        cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
    }
    cell.textLabel.text = [NSString stringWithFormat:@"Section %d, row %d", indexPath.section, indexPath.row];
    return cell;
}

Here is where the cell generation and reuse takes place. Again, nothing surprising here. We take advantage of our table view’s cell queue and either dequeue or create a cell, setting its text label to the current cell’s section and row.

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath
{
    if (editingStyle == UITableViewCellEditingStyleDelete)
    {
        [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
    }
    else if (editingStyle == UITableViewCellEditingStyleInsert)
    {
    }
}

Since we’re allowing editing (and by editing we mean deletion of cells, not insertion), we’ll respond to this method as well, deleting the row indicated by the indexPath, fading it out as it goes.

- (void)tableView:(UITableView *)tableView moveRowAtIndexPath:(NSIndexPath *)fromIndexPath toIndexPath:(NSIndexPath *)toIndexPath
{
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    return ROW_COUNT;
}
- (NSInteger)tableView:(UITableView *)tableView sectionForSectionIndexTitle:(NSString *)title atIndex:(NSInteger)index
{
    return [title intValue];
}

We respond to -tableView:moveRowAtIndexPath:toIndexPath: as well. Since we aren’t manipulating any behind-the-scenes data, we don’t need to do anything extra. We also offer up ROW_COUNT rows in each section. Next, we take advantage of our section index titles (which are just numbers represented as strings), converting them back to integers as needed. index is meant to be used with our index title array, which of course we aren’t keeping track of. Then again, it’s simple enough that we don’t have to. Each index title maps directly to a like-numbered section in the table view, so it’s as simple as returning each title’s integer value.

Two more data source methods and we’re more than halfway there.

- (NSString *)tableView:(UITableView *)tableView titleForFooterInSection:(NSInteger)section
{
    return [NSString stringWithFormat:@"Footer for section %d", section];
}
- (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
{
    return [NSString stringWithFormat:@"Header for section %d", section];
}

Easy peasy, right? Good! Now for the table view delegate methods. These are even easier:

#pragma mark - UITableViewDelegate
- (void)tableView:(UITableView *)tableView accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath
{
}
- (void)tableView:(UITableView *)tableView didDeselectRowAtIndexPath:(NSIndexPath *)indexPath
{
}
- (void)tableView:(UITableView *)tableView didEndEditingRowAtIndexPath:(NSIndexPath *)indexPath
{
}
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    [self.tableView deselectRowAtIndexPath:indexPath animated:YES];
}
- (UITableViewCellEditingStyle)tableView:(UITableView *)tableView editingStyleForRowAtIndexPath:(NSIndexPath *)indexPath
{
    return UITableViewCellEditingStyleDelete;
}

A few more empty methods, again just to get the benefit of logging. We will also deselect each row in response to it being selected. Next, we assure that the editing style of each row supports deletion.

Now we’ll handle header, footer, and row sizing, plus indentation:

- (CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section
{
    return 20.0f;
}
- (CGFloat)tableView:(UITableView *)tableView heightForHeaderInSection:(NSInteger)section
{
    return 20.0f;
}
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    return 44.0f;
}
- (NSInteger)tableView:(UITableView *)tableView indentationLevelForRowAtIndexPath:(NSIndexPath *)indexPath
{
    return 0;
}
- (BOOL)tableView:(UITableView *)tableView shouldIndentWhileEditingRowAtIndexPath:(NSIndexPath *)indexPath
{
    return YES;
}

Returning YES for -tableView:shouldIndentWhileEditingRowAtIndexPath: allows the background of the edited row to be indented. This allows the cell contents to shift and more gracefully accomodate the Delete button appearing on the right-hand side.

- (NSIndexPath *)tableView:(UITableView *)tableView targetIndexPathForMoveFromRowAtIndexPath:(NSIndexPath *)sourceIndexPath toProposedIndexPath:(NSIndexPath *)proposedDestinationIndexPath
{
    return proposedDestinationIndexPath;
}

We won’t do anything unusual with proposed moving of cells, so we return the proposed destination index path.

- (NSString *)tableView:(UITableView *)tableView titleForDeleteConfirmationButtonForRowAtIndexPath:(NSIndexPath *)indexPath
{
    return @"Delete";
}
- (UIView *)tableView:(UITableView *)tableView viewForFooterInSection:(NSInteger)section
{
    return nil;
}
- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
{
    return nil;
}

The delete confirmation button will remain @”Delete”, and we won’t be using views for the section headers or footers. Still, we need to implement these methods if we are to see them logged!

Four more methods to go, and our implementation is finished:

- (void)tableView:(UITableView *)tableView willBeginEditingRowAtIndexPath:(NSIndexPath *)indexPath
{
}
- (NSIndexPath *)tableView:(UITableView *)tableView willDeselectRowAtIndexPath:(NSIndexPath *)indexPath
{
    return indexPath;
}
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath
{
}
- (NSIndexPath *)tableView:(UITableView *)tableView willSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    return indexPath;
}

Executing the Code

Congratulations! Let’s take it for a spin in the Simulator. Before building your project, bring up the debugger console window by typing Shift-Cmd-R or selecting Run > Console from the menu. Move the console off to the side so that you can see what happens next. You might even want to venture a guess as to which messages and parameters you’ll see first. Place your bets!

Now Build and Run your project using the Debug configuration. The Simulator will launch and the console will soon be filled with a bunch of log messages. Do not use the Simulator just yet. Let’s focus on the console.

Thankfully, they will only be concerning our table view controller delegates. (Otherwise, we would be positively buried with messages. You think this is a lot of messages, you should see what Objective-C deals with in a typical app’s lifetime!)

Let’s start at the top and see what we have here. (We have removed the timestamp and App specific info. Your log lines will be a bit lengthier by comparison. You might want to make the console window a bit wider to help keep the lines from wrapping.)

numberOfSectionsInTableView:
numberOfSectionsInTableView:

The first thing we’re asked for is the number of sections in our table view … and we’re asked for this information twice. (Your guess is as good as ours.)

Remember, we have 24 sections in our table view.

tableView:viewForHeaderInSection:24
tableView:titleForHeaderInSection:24
tableView:heightForHeaderInSection:24
tableView:heightForHeaderInSection:24
tableView:viewForFooterInSection:24
tableView:titleForFooterInSection:24
tableView:heightForFooterInSection:24
tableView:heightForFooterInSection:24

Next, we see a bunch of messages pertaining to one section, in this case section 24. First the headers, then the footers. Here we have two more examples of a twice-called method in -tableView:heightForHeaderInSection: and -tableView:heightForFooterInSection:.

So the order so far is as follows (eliminating duplicate invocations):

numberOfSectionsInTableView:

Then, for each section, the header and footer information:

tableView:viewForHeaderInSection:
tableView:titleForHeaderInSection:
tableView:heightForHeaderInSection:
tableView:viewForFooterInSection:
tableView:titleForFooterInSection:
tableView:heightForFooterInSection:

You can imagine that the title is not needed (and the relevant method not called) if a view is returned, so it makes sense that the view is asked for first.

Armed with our section count, the table view turns its attention to the rows, starting with … the last one?

tableView:numberOfRowsInSection:24
tableView:heightForRowAtIndexPath:{24, 0}
tableView:heightForRowAtIndexPath:{24, 1}
tableView:heightForRowAtIndexPath:{24, 2}
tableView:heightForRowAtIndexPath:{24, 3}
tableView:heightForRowAtIndexPath:{24, 4}

We have 5 rows in each section, which explains the index paths from {24, 0} through {24, 4}. The height is returned for each. So far, so good.

Now it would appear as if we’re starting at the end of the list and working our way backward, but the next thing you see is this:

tableView:viewForHeaderInSection:0
tableView:titleForHeaderInSection:0
tableView:heightForHeaderInSection:0
tableView:heightForHeaderInSection:0
tableView:viewForFooterInSection:0
tableView:titleForFooterInSection:0
tableView:heightForFooterInSection:0
tableView:heightForFooterInSection:0
tableView:numberOfRowsInSection:0
tableView:heightForRowAtIndexPath:{0, 0}
tableView:heightForRowAtIndexPath:{0, 1}
tableView:heightForRowAtIndexPath:{0, 2}
tableView:heightForRowAtIndexPath:{0, 3}
tableView:heightForRowAtIndexPath:{0, 4}

Is UITableView darting back and forth between the beginning and the end? (Answer: No. The next section it inquires about is section 1, all the way up to 23.) In fact, if you recompile this with only three sections, numbered 0 through 2, you’ll get a similar outcome with the section order: 2, 0, and 1.

So what’s happening here? Why does UITableView need to know about the last section first? [Note: Unknown! Any insights?]

sectionIndexTitlesForTableView:

Now that UITableView knows all the row heights, you shouldn’t see those called again unless the table is reloaded. That’s a good thing too because calculating those row heights can take some time, depending on the situation.

tableView:cellForRowAtIndexPath:{0, 0}
tableView:indentationLevelForRowAtIndexPath:{0, 0}
tableView:canEditRowAtIndexPath:{0, 0}
tableView:willDisplayCell:forRowAtIndexPath:{0, 0}

Next up are a series of four messages for each visible row, as well as those just out of view above and below. Since we’re at the start of the content area, we begin with index path {0, 0} and the messages are sent all the way through index path {1, 3}. The familiar -tableView:cellForRowAtIndexPath: is called first, followed by a request for the indentation level, and a check to see if the row is editable. Last comes -tableView:willDisplayCell:forRowAtIndexPath:. If you’ve read the documentation, you know this is your last chance to make final adjustments before a cell is displayed … and now we have proof!

tableView:viewForHeaderInSection:0
tableView:titleForHeaderInSection:0
tableView:viewForFooterInSection:0
tableView:titleForFooterInSection:0

Finally, we have a set of four different messages for the view (or, failing that, the title) for the header in each visible section. You probably know that headers are always visible, even when all of a given section’s rows are not. This holds true for section footers as well, only these are kept visible on the bottom of the view instead of the top.

In the Debugger console, press return a few times to add some blank space (or just press Clear Log in the toolbar). Now let’s try and scroll another screenful of rows into view and see what happens. Click and drag the bottom-most row up to the top until Section 2, row 4 is visible. Here’s what we get. Note that we have added blank lines in between each logical group of method invocations.

tableView:viewForHeaderInSection:0
tableView:titleForHeaderInSection:0
tableView:cellForRowAtIndexPath:{1, 4}
tableView:indentationLevelForRowAtIndexPath:{1, 4}
tableView:canEditRowAtIndexPath:{1, 4}
tableView:willDisplayCell:forRowAtIndexPath:{1, 4}
tableView:viewForFooterInSection:1
tableView:titleForFooterInSection:1
tableView:viewForHeaderInSection:2
tableView:titleForHeaderInSection:2
tableView:cellForRowAtIndexPath:{2, 0}
tableView:indentationLevelForRowAtIndexPath:{2, 0}
tableView:canEditRowAtIndexPath:{2, 0}
tableView:willDisplayCell:forRowAtIndexPath:{2, 0}
tableView:viewForFooterInSection:2
tableView:titleForFooterInSection:2
tableView:cellForRowAtIndexPath:{2, 1}
tableView:indentationLevelForRowAtIndexPath:{2, 1}
tableView:canEditRowAtIndexPath:{2, 1}
tableView:willDisplayCell:forRowAtIndexPath:{2, 1}
tableView:cellForRowAtIndexPath:{2, 2}
tableView:indentationLevelForRowAtIndexPath:{2, 2}
tableView:canEditRowAtIndexPath:{2, 2}
tableView:willDisplayCell:forRowAtIndexPath:{2, 2}
tableView:cellForRowAtIndexPath:{2, 3}
tableView:indentationLevelForRowAtIndexPath:{2, 3}
tableView:canEditRowAtIndexPath:{2, 3}
tableView:willDisplayCell:forRowAtIndexPath:{2, 3}
tableView:viewForHeaderInSection:1
tableView:titleForHeaderInSection:1
tableView:cellForRowAtIndexPath:{2, 4}
tableView:indentationLevelForRowAtIndexPath:{2, 4}
tableView:canEditRowAtIndexPath:{2, 4}
tableView:willDisplayCell:forRowAtIndexPath:{2, 4}

Of particular interest here are the header and footer related methods. They appear to be invoked in a rather odd pattern, until you examine the order that each header and footer appears on screen. Then it makes perfect sense. Interestingly enough, now that we’re on the move and have stopped at a definitive spot, we never see index path {3, 0} on the radar, which is just out of view, past the bottom.

What about editing? Add some blank space in your debugger, then tap the edit button.

tableView:canEditRowAtIndexPath:{1, 1}
tableView:editingStyleForRowAtIndexPath:{1, 1}
tableView:shouldIndentWhileEditingRowAtIndexPath:{1, 1}
tableView:canMoveRowAtIndexPath:{1, 1}

We’ve already seen -tableView:canEditRowAtIndexPath: invoked, just before our last chance to adjust the cell prior to display. Now it’s the first message in the group, followed by a few additional requests. The editing style is sought, followed by a request to indent the row while editing, and rounded out by an inquiry to see if the row can be moved.

Here’s another observation. Notice how index path {1, 1} seems to be out of view in our example, yet we see it being called here. This is repeated through index path {2, 4} which is just in view, but not index path {3, 0} which is just out of view once again. Why?

There is a good reason for this behavior. When a header and footer are covering up rows within their related section (that is, when the header or footer is pegged to the top or bottom of the visible part of the view), look for a little bit of transparency, letting the underlying cells show through. When a header is directly above the first cell in its section (or when a footer is directly below the last cell in its section), there are no underlying cells to show through. In our case, we know each section has a header and footer. Thus, there is no need for fetching adjacent section/row data until at least the next section’s header comes into view.

Let’s switch Section 1, rows 3 and 4. With the debugger console in view, tap and hold index path {1, 4}, just over the three bars (signifying a movable row). Drag it upward until it switches places with index path {1, 3} but don’t let go just. Observe the log:

tableView:targetIndexPathForMoveFromRowAtIndexPath:toProposedIndexPath:{1, 3}

Had we been logging this one more completely, it would have looked like this:

tableView:targetIndexPathForMoveFromRowAtIndexPath:{1, 4}toProposedIndexPath:{1, 3}

That’s all the table view needs to do. Now let go, and the move is complete:

tableView:moveRowAtIndexPath:toIndexPath:{1, 3}

Again, a more complete log would have shown:

tableView:moveRowAtIndexPath:{1, 4}toIndexPath:{1, 3}

Tap Done in the navigation bar, and we see this:

tableView:canEditRowAtIndexPath:{1, 1}
tableView:canEditRowAtIndexPath:{1, 2}
tableView:canEditRowAtIndexPath:{1, 3}
tableView:canEditRowAtIndexPath:{1, 4}
tableView:canEditRowAtIndexPath:{2, 0}
tableView:canEditRowAtIndexPath:{2, 1}
tableView:canEditRowAtIndexPath:{2, 2}
tableView:canEditRowAtIndexPath:{2, 3}
tableView:canEditRowAtIndexPath:{2, 4}

Terrific! Now what other mischief can we cause? Let’s delete section 2, row 1 (index path {2, 1}). Add some whitespace to the console, then tap edit once again, then the red circle at the left of the cell in section 2, row 1.

tableView:titleForDeleteConfirmationButtonForRowAtIndexPath:{2, 1}

Makes sense. The delete button appears (properly labeled). Now tap it to delete the row.

tableView:commitEditingStyle:forRowAtIndexPath:{2, 1}

First, we commit the editing style for index path {2, 1}. Then we effectively have a reloadData operation, which causes everything to be rechecked once again – headers, footers, row heights, the works. Only now we start at index path {0, 0} and run all the way clear through {24, 4}. So section 24 gets to go last this time!

Aaaand … the app crashes big-time.

 *** Assertion failure in -[UITableView _endCellAnimationsWithContext:], /SourceCache/UIKit_Sim/UIKit-1261.5/UITableView.m:920
 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid update: invalid number of rows in section 2.  The number of rows contained in an existing section after the update (5) must be equal to the number of rows contained in that section before the update (5), plus or minus the number of rows inserted or deleted from that section (0 inserted, 1 deleted).'

Wha happen? Well, our faux data model still thinks there are 24 sections of five rows each. Obviously that doesn’t match up with the table view’s reality. In short, “table view fall down go boom.”

Well, it was fun while it lasted Get the whole source code on Github and we hope it’ll be useful to you!

Similar Posts:

• Getting the Next and the Previous NSIndexPath Instances
• Objective-C Categories as Stylesheets
• Smart Pointers in Objective-C++
• A Proposed Architecture for Network-Bound iOS Apps
• How knowing C and C++ can help you write better iPhone apps, part 1

The problem is the following: let’s consider a relatively complex application, which has to connect to, and retrieve and send data from different remote resources (from the same origin or from different ones), all while handling as gracefully as possible different problems such as “network not available”, “500″ errors, etc, while at the same time notifying the app about showing popups, enabling and disabling fields, with many different screens (usually each with its own controller), and so on.

This article will describe in detail a solution for this problem using ASIHTTPRequest, my favorite HTTP library for iOS. The solution involves a bit of object oriented code, and there is a sample implementation in our Senbei project in Github that I am going to refer to in this article.

I want to point out that I do not consider this the “best” architecture by any means; it is simply a pattern or structure that has given me excellent results in many different applications, and which has evolved over time from many other approaches. If someone else has a better idea, I’d be glad to try it! This architecture also has the advantage of being easy to document, understand, maintain and extend.In the answer on StackOverflow I just enumerated the different elements of the architecture; here I will explain the rationale behind every decision.

Singleton, “Class Cluster”

As I said in the answer, this architecture involves a single object taking care of network connectivity, which I will call a “network manager”. Typically this object is a singleton (created using Matt Gallagher’s Cocoa singleton macro). Basically this is because it’s a good way to centralize all the network logic in a single component, and it is also a very common Cocoa design pattern.

This object can also be seen as a class cluster, because it uses an army of individual classes that perform the real work behind the scenes.

In Senbei, this singleton object is the SBNetworkManager class. All the controllers of the application use the methods of this class to trigger asynchronous requests to the remote FFCRM server used by the application. All of these controllers, as well as the application delegate, are notified of events by means of ad hoc notifications (defined in the SBNotifications.h file).

Network Queues

The network manager wraps an instance of ASINetworkQueue, and also acts as its delegate. Network queues are interesting in mobile apps, given that the available bandwidth varies drastically when the device is connected through a wifi connection or a low-speed GPRS mobile network. The network queue will automatically change the number of requests sent by unit of time depending on the current connectivity, without clogging the device.

In our example, SBNetworkManager has a private ivar (well, as private as Objective-C allows ivars to be) pointing to an instance of ASINetworkQueue, itself a subclass of NSOperationQueue.

One Subclass per Request

I create subclasses of ASIHTTPRequest for each kind of network request that my app requires (typically, for each backend REST interaction or SOAP endpoint).

I also create a base class for all the requests of the application; this allows to centralize some shared behavior in the base class, which proves handy while extending and refactoring your network code.

In our example, Senbei has a base class for all the GET requests in the application, called SBBaseRequest. There is another base request, called SBBaseFormDataRequest, which is used for requests that use the POST and PUT verbs (used to create and modify resources on the server).

There is also a category on ASIHTTPRequest, to add some methods to any request create on the system; this is required because SBBaseRequest inherits from ASIHTTPRequest, while SBFormDataRequest inherits from ASIHTTPFormDataRequest, which also inherits from ASIHTTPRequest. The category on the latter allows to inject some common behavior in a way that classic inheritance does not allow per se.

For every network interaction in the server, there is a dedicated class available for the SBNetworkManager; the code is easy to understand, and the responsibilities are separated and well defined. Should the system be extended in the future, the extension mechanism will naturally fit any new request, in a horizontal fashion.

The following class diagram (generated from the Xcode project using the excellent [OmniGraffle][9] application) shows how the system is structured (you can click the diagram to see a larger version).

Polymorphism to the Rescue

The network manager doesn’t know what to do with the result of each request; hence, it just calls a method on the request. Remember, requests are subclasses of ASIHTTPRequest, so you can just put the code that manages the result of the request (typically, deserialization of JSON or XML into real objects, triggering other network connections, updating Core Data stores, etc). Putting the code into each separate request subclass, using a polymorphic method with a common name accross request classes, makes it very easy to debug and manage them.

In our example, the SBNetworkManager calls the “processResponse” method in each subclass. This method has an empty implementation in our category for ASIHTTPRequest, and each individual subclass performs a different set of operations; some will parse XML, some will just post a notification; the separation of the logic in each subclass makes it easy to debug, document, maintain and extend the system.

Usage

Every time one of my controllers requires some data (refresh, viewDidAppear, etc), the network manager creates an instance of the required ASIHTTPRequest subclass, and then adds it to the queue.

Whenever a request finishes or fails, the network manager is called (remember, the network manager is the queue’s delegate). In turn, the network manager calls a method on the request itself, delegating the task of the processing of the response to each subclass.

In Senbei, every method of the SBNetworkManager class just creates an instance of a dedicated SBBaseRequest subclass, and pushes it into the wrapped network queue.

Notifications

The network manager notifies the controllers above about interesting events using notifications; using a delegate protocol is not a good idea, because in your app you typically have many controllers talking to your network manager, and notifications are more flexible.

However, as with always with notifications, using them requires planning, naming conventions and documentation. Code using notifications might be complex to maintain, because the dependencies are not obvious at first hand; that’s the price of their flexibility. In Senbei, notifications are all defined in the same file, so that different components can use the same constants throughout the application. The names of the notifications are clear and express the purpose and circumstance of each one.

Since iOS 4 there is also the possibility of using blocks as callback notifications, but then again, I think they just offer an alternative to delegate protocols; notifications are much more flexible, as many different objects can be notified of the same event (and receive the same information through userInfo dictionaries) at once.

Conclusion

This is how I’ve been writing many network-bound apps for the past few years, and frankly it has worked pretty well so far. I can extend the system horizontally, adding more ASIHTTPRequest subclasses as I need them, and the core of the network manager stays intact. The responsibilities is clearly separated, and the class and notification names give a pretty good idea of the purpose of each request.

One problem that I haven’t yet solved with this architecture (and one that a commenter of my StackOverflow answer points out) is finding a way to test the system; probably using mock objects, we could simulate different network conditions, and integrate this knowledge with automated tests.

I hope that this architecture is useful to you too! I look forward to read your comments below.

[9]:http://www.omnigroup.com/products/omnigraffle/Similar Posts:

• Senbei 1.3 hits the App Store!
• Our Open Source Projects
• initWithContentsOfURL: Methods Considered Harmful
• Introducing the Teaching Editor
• Objective-C Categories as Stylesheets

Some developers have gone the extra mile, though: we have kindly received two enhancements for the project!

• Jared Crawford contributed support for shadows in AKOCustomFontLabel back in March.
• Today, Christian Menschel from tapwork.de contributed the AKOMultiColumnTextViewDataSource protocol to add custom views in the text columns.

These contributions make the CoreTextWrapper a very interesting option to display rich, multi-column text on your iPad application! Thanks to Jared and Christian for the contributions, and don’t hesitate to send us your pull requests or your changes for us to integrate with the project. We would love to make your code part of this project.

Similar Posts:

• Core Text Objective-C Wrapper
• New Project Request Form
• digital2.0 iPad Application
• A Proposed Architecture for Network-Bound iOS Apps
• Integrating iOS Applications with Backend REST Services

I’ve talked about them in a previous article in this blog. In C++, a smart pointer will automatically call “delete” on the managed pointer when it goes out of scope, simplifying resource management and providing many more advantages over common pointers, as Andrei Alexandrescu explained in chapter 7 of his book “Modern C++ Design”.

In Objective-C, the “new” and “delete” keywords are replaced by some combination of “alloc / init”, “copy”, “release”, and “autorelease”. But given that Objective-C does not allow for stack allocation of objects (apart from blocks, but that’s another story), I’ve tried to create such a beast in Objective-C++. These are the features of my smart pointer:

• It takes ownership of any non-autoreleased object with a retain count of at least 1.
• It has value semantics, that is, it is copied by value from stack frame to stack frame, while the “owned” object, as any Objective-C entity, lives happily in the heap.
• When it goes out of scope, its destructor is called, which sends a “release” message to the owned object.

Here’s how you could use it:

for (NSInteger index = 0; index < 10; ++index)
{
    // A SmartPointer around an NSObject
    SmartPointer obj = SmartPointer::create();
    // SomeType is a typedef (see above)
    SomeType someObj = SomeType::create();
    // You can get access to the underlying Objective-C object
    // using "*", ".get()" or "()"; they all return the same pointer.
    // And once you have it, it's a normal Objective-C pointer
    // you can send messages to:
    SmartPointer array = [*someObj createArrayWithCapacity:5];
    // Here a SmartPointer around an NSNumber
    NSNumber *value = [[NSNumber alloc] initWithInt:1424];
    SmartPointer number = SmartPointer(value);
    // Playing with the array we got above, just to show it's a normal object
    [array.get() addObject:@"test1"];
    [*array      addObject:@"test2"];
    [*array      addObject:number()];
    [array()     addObject:*obj];
    // After this NSLog call, in the console you should see
    // "[SomeClass dealloc]" which is printed when the SmartPointer goes
    // out of scope, sending the release message on the underlying pointer.
    NSLog(@"array %@", *array);
}

In general, NSAutoreleasePools fit the bill quite comfortably in Objective-C for this kind of tasks, apart from some performance issues in iOS devices (particularly older iPhones and iPod touch devices), but I think there might be cases where just using a “non-autoreleased” approach to resource management might be useful, and typing an extra “[obj release]” line would be too much to ask

Of course, this is just an experiment, that I just publish as part of my own curiosity. I would be more than glad to hear some feedback about it from people more knowledgeable in Objective-C and C++ than I am. The code, as usual, is available in Github under a liberal BSD license. Enjoy!

Update, 2011-03-28: just found by pure chance another, much more complete, implementation of this idea (note to self: always Google first!) with its code in Github. Similar Posts:

• How knowing C and C++ can help you write better iPhone apps, part 1
• Core Text Objective-C Wrapper
• Determining Delegate Object Method Call Order in Objective-C with NSProxy
• Objective-C Categories as Stylesheets
• nib2objc updated

The obvious question being “why should I learn C if actually I have to use Objective-C to create my apps?”, and the answer “because Objective-C is a superset of C” is not really useful, albeit technically correct.

This series of two articles will provide some pointers (no pun intended) to answer that question, in the hopes that new iOS developers will get a copy of the K&R and the Stroustrup books soon.

Objective-C

Before starting with this article, I would like to remind my readers about some key facts of Objective-C, often overlooked by tutorials and teachers, and which explains much of the characteristics of Cocoa as well:

1. All methods (at instance and / or class level) are public, virtual and overridable. You can have @public, @private and @protected instance variables (also known as “ivars”), but methods are public. And yes, you can override class methods in subclasses, too, which is not a very common pattern (you can do that in C++ through templates, though). Polymorphism is the key to understanding Objective-C.
2. There is no formal concept of abstract classes. You can override the alloc and init methods of some class to avoid creating instances from it, but a priori, you can create an instance from almost any class.
3. You can have as many “root classes” as you want. You are not forced to inherit from NSObject, although in most cases that is what you do. In Cocoa there are two root classes already defined for developers to use: NSObject and NSProxy.
4. There is no concept of namespaces. That explains the prefix crazyness all over the place, because all classes live in the same planet, so you should better use a nice prefix for your stuff. In my case I usually publish my classes with the “AKO” prefix.

Stack and Heap

This is the probably the most important thing to know about iOS programming. Many developers, particularly those coming from Java, .NET, PHP or other garbage-collected environments, just don’t know that the computer memory used by applications is not a uniform space, and that running code uses space in three different, yet complementary, regions of memory, or as computer scientists refer to them, “segments”: the text, the stack and the heap.

The “text segment” is where the application code lives in memory while your application runs. Every instruction is there, every single function and procedure and method and executable code lives in that part of memory until your application exits. Usually you don’t really have to know anything about the text segment, other that it is there.

When the application starts, the main() function is called and some space is allocated in the “stack”. This is another segment of memory allocated for your application, and that’s where the memory required for the variables of your functions are allocated. Each time you call a function in your program, a section of the stack called a “frame” is allocated in the stack. The local variables of this new function are allocated there.

As the name implies, the stack is a “last in & first out” (or LIFO) structure, and when functions call other functions, stack frames are created; when those functions exit, their frames are destroyed automatically (that’s why stack objects are usually referred to as “automatic” objects). In your code, an “end” statement or a closing curly brackets “}” visually indicate a delimiter of stack context; when the current execution goes beyond that element, you can be sure that the stack frame is gone.

The stack region is at the origin of the “stack overflow” concept, which frequently happens when using recursive functions; you allocate too many frames, and you run out of space in the stack. Boom. Another interesting problem associated with stacks is that of “buffer overflows”, which constitutes one of the most common security problems caused by badly written C code. When you write memory contents in the stack, and you don’t check the size of your structures, you might end up writing something on the text segment… which basically means that you might as well be rewriting the code of the application, as it runs. Bad, very bad things can happen then.

Finally, the “heap” (also called the “data” segment) provides a storage medium that can last throughout the execution of functions; global and static variables live on the heap, until the application exits. To access whatever data you have created in the heap, you require at least one “pointer” on the stack, because that’s how your CPU can access data in the heap; through the stack. You can think of a pointer as just an integer variable that holds the number of a particular memory address in the heap (it is actually a bit more complicated, but that’s the basic picture).

To summarize: the CPU uses the value of the pointer in the stack to access or, as they say, “dereference”, the structure in the heap. Without pointer on the stack, no access to the object on the heap. And here lies the reason of all memory leaks: if you lose your pointer for whatever reason, then you have lost track of an object in the heap. And given that the heap is cleared only when your application exits, you have “leaked” memory, and you will never be able to recover it again (unless you restart your program, that is, but we don’t want to ask your user to quit and restart to solve that problem, do we?).

In C++ you can create objects in both the stack and the heap, and to know how to differentiate between both regions, you have to pay attention to the syntax used to create them:

// The variable does not use a "star"!
// Created on the stack, don't use "new"
SomeClass stackObject;
// do not call delete stackObject!!!
// Pay attention to the "star"...
// it's a pointer on the stack!
// We are initializing it to NULL,
// as a rule of thumb.
SomeClass *heapObject = NULL;
// And to create the object, use "new"
// to have it created on the heap
heapObject = new SomeClass;
// you must call this to avoid a leak!
delete heapObject;

In the case of the stack object, its destructor is called automatically when the stack frame is removed. In the case of the heap object, what goes away is the pointer variable in the stack… but not the object on the heap! To avoid that problem, in C you have to balance every malloc() (or calloc() or similar function) with a free(). In C++ you have to balance every call to “new” with a call to “delete”.

Now, imagine for a second that you have an object in the stack (an automatic object) that points to some other object in the heap, and that our first object is prepared to call the destructor of the second one. This is how the auto_ptr (or “smart pointer”) class of the standard C++ template library (STL) works; it takes advantage of the fact that variables on the stack are automatic. Instead of having to manage manually the lifecycle of your objects, an auto_ptr object on the stack will call delete automatically when it goes out of scope:

#include 
#include 
using namespace std;
int main(int argc, char **argv)
{
    // created on the heap
    SomeClass *heapObject = new SomeClass;
    // now the stackPointer owns the heapObject
    auto_ptr auto(heapObject);
    // Print non-NULL address of heapObject
    cout < < auto.get() << endl;
    // no need to call delete here!
    // "auto" is an stack object that
    // "owns" heapObject
    // (see below for a discussion
    // about ownership!)
    // and will call the destructor of heapObject
    // automatically when required. Magic!
}

How does all of this apply to Objective-C? Well, it turns out that the current versions of Objective-C only allow us to create objects on the heap. Apparently creating objects on the stack was possible in early versions of Objective-C, but that isn't the case anymore. All objects that you manipulate in Objective-C live in the heap (*), and as such, if you lose the pointer to them, you have a memory leak. Here goes some code in Objective-C with an obvious memory leak:

- (void)doSomething
{
    NSObject *obj = [[NSObject alloc] init];
    // do something else with obj...
    // and now we forget to release, and boom:
    // Memory leak! This is because the
    // "obj" pointer in the stack is lost
    // when this stack frame is removed...
    // ... but the heap object stays!
}

What can you do to avoid that? Two things:

1. Remember how in C you balance malloc() with free, and how you balance "new" with "delete" in C++? Well, in Objective-C you have to balance every call to "alloc", "copy" or "retain" with a "release".
2. You can also use the "autorelease" method, to add your object to the current autorelease pool, so that it will be automatically disposed of in the next iteration of the run loop cycle. OK, this is slightly more complex, but basically this also solves the memory leak problem.

Here goes some code illustrating the two solutions in detail:

// First solution
- (void)doSomething
{
    NSObject *obj = [[NSObject alloc] init];
    // do something else with obj...
    [obj release];
}
// Second solution
- (void)doSomething
{
    NSObject *obj = nil;
    obj = [[[NSObject alloc] init] autorelease];
    // do something else with obj...
    // Don't release obj! The object referenced
    // by that pointer will be disposed
    // in the next run loop iteration.
}

However, please, please, avoid the following code, which stretches the use of the autorelease pool to the level of abuse(**):

for (NSData *data in veryLargeArrayWithImages)
{
    UIImage *image = [UIImage imagedWithData:data];
    // do something with image
}

because this will create an unnecessary large number of instances that will remain in memory until the next run loop cycle (which will probably happen after the end of the current loop, that is, in a long CPU time in the future). Instead, either use a temporary autorelease pool, or use the non-autoreleased version of the code above (which I prefer, particularly in the iPhone):

for (NSData *data in veryLargeArrayWithImages)
{
    UIImage *image = [[UIImage alloc] initWithData:data];
    // do something with image
    [image release];
}

All of these memory management techniques are explained in detail in my article 10 iPhone Memory Management Tips.

Mike Ash has written an extensive article about stack and heap objects that will help you understand all of these issues even better. Finally, to see visually how the stack and the heap collaborate with each other, and how to keep an object-oriented mindset when writing code in C, I recommend watching on iTunesU the excellent Programming Paradigm course by professor Jerry Cain from Stanford University.

Object ownership

Ownership is a key concept in C++ memory management: whenever an object creates or copies another, the first one becomes the "owner" of the second. And as such, it is the task of the first one to destroy the second. Here goes some code that shows that pattern; here some class requires another one, and the ownership relationship is enforced throughout the lifetime of both objects.

// Forward declaration of some owned class
class Owned;
// Declaration of the owner
class OwnerClass : BaseClass
{
public:
    OwnerClass();
    virtual ~OwnerClass();
    const Owned& getOwnedObject();
private:
    Owned* _owned;
};
// Constructor implementation
OwnerClass::OwnerClass()
: BaseClass()
, _owned(new Owned)
{
}
// Destructor implementation
OwnerClass::~OwnerClass()
{
    delete _owned;
}
// Provide to clients a reference
// to the underlying owned object
const Owned& OwnerClass::getOwnedObject()
{
    return _owned;
}

In Objective-C, the chain of ownership is important to solve the problem of circular references; this is a common problem when creating delegation relationships between objects. When an object is delegate of another, the reference between the object and its delegate must be weak:

// A delegate protocol declaration
@protocol OwnedDelegate 
@optional
- (void)ownedObjectSaysSomething:(Owned *)owned;
@end
// Interface of the owner
@interface OwnerClass : NSObject 
{
@private
    Owned *_owned;
}
@property (nonatomic, retain) Owned *owned;
@end
// Interface of the owned
@interface Owned : NSObject
{
@private
    id _delegate;
}
@property (nonatomic, assign) id delegate;
@end

Pay attention at the @property declarations in the code above. The OwnerClass "retains" the Owned object, but the Owned class just "assigns" the delegate. This way, we know clearly who's responsible of releasing who: it is the OwnerClass dealloc method that will do that, and not the other way around!

@implementation OwnerClass
@synthesize owned = _owned;
- (id)init
{
    if (self = [super init])
    {
        _owned = [[Owned alloc] init];
        _owned.delegate = self;
    }
    return self;
}
- (void)dealloc
{
    _owned.delegate = nil;
    [_owned release];
    _owned = nil;
    [super dealloc];
}
#pragma mark -
#pragma mark OwnedDelegate protocol
- (void)ownedObjectSaysSomething:(Owned *)owned
{
    // do something now
}
@end

If you don't follow this pattern, you might end up with a circular reference, and the reference counting scheme of Objective-C won't be able to solve this problem, which means that you might end up leaking two instances at once!

free() vs. delete vs. dealloc

In C, free() is a function taking any pointer as parameter, and whose purpose is to mark the region of memory pointed by the parameter as available for the application. It is up to the application developer to pay attention to properly clean any owned objects in the structures stored in that region, as the standard C runtime makes no assumptions whatsoever about those secondary relations.

In C++, delete is an operator, and its task is to ultimately call the destructor of the target object, starting by the class of the current object, until it reaches the last class in the inheritance chain, and it does this immediately when called, in a synchronous fashion. Your constructors do not have to call the constructor of the base class in their implementation; it is, however, strongly recommended to mark your destructors as virtual, to ensure that the delete operator does this in all cases.

On the other hand, dealloc in Objective-C is a polymorphic, virtual, overridable method, not an operator neither a function, and it is never called directly by your code. It is called in a kind of asynchronous fashion, when the current run loop ends, and when the retain count of the current object reaches zero. This means that you might not know exactly when that happens, and actually, you shouldn't care. The important thing is to release all the things you were holding on to (see the "object ownership" section above).

Another important fact of dealloc is that, being polymorphic, only the implementation of the current class will be called, so you must always remember to add a call to [super dealloc] at the end of your own dealloc. And always, always add it at the end, not at the beginning, of your own dealloc.

Conclusion

I hope this information will be useful to developers new to the iOS platform. Objective-C and Cocoa share many characteristics with other similar platforms and frameworks written in C and C++, and developers working with garbage-collected runtimes are not used to know the layout of structures in memory. I think, however, that knowing this is useful also in such environments.

In the second part of this series I will dive into variable initialization, bitwise masks, functions and other related aspects of C and C++ programming, and how they relate to Objective-C.

Acknowledgement: Many thanks to Ariel Rodríguez for reviewing early drafts of this post.

(*) Well, that is not entirely true; there is one kind of Objective-C object that lives in the stack, and that is blocks. But this is an exception, one that I will tackle in a separate blog post.

(**) Autorelease pools are definitely material for another blog post.

Update, 2010-10-13: Ariel has written an excellent follow up to this article, explaining the problem of stack overflows. Similar Posts:

• Smart Pointers in Objective-C++
• Objective-C Categories as Stylesheets
• Core Text Objective-C Wrapper
• A Proposed Architecture for Network-Bound iOS Apps
• Determining Delegate Object Method Call Order in Objective-C with NSProxy

This project showcases different transport formats and libraries to consume web services from an iPhone application. It features a server application written in PHP, a command-line script that saves the output of the server application in different formats, and an iPhone client application (compatible with iPhone OS 3.0 and higher). The server application reads a MySQL database and outputs data in the following formats: HTML, JSON, YAML, XML (arbitrary format), SOAP, Property list (Binary and XML), CSV, and Protocol Buffers.

As promised, here go the slides and of course, check the project in Github which actually contains the real thing!

Although not everyone liked it (you definitely can’t please everyone) I’ve got good feedback from many other attendees and all in all I’m happy to have shared what I’ve learnt in this project. Feel free to fork the code and add support for other libraries and configurations! I’d love to receive feedback about this project. Similar Posts:

• Presentations at SDC 2011
• Talking at the Scandinavian Developer Conference 2011
• Introducing the Teaching Editor
• Trainings 2012: Advanced iOS, Mobile Web Apps and Node.js
• A Proposed Architecture for Network-Bound iOS Apps

First of all, a few warnings:

• I assume your current applications run in iPhone OS 3.1 as a minimum requirement. Apple does not accept any more applications targeting the 2.x frameworks these days, and the developer tools do not include those anymore.
• I assume your projects compile and link without warnings; many API calls have been deprecated between 2.x and 4.0, so you’d better have code using the latest methods and no deprecated ones.

Panorama

Waiting for an unification of the iPad and the iOS 4 frameworks (probably later this year), the current panorama of software and hardware iOS platforms looks as follows:

(ls): limited support, particularly for multitasking.

For practical purposes, I’ve omitted in the table above the fact that the iPhone 3G is (theoretically) able to run iOS 4. Something that has been empirically proved to be a bad idea.

Upgrading Xcode Projects to iOS 4

Your Xcode 3.1 iPhone project can be migrated to iOS 4 as follows:

• If you are using an SCM with branching support, create a new branch for all of the operations below; you don’t want to impact your “trunk”, or main branch with all these changes, as more urgent bugs might appear while you are doing this.
• Download the latest SDK from Apple. This is required by Apple, actually. And the latest version of Xcode (3.2.3 at the time of this writing) allows you to write applications compatible with all the platforms in the table above.
• Open your project with Xcode 3.2.3; select the “Project / Edit Project Settings…” menu and change the “Base SDK value to iPhone Device 4.0 (yes, even if your project is meant to target iPhone OS 3.1… stay with me!)

• In the “Targets” group of your Xcode project, open the “Info” panel, select the “Build” tab and change the “iPhone OS Deployment Target” entry for all the configurations of your target to “iPhone OS 3.1″. This will allow your code to be loaded in earlier versions of iOS, even if your application uses iOS 4 as a base SDK for all configurations:

• Set the UIKit framework, as well as any new framework provided by iOS 4, to link as “Weak”; for example, in the screenshot below, taken from the settings of my open source Senbei application, you can see that UIKit is weakly linked, as well as the MobileCoreServices framework (which does not exist in iPhone OS 3). This prevents the application from crashing at startup in versions of iOS earlier than 4, because newer versions of UIKit bring new classes and APIs that were not available before:

• Change your Entitlements.plist file, because iOS 4 applications submitted to the App Store require a new format in the Entitlements.plist file. In most cases, you can just delete the previous file, and create a new one from Xcode (“File / New File…”, then select “Code Signing / Entitlements” in the dialog that appears).

Old Entitlements.plist:

< !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">


    get-task-allow
    

New Entitlements.plist:

< !DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">


    
    application-identifier
    $(AppIdentifierPrefix)$(CFBundleIdentifier)
    keychain-access-groups
    
        $(AppIdentifierPrefix)$(CFBundleIdentifier)
    
    

• Update your icons and graphics for the new “Retina” display of the iPhone 4; Apple has published a special guide that provides all the information required in terms of sizes, formats and naming conventions.

After doing the steps above, you should have an application running on iPhone OS 3.1, 3.2 (as an iPhone application) and 4.0, offering exactly the same functionality and ready to be sent to the App Store.

Create a Universal iPhone and iPad application

Creating an iPad-compatible application from your iPhone app requires much more than just adapting your source code; the user experience of iPad apps is a completely different beast than that of iPhone apps, so I strongly recommend you ask a graphic and/or UX designer for help. I can’t stress this too much; iPad apps aren’t just “big” iPhone apps. They are much, much more.

Technically speaking, in the simplest of terms, you should be able to migrate most UIKit-based application following the standard path provided by Apple:

• Select your target in Xcode and choose the “Project / Upgrade Current Target for iPad…” menu.
• Use some compile-time and runtime tricks to get different parts of your code to execute in different environments, as explained by Jeff LaMarche:

#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 30200
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
        NSLog(@"iPad Idiom");
    else
#else
        NSLog(@"iPhone Idiom");
#endif

Testing your code in different devices

My advice is the following: don’t upgrade your old iPhone to iOS 4, particularly if you own a 3G. Keep it running under 3.1 and get the new iPhone 4 as soon as you can. This has two major advantages:

• You will be sure that there aren’t crashes or unexpected situations in iPhone OS 3.1, particularly when you are using new APIs in your code.
• The iPhone 3G and 3GS are slower than the new iPhone 4, but they are still (probably not for long) the most widely deployed, particularly in those countries where the iPhone 4 has not yet been released. This will help you create code that uses low memory, and that runs faster in newer models.

In my personal situation, I have my old iPhone 3G running iPhone OS 3.1.3, and a second generation iPod touch running iOS 4. And of course, my iPad runs iPhone OS 3.2.1.

Adapting your code for different platforms

Although Apple recommends using the UI_USER_INTERFACE_IDIOM macro, sometimes you need a tighter control in your code. For this, I have used three different techniques:

• Use a different class as the app delegate in your iPad application; instead of making your code a mess of “if” and “else” statements or preprocessor routines, make your iPad application create an instance of a different class, one that might or might not be a child class of the existing application delegate. This way, you can completely separate the code of both platforms, and each can load a different UI control hierarchy, without impacting the existing iPhone OS 3.1 or iOS 4.0 infrastructure.
  You can specify a different class for your iPad app delegate directly in your MainWindow-iPad.xib file, created for you when you selected the “Project / Upgrade Current Target for iPad…” menu (one more advantage of using Interface Builder files in your projects!):

• Check for symbols at runtime, taking advantage of the dynamic nature of Objective-C; for example, the code below only executes in iOS 4 or later, because the ADBannerView is not available in previous versions of the iPhone OS. This code will run without problems in iPhone OS 3.1! You can also use NSObject’s “respondToSelector:” method to perform runtime checks of the capabilities of your current platform, which might help you branch your code in different directions depending on the context:

- (void)showAdvertising
{
    Class klass = NSClassFromString(@"ADBannerView");
    if (klass)
    {
        ADBannerView *adView = [[ADBannerView alloc] initWithFrame:CGRectMake(0.0, 416.0, 320.0, 50.0)];
        adView.currentContentSizeIdentifier = ADBannerContentSizeIdentifier320x50;
        adView.delegate = self;
        [self.view addSubview:adView];
    }
}

• Include and use in your project the UIDevice extensions by Erica Sadun. This very handy set of categories provides a wealth of options, making your code much more readable and easier to understand. Most importantly, it is actively maintained by Erica, and this means that future versions of the categories will be able to detect more features of iOS.

Finally, MPMoviePlayerController requires special attention, because it’s widely used in many applications and also because it has been greatly improved (and changed) between iPhone OS 3.1, iPhone OS 3.2 and iOS 4. Those changes include, in some cases, deprecated APIs, so here I’ll just link to this excellent article by John Muchow in the iPhone Developer Tips blog, which explains all the problems and the possible solutions.

Conclusion

As you could see, creating universal apps is not easy, but it isn’t impossible either; it requires a bit of attention and lots of testing. Do you have any tips or links that you would like to share? Feel free to add more information in the comments below. Similar Posts:

• More nib2objc fun
• Core Text Objective-C Wrapper
• Dropping support for iPhone OS 3.x
• digital2.0 iPad Application
• Introducing the Teaching Editor