So it is time for Apple’s first Keynote of the year (or do we count the educational event in January? … it did show up in the Keynote Podcast Feed after all), and the one prediction that everyone seems to be agreeing upon is that we will see the unveiling of the iPad 3, but what will be new…

iPad 3

Retina Display

The iPad 3 will have a 2048×1536 Retina Display (4 times as many pixels as the iPad 2′s display), meaning that text will be sharp and crisp and your be able to watch 1080p videos with (quite a lot of) pixels to spare. To put this into perspective, the 27″ iMac has a resolution of 2560×1440, which means the iPad will actually have more lines on the screen than the 27″ iMac. There is an unfortunate side effect of the iPad getting a Retina Display, and that is applications will probably increase in size with all of the iPad @2x images.

A6 Quad Core Processor

One thing that we know for sure is that the iPad 3 will need quite a bit of a speed bump to push all those pixels around the screen, but will it be a newer Dual Core A5 or a Quad Core A6 Processor? One of the rumors is that the iPad 3 will be slightly thicker than its predecessor, and I think this is to accommodate a bigger battery for a Quad Core Processor.

Improved Camera

The iPhone 4S’s camera is the one of best cameras that you will find on a smartphone, the iPad 2′s camera on the other hand is probably not as good as the original iPhone’s. The Retina Display would emphasise how bad the cameras are on the iPad, so I expect Apple to bump the spec of both of the cameras so that they can at least both record video at 1080p.

LTE

It is early days for LTE, but I don’t think that there is any doubt that it will be the standard for the next few years, and unlike CDMA this will include outside of the US too. Maybe LTE is why the iPad 3 will put on a few pounds?

What else?

AppleTV 3

Continuing on the theme of 1080p, I think that we will finally get an AppleTV that is able to play 1080p videos which will also mean…

1080p iTunes Videos

I think Apple will start selling 1080p videos, which means that they are (theoretically) the same quality as Bluray. This means that videophiles will have nothing left to complain about… unless they still have a dial up internet connection as those video files will be huge.

What we won’t see

Thunderbolt Syncing

Am I the only person who still syncs their iPad using a USB cable? Hopefully I am not, but it would be good if you could sync your iPad in seconds over Thunderbolt. Unfortunately I don’t even think Apple will be adding to the tiny (mini? … nano?) list of device that currently uses Thunderbolt.

128 GB of Storage

With 1080p Videos and Retina apps everyone would like a bit more storage wouldn’t they?

iOS 6

I don’t think we are too far away from the developer preview of iOS 6, but I think that Apple will have an event just for iOS 6 (especially if it is a major release).

The latest version of Xcode ships with LLVM 3.0 as it’s default compiler, and one of the first things that you will notice is that is a lot more thorough when it analyses your code compared to previous versions (which can only be a good thing). One thing that the static analyser now warns you about, is that you are over releasing objects that are returned from prefixed intalizer methods (init), such as in a category (for my previous posts on categories see here and here).

For example my NSString category has the following method:

- (id)MCSM_initWithComponents:(NSArray *)components 
seperatedByString:(NSString *)seperator;

And it’s implementation looks like this:

 
- (id)MCSM_initWithComponents:(NSArray *)components 
seperatedByString:(NSString *)seperator{
 
    NSMutableString *componentizedString = [NSMutableString string];
 
    NSUInteger i = 0;
    for(NSString *component in components){
 
        if(i == 0)
        {
            [componentizedString appendString:component];
        }else{
            [componentizedString appendFormat:@"%@%@",seperator,component];
        }
 
        i++;
 
    }
    return [self initWithString:componentizedString];
}

This method takes an array of strings, and joins together using the separator parameter and can be used in the following way:

 
NSString *string = nil;
NSArray *components = [NSArray arrayWithObjects:@"one",@"two",nil]; 
string = [[NSString alloc] MCSM_initWithComponents:components seperatedByString:@","];
NSLog(@"%@",string);
[string release];

This would output:

one,two

As this method is in a category of NSString I don’t want it to clash with any other implementations. The common practise in Objective-C is to prefix categories methods (due to the lack of namespaces), so I have with MCSM_. The issue is that the static analyser will now think that this method returns an autoreleased object, as the method does not begin with init, new, copy or alloc. This means when you release the object the static analyser will complain about you over releasing an object.

