Blocks, are an interesting concept in Objective-C that can be used in many ways.  As a quick starter, if you’ve heard of or used “closures” or “anonymous functions” in other languages, you should get the feel of what they are any what they can do.  At the simplest level, they allow you to group multiple lines of code together which can be passed around your app with much the same flexibility as you might use simple variables.

So why is this useful?  Well, there’s many reasons but, in the attempt to make this a bit more readable, I’m going to go through a few use cases for blocks and hopefully, by the end, you’ll want to start optimizing your apps to make use of them.  But first, what’s a block look like?  This:

^{
	// some code here
}

Fairly simple.  The caret (^) defines a block and then curly braces contains it.  A slightly more complex example would be the following:

typedef int (^IntegerComparisonBlock)(int i, int j);
 
IntegerComparisonBlock whichIsGreaterBlock = ^ int (int i, int j) {
	return i > j ? i : j;
};
 
NSLog(@"%d", whichIsGreaterBlock(1, 3));  // 3

Firstly, I’ve created a type definition for a certain format of block which will be available as type IntegerComparisonBlock. Defined at the end of the typedef are the parameters IntegerComparisonBlock‘s will expect, separated by commas. These blocks will also return an integer which is defined at the start of the definition.

Ok so we’ve got a block type. Now to actually create one based on it. The second line does this and calls it whichIsGreaterBlock. Following the caret, the correct return type and parameters are defined and then a bit of useless code that just returns the larger of the two. The final NSLog statement shows how it can be used.

As useless as that example was, you should now have a grounding on what a block is and how to create one that has a return type and accepts typed parameters. Now onto that use case list I promised…

Using Blocks In Place Of Delegates

Because blocks allow pieces of code to be sent around your application as one, they can greatly lessen the amount of code required to have one class do something based on what’s happened in another. Creating custom protocols, defining a delegate object, firing commands at that object and then another class defining themselves as that object works great but is quite cumbersome when maybe you only want a small amount of code to be executed. This is where using blocks can cut down on code. All you have to do is instantiate the second class, pass it some code contained within a block which you want to be run when that class has done it’s thing and then the second class can just call that block by itself when it needs to. This reduces the connection between the two classes and does away with the delegate object. Here’s a diagram which illustrates the differences:

Using Blocks With Grand Central Dispatch (GCD)

This is more an example of where blocks need to be learned rather than how it can change your standard coding but if you plan to be running your code on multiple threads, you’ll most definately be looking into using the libdispatch library and if you do that, you’ll be using blocks. A lot.

Grand Central Dispatch is a blog post of it’s own, but to illustrate how to implement in-line blocks, the following, simple GCD example should give you a good idea:

myQueue = dispatch_queue_create("com.davidfox.myqueue", NULL);
dispatch_async(myQueue, ^{
                        [code to be run on another thread]
                        });

Writing Blocks In XCode 4

The syntax of blocks can be quite difficult to read at first. Writing your own can end up in a bit of messy trial-and-error to see what actually works. Additionally, things like writing your own blocks which are stored within a variable to be reused multiple times can be very wordy. However, if you’ve got XCode 4 installed, you’ll find some great code snippets in the snippets window which give you the skeleton code for writing different types of blocks. Try dragging a few into your code; it’ll clarify things further.

So, “When And Where?” has just gone live and it’s my first application to be submitted to the iTunes App Store.  All in all it took about 2-3 days of free time to put together, stress test and debug.

I thought it might be interesting to share some experiences about building an application like this…

Using Core Location And Web Services

The first thing I thought about that might cause some headaches was basically just working with external data and using the network. There’s lots of things to worry about and many different scenarios the iPhone might be in that would cause unwanted behaviour. What if the phone has no signal? What if Core Location can’t zone in to a particularly accurate approximation of the phone’s geographical location? If this application was going to be useful for a good range of users, from those using an iPhone like the latest O2 business phone to those who simply wanted a more convenient way to meet their friends, the app would have to be intelligent enough to accomodate the various situations the handset might be in.

Not only does not dealing with these issues result in an unpleasant user experience, it’s also grounds for your app being rejected by Apple.

In all circumstances, Apple’s documentation is generally top-notch.  Entering any API or class name into the documentation window in XCode brings up all the usual information but also, sample projects created by Apple to help out with things.  One such project which was very helpful was the “Reachability” project.  It demonstrates in a very concise way, how to detect whether a phone’s network is available and, separately, if they have a working Wi-Fi connection amongst other things.

