When you start a new application you probably have a list of features and a sketch of what you think/hope/wish the 1.0 version of your application will look like. As an indie developer you are the only one that knows exactly what is on this list, but you often feel like you can’t release an application until the whole list is completed, even though nobody else would be any the wiser.

The other major difference about a 1.0 version of an application is the lack of immediate pressure to release it. When you have released an application you are often pressured into releasing an update for a new feature or simply to fix some bugs. As an indie developer the only pressure you get is from yourself (and I try not to moan at me too often).

So over a week ago I finally decided my baby was ready to see the world, so I sent off the 1.0 version of my application Actionify to Apple and waited for it to go through the review process. To my pleasant surprise there was no problems first time round (Apple usually find something) and Actionify was released on Friday. Actionify is a GTD inspired Task Manager, that also offers a cloud sync subscription that allows users to collaborate on Projects. If you want to know more about it, you can click on the link here, but I won’t overload this post info. I am very pleased with how Actionify has turned out, the 1.0 misses a few features from my original list but also some additions that I added due to the feedback I received during the beta testing (thank you testers!!!). Inevitable it took longer than I had originally hoped, but this was mainly down to me underestimating the amount of effort and paperwork it took to set up a limited company (in the UK) and everything that goes with that (e.g. Banking, Transferring my iTunes Connect Account etc etc). In terms of development time the project probably only over run by 1 or 2 months, while this is not ideal, it isn’t to bad either.

In terms of technology, Actionify requires Mac OS 10.7 as the UI is mainly built with view based table views and the new Core Data APIs. I think view based table views shaved about 2 months off of my development time, so support for 10.6 wasn’t really an option for me. 10.7 also has a JSON Parser (NSJSONSerialization) and Popovers (NSPopover) built in, and although there are open source projects that offer similar functionally, I prefer to only depend on code by Apple and myself (rightly or wrongly) wherever possible.

The application syncs with a Rails application that I host on Heroku, and I couldn’t recommend Rails and Heroku enough. Rails is a great framework and Ruby is a great programming language, the best thing about Rails (for a non web developer) is everything has its place. Rails forces you to have a certain folder structure and I found this extremely beneficial … you can also add features with only a few lines of code which can only be a good thing. Heroku’s main benefit is you don’t have to think about servers and you just have to worry about your app. You simply deploy your code using a git push and you’re done. Moreover the majority of basic Heroku Add Ons are free, so you can start using Heroku without any risk (I am honestly not on commission, I just like it ).

I want to end this post by saying no matter how many times you release an application, seeing other people downloading it and using it is always the best feeling a developer can get, so if you can … SHIP IT!!!

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.

I’ve previously written 2 posts on categories (which you can find here and here), and how they allow you to extend a class’s functionality by adding additional methods to it without subclassing it. The key word being methods (or indeed selectors if your getting technical), and not properties or instance variables. If you need to call a block after an asynchronous action has completed, you’re going to have to store it somewhere in the meantime, and that is the main focus of this post.

Take UIAlertView for example, you need to register for a callback when the user presses a button.

So you’d often have something like:

- (IBAction)showAlert:(id)sender{
 
UIAlertView *alertView = nil;
 
alertView = [[UIAlertView alloc] initWithTitle:@"YES or NO"
message:@"Select One" 
delegate:self 
cancelButtonTitle:@"NO" 
otherButtonTitles:@"YES", nil];
 
[alertView show];
[alertView autorelease];
}

Then you would need to implement a method with the correct signature to handle it:

- (void)alertView:(UIAlertView *)alertView 
didDismissWithButtonIndex:(NSInteger)buttonIndex{
if(buttonIndex == 1)
{
//Do Something
}
}

This may look fine in the above example, but in a real iOS application the callback method may have to handle lots of different alert views, and we still have the handler code separated from where we actually setup and show the alert view.

So how can we solve this?

We are going to add a completion handler to UIAlertView, which doesn’t return anything and takes the button index we get given by the UIAlertViews delegate method as a parameter. To keep things clean we will define our completion handler in our categories header:

