Socialize

Feel free to follow me on twitter

Triply – Never miss another stop…

Posted on Nov 18, 2013

Firstly, apologies for not updating my blog in a while, since completing the Stanford courses I’ve been super busy on my first app. Triply is a minimal, iOS7 inspired, gesture based train alarm app. You can find out more about Triply here on the website.

The purpose of my post is not to tell you what Triply does but to go over some of the inner workings, expose some of the frameworks used and to talk about some of the problems I faced and subsequently endeavoured to solve as part of the development process.

To give you an idea of some of the frameworks that went into Triply, here’s the list of imports across some of the view controllers…

#import “TriplyViewController.h”

#import “Station.h”

#import <CoreLocation/CoreLocation.h>

#import “UIColor+Extensions.h”

#import “TriplyAppDelegate.h”

#import <MapKit/MapKit.h>

#import “DefaultsManager.h”

#import “TriplyIntroView.h”

#import “SettingsViewController.h”

#import “SWRevealViewController.h”

#import “TriplySettings.h”

#import <MediaPlayer/MediaPlayer.h>

#import <MessageUI/MessageUI.h>

In particular I want to talk to you about the following topics which I’ll mostly split into separate posts…

-       The overall structure including the sliding panel interface as seen in Facebook and other popular apps.

-       Pull to refresh including the implementation details

-       Core location and how it’s used within the app

-       UIPickerView and my solution for alphabetised automatic scrolling

-       UILocatioNotification and ensuring background alerts

-       MPMusicPlayer and it’s use within the app.

-       Persistence and how the app uses NSUserDefaults to manage recent stations

I’ll start with overall structure of the app which at first glance appears to be fairly straight forward, however as always when you get into the detail things soon become complex as you need to start passing information between view controllers. At a high level the app uses an SWRevealViewController (a container view controller0 to manage a sidebar view controller (revealed when the user swipes the frontmost VC to the right or taps the ‘reveal’ button) along with a ‘Home’ VC and a ‘Recent’s VC. The alarm itself can be set-up from either the home or recents view controller, and either way is presented in a ‘fresh’ modal view controller each time. This modal ‘alarm’ VC is subsequently ‘destroyed’ on deactivation of the alarm, releasing any memory previously allocated for it.

At first I wanted the SWRevealVC to ‘hold on’ to each of it’s child view controllers and to ‘re-instantiate’ the same VC each time you navigate away and go back. I soon realised this wasn’t the best approach and goes against Apples storyboard paradigm of instantiating an new VC each time its required. I therefore built the initial structure in such a way that each scene (view controller) is deallocated at the point the user navigates away and a completely new one is instantiated upon the users return, essentially ensuring optimum use of available memory.