Ok, so I’ve ran this code on application startup and an alert will be shown if there’s no connection.  But what about finding out the phone’s location and then displaying information about nearby places?  Well for the phone’s location, Apple’s built-in CLLocationManager class is super-easy to use.  Here’s a quick bit of code…

CLLocationManager *locationManager = [[CLLocationManager alloc] init];
[locationManager setDelegate:self];
[locationManager startUpdatingLocation];

I’m not going to go into too much detail, but these three lines of code create a location manager, set the containing class to it’s delegate and finally, just start trying to figure out where the device is.  Additional delegate methods are then defined, the most important one of which looks a little like this in my project…

- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation {
	if (newLocation.horizontalAccuracy <= kCLLocationAccuracyNearestTenMeters)
	{
		// we've got the device's location correct to the nearest 10 meters.  start searching for nearby places
	}
}

The above method will be called each time the location manager updates with it’s new value. However, you can see in my if-statement that I’m being quite picky and wanting to get the location correct to the nearest ten meters. That’s pretty tough for the iPhone to do and it could take some time, if it ever gets that close at all. If it doesn’t we’ll never get to a point where we can start searching. Because of this, it’s seriously important that when you tell the location manager to start updating, you also start a timer off that will, after a certain amount of time (10 seconds in my case), just ditch the location manager and do the search anyway using the best location the manager could come up with.

Ok, so we’ve got either a location that’s within 10-meters or thereabouts. How to use this to get the nearby bars, restaurants etc? Well I chose to use the Bing search API.  I’m sure Google’s API could do the job too and maybe an update will switch over to Google at some point in the future but Bing’s just seemed a bit more straightforward. For this, I use the NSOperationQueue. When I came to stress-testing and debugging, I was so glad I used this. One example would be that I might fire off a Bing search request for cafes in the area but then, the user might get tired of the wait and just come back to the main screen, check the About screen or just come out of the application. If they did that, the search would still be happening in the background and it’s complete events would be fired off even though we’re not interested in them any more. Dealing with this normally is obviously possible, but a bit messy. However, if you put functionality like this in an NSOperation and use NSOperationQueue to run it, you can automatically cancel individual or all of the operations in that queue with one line of code.

For information about using NSOperation and web services, check out my post on how Bit.ly was used.   This post goes into greater detail about the implementation of web services and although it’s a different operation, the principal execution is the same.

Sending Text Messages And E-Mail

So, the application has found the user’s location and the user has selected from a list, the location they’ll be meeting in. With all this data collated, I build a string up that will be sent to their friend but how to actually utilise in-app e-mail and SMS to send the thing? Well, there’s two libraries in the iOS environment which let you do this. One, “MFMessageComposeViewController” allows you to send SMS messages. The other which handles e-mail is “MFMailComposeViewController”. They’re both very similar in usage. You create an instance of the controller, set the delegate, set the recipients as an array, set content and/or body and then display it. Here’s the code When and Where? executes if the user picked a friend’s phone number…

MFMessageComposeViewController *smsComposeController = [[[MFMessageComposeViewController alloc] init] autorelease];
smsComposeController.body = userMessage;
smsComposeController.recipients = [NSArray arrayWithObject:[selectedDetails objectForKey:kMeetingDetailContact]];
smsComposeController.messageComposeDelegate = self;
[self presentModalViewController:smsComposeController animated:YES];

This is a direct copy-paste from my code so some variables are obviously missing. The interesting part is the last line… The panels which take over the screen when one of these controllers are displayed are called “Modal View Controllers”. The fact they take over the entire screen is what makes them “modal” and this is the approach that is happening in many apps, not just for messaging components, but also things like settings panels. Notable pieces of code above may be the use of the “kMeetingDetailContact” constant. Basically, a dictionary exists in this class which contains all the details a user has chosen (friend name, e-mail or phone number etc). Using a constant just makes sure I don’t make any typing errors. Also, you can see the MFMessageComposeViewController requires a delegate. This particular controller only includes one delegate method, “– messageComposeViewController:didFinishWithResult:” which will be called when the user has tapped “Send” or “Cancel”. In my code, I just dismiss the modal view and display an alert confirming the send.