typedef void(^MCSMUIAlertViewCompletionHandler)(NSUInteger buttonIndex);

So the first thing you will need to do is set the completion hander block on an alert view and store it for when we get the delegate callback. For this we will use the Objective-C runtime function: objc_setAssociatedObject.

The objc_setAssociatedObject function takes 4 parameters:

1. The object that you want to add the association too, in this case the UIAlertView
2. The unique key so you can retrieve the value later
3. The value you want to associate, which in this case is the completion handler block
4. The association policy, which tells the runtime wether this association retains, copies or assigns the value.

The best way to describe how this function works, is that it treats an object like and NSDictionary. It allows you to set a given value for a given key, but unlike NSDictionary you can specify if the value is assign, retained or copied.

To use this method you need to include the runtime header:

#import <objc/runtime.h>

And we will define our key as a constant to keep things tidy, and so we don’t make any typos later on:

NSString * const MCSMUIAlertViewCompletionHandlerKey = @"MCSMUIAlertViewCompletionHandlerKey";

Then in another category method on UIAlertView all you need to do is set the alert view as its own delegate, and store the block as an associated object:

- (void)MCSM_setCompletionHandler:(MCSMUIAlertViewCompletionHandler)handler{
self.delegate = (id<UIAlertViewDelegate>)self; 
 
objc_setAssociatedObject(
self, 
MCSMUIAlertViewCompletionHandlerKey,
handler,
OBJC_ASSOCIATION_COPY_NONATOMIC);
 
}

As the UIAlertView is now it own delegate, it will receive the alertView:didDismissWithButtonIndex: callback. In this method you will need to retrieve the completion handler block so you can call it with the button index argument. To do this you will need to use another Objective-C runtime function objc_getAssociatedObject

The objc_getAssociatedObject function takes 2 parameters:

1. The object to retrieve the association from
2. The unique key for the association

This will mean that you end up with a method looking like this:

- (void)alertView:(UIAlertView *)alertView didDismissWithButtonIndex:(NSInteger)buttonIndex{
 
MCSMUIAlertViewCompletionHandler handler = nil;
//Get the Handler
handler = (MCSMUIAlertViewCompletionHandler)objc_getAssociatedObject(
self,
MCSMUIAlertViewCompletionHandlerKey);
 
//If there is a handler call the handler
if(handler)
{
  handler(buttonIndex);
}
 
//Release the block by setting the associated object to nil
objc_setAssociatedObject(
self, 
MCSMUIAlertViewCompletionHandlerKey, 
nil, 
OBJC_ASSOCIATION_COPY_NONATOMIC);
}

So now that we have added this category to UIAlertView, all we have to do is update the code that creates and shows the alert view:

- (IBAction)showAlert:(id)sender{
 
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"YES or NO"
message:@"Select One" 
delegate:self 
cancelButtonTitle:@"NO" 
otherButtonTitles:@"YES", nil];
 
[alertView MCSM_setCompletionHandler:^(NSUInteger buttonIndex){
if(buttonIndex == 1)
{
//Do Something
} 
}];
[alertView show];
[alertView autorelease];
}

You can grab the code for this on Git Hub here and have a play with it yourself.

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.

So what is a singleton? Wikipedia defines it as:

In software engineering, the singleton pattern is a design pattern used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object.

Or as I would put it:

A singleton is a class, where only one instance of it can instantiated.

Although this is the actual definition of a singleton, this isn’t always the case in the world of Foundation. NSFileManger and NSNotificationCenter for example, are usually accessed through their class methods defaultManager and defaultCenter respectively. Although not strictly a singleton, these class methods return a shared instance of that class that developers can then access throughout their code. It is this approach that we will be looking at in this post.

There has always been a debate on the best way to implement the singleton pattern using Objective-C, and developers (including Apple) seem to have been changing their minds every couple of years. When Apple introduced Grand Central Dispatch (GCD) (in Mac OS 10.6 and iOS 4.0) they introduced a function that is perfect for implementing the singleton pattern.