So how do you fix this?

To fix this you can tell the compiler that the method returns a retained object by using the source annotation NS_RETURNS_RETAINED, which means your interface would look like the following:

 
- (id)MCSM_initWithComponents:(NSArray *)components 
seperatedByString:(NSString *)seperator NS_RETURNS_RETAINED;

Instead of NS_RETURNS_RETAINED you can also use __attribute__((ns_returns_retained)), which is a longer way of writing the same thing:

- (id)MCSM_initWithComponents:(NSArray *)components 
seperatedByString:(NSString *)seperator __attribute__((ns_returns_retained));

So thats all fixed? Unfortunately not quite yet. The static analyser will now complain about a memory leak, as we have allocated a NSString by doing [NSString alloc], but then it isn’t referenced again in our code. For a method that begins with init, the static analyser knows that the method consumes the variable (which means it releases the parameter upon completion), and that is the behaviour we need.

To do this we have to use the source annotation __attribute__((ns_consumes_self)) in conjunction __attribute__((ns_returns_retained)), which means your interface will look like:

- (id)MCSM_initWithComponents:(NSArray *)components 
seperatedByString:(NSString *)seperator __attribute__((ns_consumes_self))__attribute__((ns_returns_retained));

And that will fix it.

Summary:

You don’t need to use the source annotations if your code obeys the Objective-C naming conventions, but in certain circumstances like the one above you need to help the Static Analyser do its job. As LLVM forms the the backbone of Automatic Reference Counting (ARC), you still need to do this even if your not retaining and releasing memory yourself.

So after months of waiting, Mac 10.7 has finally been released to the general public. Although it has been given some minor spit and polish on the UI front when compared to it’s predecessor Mac OS 10.6, most of the improvements are under the hood. Thankfully the majority of these changes have been made available to developers in the form of APIs. With that in mind I thought I would point out some of my favourite new APIs that I have been using in the developer previews.

NSPopover

NSPopover works a lot like UIPopoverController on iOS. You give an NSPopover an instance of NSViewController (or one of your subclasses), and you can then present this view controller in a popover.

- (IBAction)showPopoverFromButton:(id)sender
{
//Create the popover
popover = [[NSPopover alloc] init];
 
//Set the content view controller
popover.contentViewController = popoverViewController;
 
popover.animates = YES;
 
//So we get told when the popover has closed
popover.delegate = (id<NSPopoverDelegate>)self;
 
[popover showRelativeToRect:[sender bounds] 
ofView:sender 
preferredEdge:NSMaxYEdge];
}

The APIs for NSPopover are nice and simple, but in true Mac OS fashion the delegate callbacks take the form of NSNotifications rather than selectors.

- (void)popoverDidClose:(NSNotification *)notification
{
if([notification.object isEqualTo:popover])
{
   [popover release]; popover = nil; 
}
}

If you need to implement something like NSPopover in previous versions of Mac OS, then I recommend taking a look at MAAttatchedWindow.

CoreData

CoreData has had so many updates in Mac OS Lion it is hard to know where to start. Most of the API changes are to incorporate features that are needed to support Versions and iCloud Syncing. What this means is when you modify files Versions and iCloud only want to know the changes that have been made to a file, so they only need to store or transfer the differences between the original and the new file. This approach not only saves space (only the changes are stored, not another whole file), and it also means the versions of the file can easily be compared and contrasted (I am guessing that Apple uses GIT for this). If your application persists any data (and who’s doesn’t?), then you must look at CoreData as it gives you so many things for free.

NSOrderedSet

An ordered set, isn’t that just an array? Well in reality it is, it is an array that makes sure that the objects that it holds are unique and therefore not duplicated. That in itself isn’t that exciting, but what is exciting is that it allows you to have ordered Core Data relationships by simply ticking a box. These ordered relationships do incur a performance penalty over non ordered relationship, so don’t use them for the sake of it.

Concurrency

One of the major issues with CoreData is that NSManagedObjectContexts and therefore the NSManagedObjects that it contains, are not thread safe. In Lion NSManagedObjectContext has the initialiser method initWithConcurrencyType, which allows you to tell an NSManagedObjectContext to mange all of it’s interactions using its own private dispatch queue. This means by using Grand Central Dispatch you can reduce the complexity of concurrency when using CoreData in Mac OS 10.7.