Detecting No SMS On The iPod

The whole time I was developing this app, I was testing it on my iPhone 4 and my old iPhone 3GS (I purposely didn’t update my 3GS’s firmware so I could test my app on a device running an outdated iOS version). Everything was cool but then, all of a sudden, I thought about what would happen if the app was being run on an iPod or iPad. These devices don’t support SMS so what can I do? Luckily, the “MFMessageComposeViewController” class contains a static method called “canSendText”. If it returns false, the app knows it’s on a device that can’t send a text and so, the address book picker doesn’t display any phone numbers. An easy bit of code to add, but it’s a good example of how you really have to think outside the box sometimes and take into account just how many different types of device your app may run on and what circumstances the person may be running it in.

And That’s That

Well, the app is done and I’ve a few ideas for future versions but the main aim has always been to keep it simple. I use the app myself now and can see the merits of just 3 screens which can be tapped quickly whilst I’m standing in a bar with a pint and only one hand free. Consider your audience when you’re making your app and remember that the iPhone itself is all about ease of use and core functionality so don’t bloat it with anything it really doesn’t need. Thanks for taking the time to read and if you have any requests for any other info I haven’t mentioned, drop a comment below and I’ll update.

As an Actionscript developer, it’s the new language features in Objective-C that interest me the most about iPhone development. One feature I’m loving is something called categories.

Essentially, categories allow the programmer to add additional methods to an already-existing class without subclassing it. When coding, these newly created methods are available on the existing object already and as a result, these new methods can be called on instances of that object type.

An Actionscript developer may typically create these types of methods in a separate file declared as static functions. One major difference is that the methods have to be referred to on the class where they were declared. For example, here’s a couple of functions that convert radians to degrees and vice versa…

public static function degreesToRadians(degrees : Number) : Number
{
return degrees * (Math.PI / 180);
}
 
public static function radiansToDegrees(radians : Number) : Number
{
return radians * (180 / Math.PI);
}

So we would typically put these in a separate class (let’s call it MathUtils) and when we want to use them, call MathUtils.degreesToRadians(180). Now, let’s look at how this could be implemented in Objective-C using a custom category…

NSNumber+MathUtils.h

#import <Foundation/Foundation.h>
 
@interface NSNumber (MathUtilities)
 
- (float) toRadians;
- (float) toDegrees;
 
@end

NSNumber+MathUtils.m

#import "NSNumber+MathUtils.h"
 
@implementation NSNumber (MathUtilities)
 
- (float) toRadians
{
	return [self floatValue] * (M_PI / 180);
}
 
- (float) toDegrees
{
	return [self floatValue] * (180 / M_PI);
}
 
@end

The key things here are that when we are defining the interface type on the second line of our interface, we’re defining it’s the already-existing type “NSNumber”. You’ll notice the “(MathUtilities)” after this declaration; this is purely an arbitrary identifier. The only other thing are the two method definitions for converting to radians and degrees.

In the implementation (.m) file, we define the functions that will convert to radians and degrees. However, the main thing here is the use of “self”. Because this is a category and is sitting on top of any NSNumber instances you create, “self” actually refers to the object it’s called on. Here’s an example of it in use…

NSNumber *myDegrees = [NSNumber numberWithFloat:180];
NSLog(@"Radians: %.2f", [myDegrees toRadians]);

We have an NSNumber and then in the NSLog line, we can just call “toRadians” on that object. Now this is a pretty straightforward example. More useful categories would be things like shuffling an array etc. I find it nice to work with although it’s a bit difficult to pick up some code and actually know what categories have been created and are available. Still though, it’s a cool feature…

When starting out with external data in iPhone projects, I think most programmers’ first port of call will be the plist format. It’s brilliant; data is stored in it’s native format and when loaded (which is ridiculously easy), it comes in in the same format it was created. However, the formats you can use for data in a plist are restricted. Also, if you have one with a deep hierarchy, loading, updating and saving them not only becomes complex, but also takes longer to process.

Up steps archiving. It’s fast, flexible and is tied into your model so there’s no need to keep referring to plist’s to make sure you’re parsing at the right level and no hard-to-track bugs when your model changes. It also allows data to be saved and loaded in any format so it’s great for saving out entire value objects in their correct format.
Continue Reading