This function is dispatch_once:

   void dispatch_once(
   dispatch_once_t *predicate,
   dispatch_block_t block);

This function takes a predicate (which is a long, that in reality acts as a BOOL) that the dispatch_once function uses to check if the block has already been dispatched. It also takes the block that you wish to only be dispatched once for the lifetime of the application, for us this is the instantiation of our shared instance.

Not only does dispatch_once mean that your code will only ever get run once, it is also thread safe, which means you don’t have to bother with using anything like @synchronized to stop things getting out of sync when using multiple threads and/or queues.

This is verified by Apple’s GCD Documentation:

If called simultaneously from multiple threads, this function waits synchronously until the block has completed.

So how would you use this in practise?

Well lets say you have a Account Manager class, and you want to access a shared instance of this class throughout your application. You can simply implement a class method like the one below:

+ (AccountManager *)sharedManager
{
        static AccountManager *sharedAccountManagerInstance = nil;
        static dispatch_once_t predicate;
        dispatch_once(&predicate, ^{
                sharedAccountManagerInstance = [[self alloc] init]; 
        });
    return sharedAccountManagerInstance;
}

This means whenever you want access this shared instance all you need to do is:

AccountManager *accountManager = [AccountManager sharedManager];

And that’s all there is to it, you now have a shared instance that you can access throughout your application, which will only be created once.

This approach has many advantages:

1. It is thread safe
2. It will keep the static analyser happy
3. It is compatible with Automatic Reference Counting (ARC)
4. It only requires a small amount of code

The only disadvantage with this approach is that it will still allow a non shared instance to be created:

AccountManager *accountManager = [[AccountManager alloc] init];

Sometimes you will actually want this behaviour, but it is something you need to be aware of when you really only want one instance of a class to ever be instantiated.

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.

Number of applications:
If there is one thing that we can be sure of, it is that the number of applications available for Mac OS will increase due to the introduction of the MAS. There will be iOS developers jumping on board (who are in for a shock when they see NSTableView), and also developers coming “Back to the Mac” after spending some time doing iOS development.

Quality of applications:
Quality and Quantity are two very different things. Just because the quantity of applications increases, that doesn’t mean that the number of high quality applications (that we have come to expect on the Mac) will increase accordingly. I (unfortunately) think that there will be a lot of substandard applications released for the Mac, simply because of the MAS making distribution easier. I do however think that there will be a few gems uncovered because of it.

Price of applications:
When the Mac AppStore was first announced, developers contemplated raising their prices to compensate for Apple taking a 30% cut of the revenue (compared to <10% for most other providers), now developers are thinking the opposite … lets lower prices. I don’t think that this will be as extreme as the “race to the bottom” on the iOS AppStore, as Mac applications usually take longer to build than there iOS equivalents. This is mainly because iOS has a more modern set of APIs, and on the Mac you have to support extras like Drag and Drop, Keyboard Shortcuts etc.

I think that Mac AppStore application pricing will fall into 4 main categories:

• < $5 – Simple single purpose applications
• $10 – Simple applications with an iOS sized feature set
• $20 – $40 Fully featured applications
• $40+ Professional applications like Microsoft Office, Adobe creative suite etc

Application Sales:
The simple fact is that people are more willing to give their payment details to Apple, rather than entering them on an indie developer’s website. If, and it is a big if, you get a prime place on the Mac AppStore (featured,top 25s etc) your sales are likely to be huge. For all the other applications on AppStore, time will only tell if it dramatically increases sales beyond the number of sales gained from the security of purchasing through Apple. I do believe however that non MAS sales will suffer a lot. The people that currently purchase applications online are likely to be “tech savy”, and therefore they will know about the MAS. Why would these users not switch to purchasing all of their applications through Apple ? the fact is they will.

