Feel free to follow me on twitter

iOS Design Patterns used within Triply

Posted on Nov 18, 2013

When I first started learning iOS development, I skipped over ‘design patterns’ in favour of actually learning the objective-c language. However when you come do actually develop real world applications you soon come to realise that these concepts really do make your life easier and are actually fundamental to the development process.

Apple has a good overview here of some of the design patterns than can be utilised within your app. I want to go through a couple I used within Triply to give you an idea of how these can be translated into real applications.

Model – View – Controller

Model View Controller is a key design principle that you’ll want to adhere to when building your application, otherwise you’re going to find yourself in all sorts of trouble. I’m not going to explain what MVC is as if you’re here I’m sure you already know, just to make you aware that Triply used a simple model which consisted of a ‘Station’ class and a plist containing an array of dictionaries of all UK stations and their latitude/longitude information. The controller layer consists of 7 view controllers that mediate between the 7 storyboard scenes and the model.

Target Action

Target Action is a fairly simple one and is mainly used for buttons that can be hooked up using interface builder. The button is the target and the method it performs when tapped is the action. I used this multiple times across the application however you can also setup target action programmatically which I did to add the ‘reveal’ action to the sliding panel toggle button:

[self.sideBarButton addTarget:self.revealViewController action:@selector(revealToggle:) forControlEvents:UIControlEventTouchUpInside ];


Delegation is an important one and one that backs handling the data source and interation for a lot of Apples own code, such as the UITableView and UICollectionView. Triply uses this extensively, in the UIPickerView for selecting the stations on the main view and in the ‘Recents’ view to manage the table which displays a list of recent stations.


Triply also implements it’s own delegation via protocols (another design pattern) to manage communication between view controllers. It does this in two places, firstly when the user activates the alarm, the app must show a modal view controller showing the distance remaining, before it can do this it needs a fix on the users location. So how you to stop the modal view controller presenting itself prematurely? The answer is delegation, by setting the presenting view controller as the delegate of a custom location manager (it doesn’t have to be custom) class which implements it’s own didUpdateToLocation delegate method within it’s protocol, you can be notified when a sufficiently accurate location update is received, at which point you can safely present the modal view. This is used a couple of time across the application.

Delegation is also used when the intro tutorial is presented to inform the presenting view when the user has reached the end so that it can prepare itself for becoming visible whist removing the tutorial view from itself.


Blocks are something Apple is really pushing in it’s frameworks and when you realise the power they offer you understand why, even if the syntax can be intimidating at times. There was one point when I sat scratching my head for a while. I needed to find, in an array of custom Station objects, the index of the first station name, that began with a given letter of the alphabet. For example, given the letter S, I needed the index of the first station beginning with ‘S’.

This is where blocks come in, I was able to use the handy ‘indexOfObjectPassingTest:’ which iterates through an array which you pass in, then within the block you can do whatever test you like, if the test evaluates to TRUE it returns the index of that object. Easy. Out of interest I used this to implement the automatic scrolling when you choose certain letters un the UIPickerView on the main view.


Categories are another design pattern that allow you to extend the functionality of classes, even Apples own classes (ie. Source code you don’t have access to). In Triply I used a trivial implementation of a category to extend the UIColor class. I had lots of custom colours, shades of green and grey I wanted to keep consistent across the whole user interface. Instead of using [UIColour ColourWithRed:Green:Blue:] everywhere which looks kind of messy I created a category on UIColour and implemented:

+ (UIColor *)aplyGreen {

return [UIColor colorWithRed:0.0f/225.0f green:201.0f/225.0f blue:87.0f/225.0f alpha:1.0f];


This meant that everywhere I wanted to use the colour within the app I could simply say:

[UIColor aplyGreen].

Much nicer.


Finally theres notifications, the idea that you register to be an observer of a notification with the global ‘notification centre’. When certain event happen you’re then notified so you can take the appropriate action. I used this design pattern within Triply in order trigger a notification from the appDelegate to the alarm view controller in the even the app is launched as a result of the user tapping the notification that’s received when the destination is reached and the app is in the background. This allowed the alarm view controller to stop what it was doing as immediately display the ‘destination reached’ screen. I also had it automatically disable the alarm at one point however it seemed counter intuitive so I’ll left this as an action for the user.