Full Screen Windows

The full screen APIs are incredibly simple to implement (as long as your window resizes to the size of a user’s screen).

All you need to do is set the window’s collection behaviour to support full screen:

[window setCollectionBehavior:NSWindowCollectionBehaviorFullScreenPrimary];

This one line of code gives you the “full screen button” in the top right hand corner of the window.

If you want to make the window go full screen yourself, you just need to call the toggleFullScreen method on NSWindow:

[window toggleFullScreen:nil];

View based Table Views

My favourite new class is without a doubt NSTableCellView, as it allows you to use a (subclass of) NSView as a table view cell, rather than an NSCell (which is my least favourite class if you are asking). This makes things a lot easier to build custom UIs in a table cell, and also means it can have subviews such as NSButtons that can receive mouse events.

The two data source methods you must implement are:

- (NSInteger)numberOfRowsInTableView:(NSTableView *)aTableView;
 
- (NSView *)tableView:(NSTableView *)aTableView viewForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row;

Although this makes NSTableView a lot more like UITableView it is important to note that NSTableView doesn’t support sections (as you may have guessed by the numberOfRowsInTableView method not being called numberOfSectionsInTableView). To make things slightly more confusing, NSTableView does however support group rows. Group rows float above the non group rows below it, which means they behave like iOS section headers.

You can tell the table view that a cell is a group row by using the delegate method:

- (BOOL)tableView:(NSTableView *)tableView isGroupRow:(NSInteger)row;

If you are creating a custom NSTableCellView in code, don’t forget you can override isFlipped to flip the coordinate system and make it like the iOS co-ordinate system.

Also don’t forget that as NSOutlineView is a subclass NSTableView, so it also supports view based cells.

In App Purchase

In App Purchase for iOS has been in the press for all the wrong reasons recently, but it is a great API for Mac OS X developers to have, so they can unlock different features in their applications. The API is very similar to it’s iOS counterpart besides when it comes to receipt validation. For more information on this I recommend watching the WWDC session 510, which is all about In App Purchase.

Push Notifications

Another feature ported across from iOS, but this time with less features. On Mac OS push notifications can only contain a badge value and not an alert and/or sound.

So thats a wrap up of my favourite new APIs in Lion, the standout ones for me being View Based Table Views and NSPopover. There have been so many updates I recommend looking through the change list, as you never know what you might find.

This post has been a long time coming, mainly because I cannot claim that I done any of the work to make it possible, for that I have to thank the Big Nerd Ranch and Landon Fuller. Nevertheless, I have found the following category so useful that I thought I would do a post on it anyway.

When I first started using blocks, I thought “I have this block of code, can’t I just run it on a given thread?”. The answer is (thankfully) yes, but Apple don’t supply a simple API to do this in Mac OS or iOS. The category below solves this issue:

@implementation NSThread (MCSMNSThreadCategory)
 
+ (void)MCSM_performBlockOnMainThread:(void (^)())block{
	[[NSThread mainThread] MCSM_performBlock:block];
}
 
+ (void)MCSM_performBlockInBackground:(void (^)())block{
	[NSThread performSelectorInBackground:@selector(MCSM_runBlock:)
						      withObject:[[block copy] autorelease]];
}
 
+ (void)MCSM_runBlock:(void (^)())block{
	block();
}
 
 
- (void)MCSM_performBlock:(void (^)())block{
 
	if ([[NSThread currentThread] isEqual:self])
	block();
	else
	[self MCSM_performBlock:block waitUntilDone:NO];
}
- (void)MCSM_performBlock:(void (^)())block waitUntilDone:(BOOL)wait{
 
	[NSThread performSelector:@selector(MCSM_runBlock:)
					 onThread:self
				   withObject:[[block copy] autorelease]
				waitUntilDone:wait];
}
 
- (void)MCSM_performBlock:(void (^)())block afterDelay:(NSTimeInterval)delay{
 
	[self performSelector:@selector(MCSM_performBlock:) 
			   withObject:[[block copy] autorelease] 
			afterDelay:delay];
}
 
@end

This category adds a set of (simple) methods to the NSThread class, that allows you to run a block on any thread that you have a reference to. (You may notice that the Big Nerd Ranch prefix their category methods with BNR and I use MCSM, this is due to Objective-C not supporting namespaces).

For more information on blocks, see Apple’s Blocks Programming Topics documentation.

Alongside blocks Apple introduced Grand Central Dispatch (GCD) in Mac OS 10.6, and I suggest that anyone implementing processor intensive tasks that require code to be executed off of the main thread should try and implement their code using GCD. That being said there are situations (predominantly due to the use of legacy APIs/libraries) whereby the use of a dedicated thread is still required.

Say you have a network thread (networkThread), and on this thread is network socket which is maintaining a persistent connection to a server, and a parser for the data that is received on that socket. (There is a common mistake I see, whereby programmers do the network I/O off of the main thread but still parse the data on the main thread, thus locking up the application’s UI when the data is being parsed).

Normally the data you want to send over the network originates from something that has been triggered from the application’s UI, and therefore the main thread. You then need to get this data onto the network thread so it can be sent.

Say you wanted to send a person’s first name (firstName), last name (lastName) and company name (companyName) over the network.

Ideally you would have a method that looked something like:

- (void)sendFirstName:(NSString *)firstName 
lastName:(NSString *)lastName 
companyName:(NSString *)companyName;

This method would convert the data into a format that can be sent over the network (e.g. XML, JSON etc), and queue it on the socket for sending.

The issue is if two threads try to use the same socket at the same time your application will crash, so this method can only ever be called from the networkThread. This is also relevant for other non-thread safe APIs.

So for this example we will rename it to:

- (void)onNetworkThreadSendFirstName:(NSString *)firstName 
 lastName:(NSString *)lastName 
companyName:(NSString *)companyName;

and keep the original method for use on the main thread.

So how do you call a method on another thread?
Well you can’t directly, you have to use:

- (void)performSelector:(SEL)selector 
 onThread:(NSThread *)thread 
 withObject:(id)object 
 waitUntilDone:(BOOL)wait;

The only problem with this is that the selector you call can only take one argument (using the withObject parameter), and in this example we want to pass 3.

So what we need to do is put all of the arguments into one object. You could do this using an array (you would need a fixed amount of arguments to do this), a custom object (overkill if it is only going to be used as an argument to a method) or a dictionary which is what I will be using.

- (void)onNetworkThreadSendArguments:(NSDictionary *)arguments;

This means that you would end up with an implementation such as the following:

 
- (void)sendFirstName:(NSString *)firstName 
 lastName:(NSString *)lastName 
 companyName:(NSString *)companyName{
 
NSDictionary *arguments = [NSDictionary dictionaryWithObjectsAndKeys:
firstName,@"firstName",
lastName,@"lastName",
companyName,@"companyName",nil];
 
[self 
performSelector:@selector(onNetworkThreadSendArguments:) 
onThread:networkThread 
withObject:arguments 
waitUntilDone:NO];
 
}
 
- (void)onNetworkThreadSendArguments:(NSDictionary *)arguments{
 
NSString *firstName = [arguments objectForKey:@"firstName"];
NSString *lastName = [arguments objectForKey:@"lastName"];
NSString *companyName = [arguments objectForKey:@"companyName"];
 
[self 
onNetworkThreadSendFirstName:firstName
lastName:lastName
companyName:companyName];
}
 
- (void)onNetworkThreadSendFirstName:(NSString *)firstName 
lastName:(NSString *)lastName 
companyName:(NSString *)companyName{
	//format and send data
}

So before 10.6 this technique would be common practise, but it means you have to write extra methods to pack and unpack arguments for cross thread calls.

Thankfully we can get this down to 1 method call using our block category on NSThread:

 
- (void)sendFirstName:(NSString *)firstName 
 lastName:(NSString *)lastName 
 companyName:(NSString *)companyName{
 
	[networkThread MCSM_performBlock:^{
		//format and send data
	}];
}

As the block of code is always executed on the network thread, this method can be called from any thread. As you can see blocks can be very useful even when used without Grand Central Dispatch.

This category is available on github here.