Hello AppStore bye bye Serial codes:
There are a few benefits of distributing applications through the AppStore rather than handling distribution yourself. One of the major pains is payments and serials, which can take up a considerable amount of an application’s development time. This along with handling updates, is now removed from a developers workload with the introduction of the MAS, saving developers time and a lot of headaches.

Conclusion:
On the whole I can only see the Mac AppStore being a positive thing for Mac users and developers alike. Developers have a central place to sell their products from, and they don’t have to worry about getting it listed on numerous application sites. Users will have a an application (pre installed on their Mac !!!) which will allow them to search, view and securely purchase thousands of applications using just their Apple ID.

This could be a very big year for the Mac…

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event;
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event;

If you were trying to detect if a user was dragging a view (or panning as Apple would say), you would usually implement the touchesBegan:withEvent: to start dragging the piece, touchesMoved:withEvent: to adjust the view’s frame, and then touchesEnded:withEvent: and touchesCancelled:withEvent: to stop detecting the drag. While implementing dragging was not too complex, trying to detect a more advance gesture such as a swipe or pinch was a lot more complex … and a lot of hard work to make it replicates Apple’s version of the gestures accurately.

Thankfully Apple created UIGestureRecognizer:

UIGestureRecognizer is an abstract base class for concrete gesture-recognizer classes. A gesture-recognizer object (or, simply, a gesture recognizer) decouples the logic for recognizing a gesture and acting on that recognition. When one of these objects recognizes a common gesture or, in some cases, a change in the gesture, it sends an action message to each designated target object.

Taken from Apple

As UIGestureRecognizer is an abstract class, you will never use it directly. You will however use one of its subclasses, that have been designed specifically to capture a specific gesture.

UITapGestureRecognizer
UIPinchGestureRecognizer
UIRotationGestureRecognizer
UISwipeGestureRecognizer
UIPanGestureRecognizer
UILongPressGestureRecognizer

So lets take UIPanGestureRecognizer for an example, and we will use it to move a view around.

Our example view controller has a view (obviously), and this has a subview called panView, which is the view we will move around.

First thing that you will need to do, is create a pan gesture recognizer (UIPanGestureRecognizer) and add it to the panView. This will allow you to detect the gesture. To get informed about the gesture getting detected, you have to set the view controller as the delegate, and then have it call the the panViewWithGestureRecognizer: selector. (Note: You can set any object as the delegate, as long as it implements UIGestureRecognizerDelegate protocol. For this example the view controller makes sence.)

UIPanGestureRecognizer *panGesture = nil;
panGesture = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(panViewWithGestureRecognizer:)];
 
[panGesture setMaximumNumberOfTouches:2];
[panGesture setDelegate:self];
 
[panView addGestureRecognizer:panGesture];
[panGesture release];

panViewWithGestureRecognizer: will get called when the gesture changes state, the possible states are:

 
UIGestureRecognizerStatePossible  
UIGestureRecognizerStateBegan    
UIGestureRecognizerStateChanged   
UIGestureRecognizerStateEnded    
UIGestureRecognizerStatePossible
UIGestureRecognizerStateCancelled   
UIGestureRecognizerStateFailed
UIGestureRecognizerStateRecognized
UIGestureRecognizerStateEnded

For this example we only care about if gesture began (UIGestureRecognizerStateBegan) or has changed (UIGestureRecognizerStateChanged). When a pan gesture happens (begins or changes) we want to move the center of panView to be underneath the users finger, thus dragging the piece.

To do this we implement in the following way.

 
- (void)panViewWithGestureRecognizer:(UIPanGestureRecognizer *)gestureRecognizer
{    
 
    if ([gestureRecognizer state] == UIGestureRecognizerStateBegan 
         || [gestureRecognizer state] == UIGestureRecognizerStateChanged) 
    {
 
        CGPoint translation = [gestureRecognizer translationInView:[panView superview]];
 
        [piece setCenter:CGPointMake([panView center].x + translation.x, [panView center].y + translation.y)];
        [gestureRecognizer setTranslation:CGPointZero inView:[panView superview]];
    }
}

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer;