Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 7

Great tip: viewDidLoad: is always called AFTER all outlets are wired up when a view controller is instantiated from a storyboard. Therefore, this is a good place to shove any initialization code that need to reference outlets.

UIToolBar

  • Usually at the top or bottom of your view.
  • A collection (NSArray) of UIBarButtonItems easily accessed read and written using self.toolbar.items.
  • Has a default “steel” effect UI, but can be customized using barStyle, backgroundColor or a background image etc.Fig 1
  • The UINavigationController has an optional toolbar at the bottom – its toolbarHidden @property is set to YES by default but you can switch it on by setting this to NO programmatically or via a toggle button in the Storyboard.
  • Set the toolbar.items @property in each embedded view controller to an array of UIBarButtonItems to control what buttons appear for that view controller.
  • A UIBarButtonItem can show text or an image, or you can even set it to a custom view.

UISplitViewController

  • Only available on the iPad.
  • A UISplitViewController will not even be presented as an option for an iPhone storyboard.
  • A storyboard can be either iPad or iPhone specific. You must specify which when you create it.
  • A split view is generally a “root” UI element only – i.e. it fills a whole screen.
  • It is usually the initial view controller and not normally embedded in another view controller.
  • Usually you would only have one split view controller in your app.
  • The master and detail view controllers are specified in an NSArray accessible via the viewControllers @property in the split view controller. The master view controller is element 0 and the detail view controller is element 1.
  • Usually you’d just specify these using drag and drop in your storyboard.
  • Note that the viewControllers array is passed as a “copy” @property, not a strong reference, so you can’t pass in a mutable NSArray then change its elements later and expect the split view controller to change.
  • The UISplitViewController requires a delegate @property for use in portrait mode or, by default, there will be no way to display the hidden master view controller.
  • Usually you set the delegate in viewDidLoad or awakeFromNib.
  • Depending on the implementation, either the master or detail view controller may be the delegate. More often, it is the master since it is often always present in memory (even when not displayed).
  • The delegate controls in which screen orientations the master view controller appears or is hidden. The detail view controller (normally to the right) is always visible.
  • The delegate is declared as:
    @property (nonatomic, assign) id <UISplitViewControllerDelegate> delegate;
    So beware, assign is like a “weak” pointer but without the “zeroing” action – so in theory, you could get a dangling pointer, but this is unlikely within a split view controller.
  • The delegate is asked about when the master should be on screen. When the master is about to be removed from the screen, your delegate will be informed and passed a UIBarButtonItem which you need to display on screen in your detail view controller. When selected by the user this button will display the master (usually in a popover).
  • When the master view controller is about to be hidden from view, your delegate will again be informed and be responsible for removing the UIBarButtonItem.
  • The screen shot below shows the delegate message and demonstrates how you can instruct the split view controller when to hide/show the master view controller.
  • Fig 2Note how you can specify that the master (left) view controller is ALWAYS visible by returning NO for every orientation:Fig 3
  • The default is to hide the master in portrait mode:
    return UIInterfaceOrientationIsPortrait(orientation);
    This is why you always need a delegate or you’ll never see the master view in portrait mode:Fig 4
  • You handle the following message in your delegate to show the bar button – see how iOS kindly passes the UIBarButtonItem to use! easy!Fig 5
  • When the master view controller is about to be shown, you handle the opposite message and remove the bar button:Fig 6
  • Here’s a typical implementation for the setSplitViewBarButtonItem: method. This will show the button when passed, and hide it if the passed button is nil:Fig 7
  • You could handle this in the master or detail view controller – it depends which one you set as your delegate. Normally, you’d chose the view controller that’s gonna be in the split view controller all the time (even when it’s not visible), or you might chose the least generic controller. Obviously, the button is always shown in the detail view.
  • The simplest way to update the detail view is by using a target/action.
  • Note we can pass messages to the detail view controller using:
    id detailVC = [[self.splitViewController viewControllers] lastObject];
    See slide…Fig 8
  • …or, you can use a “Replace” segue. This is actually more hassle though. Note the warning in the above slide. You’d normally pass the UIBarButtonItem in prepareForSegue.

Popovers

  • A Popover is not a UIViewController – it just inherits from boring old NSObject.
  • Its content is provided by an embedded “Content” view controller which you supply.
  • You can animate a change of content in a Popover already on screen with:
    – (void) setContentViewController: (UIViewController *) viewController animated: (BOOL) animated;
  • You can also animate a change in size using:
    – (void) setPopoverContentSize:(CGSize) size animated:(BOOL) animated;
    This can look sweet.
  • in prepareForSegue, the segue argument will be isKindOfClass:UIStoryboardPopoverSegue which has a popoverController @property which you can use to grab a reference to the Popover.
  • Tip: Detect whether a Popover is visible using its isPopoverVisible @property.
  • WARNING: You MUST keep a strong pointer to your Popover controller since when a local variable goes out of scope your Popover will be deallocated! This is a common mistake!
  • You can add views to a Popover’s NSArray *passthroughViews @property if you want to ensure your Popover is not dismissed by the user touching certain views outside the Popover.
  • If you want, you can add the whole screen to passthroughViews – in this case you absolutely need a button in the Popover content to dismiss it.
  • It’s best practice to always call dismissPopoverAnimated: from outside your Popover – probably triggered via a delegate message to the view controller that initially presented it – rather than from inside – even though the latter seems easier. This is good object-orientated practice since the Popover content view controller should not need to know it’s in a Popover!Fig 9
  • The best way to specify your Popover’s size is to set the contentSizeInPopover @property of your content view controller since this is most likely to know the size it “wants” to be and can also be calculated on the fly and set programmatically.Fig 10

Universal Applications

  • Use a single binary image with separate storyboards for the iPhone and iPad.
  • How do I figure out I’m running on an iPad?Fig 11
  • BUT – whenever possible, don’t do this! Instead, use “feature-sniffing” rather than forking based on the platform. For example, if self.splitViewController is not nil you must be running in a split View Controller on an iPad. Anyone coming from a JavaScript background will recognize this technique.
  • A handy tip to find out if a view is actually on screen is to check its window @property:Fig 12Other handy ways to get the size of the current screen and the resolution:Fig 13The contentScaleFactor will return pixels per point e.g. 2 on a retina display. It’s a good way to find out what kind of screen you’re running on.
  • By default a UIViewController doesn’t support landscape orientation. This is why, if you just drag a generic view controller onto a storyboard and add a segue to it, when it runs the view will appear in portrait mode regardless of the device’s orientation. To solve this you can create a generic, custom sub-class which inherits from UIViewController and merely overrides the shouldAutorotateToInterfaceOrientation: method. A nice name for this would be “RotatableViewController”. You can use this class for all these instances even in other applications.
  • You can easily copy and paste view controllers from one storyboard to another. This is a great way to create a new storyboard e.g. for the iPad based on an existing one for the iPhone.
Advertisements

Things wot I learnt from Stanford – iPad & iPhone App Development – Fall 2011 – Lecture 6

Multiple MVC’s and Segues

A common design pattern is for an object to pass a reference to itself (using ‘self’) when sending a message to a delegate so that the delegate can ask our object for more information if they want. For example in the @protocol definition shown below, the FaceView control will set the sender parameter to self when it calls the delegate which handles the smileForFaceView: message:

Fig 1

An object sends a reference to itself to the handler.

If you want the fact that your class implements a @protocol to be kept private (i.e. it’s not of interest to an external developer), you are allowed to specify the @protocol name in your private @interface declaration  – i.e. the one (normally) in your “.m” file rather than in the header “.h” file. See screenshot.

Fig 2

Declaring a protocol implementation privately

CGPointZero is a handy, predefined constant for specifying a point of (0, 0) for example when resetting translations passed to gesture handlers. See screenshot.

Fig 3

Using CGPointZero to reset a translation in a gesture recognizer.

One MVC (Model, View Controller) should never control more than one screen. If we need to add another screen we should add a new MVC.

Fig 4

Multiple MVCs working together to show multiple screens.

We need a “controller of controllers” to switch between multiple MVCs (or screens) for example a UINavigationController. These are sometimes referred to as “container controllers”.

Fig 5

A UINavigationController acts as a “controller of controllers” and allows us to co-ordinate between multiple MVCs

Fig 6Fig 7A UINavigationController is a subclass of UIViewController with its own view which can have a title bar and always has an area below it in which to show the view from another MVC. It has no model, it is purely a UI controller.

It has a rootViewController @property which can point to another MVC. This controls what appears in its view (the white area in the screenshots above). It actually “embeds” that MVC’s view into this area. It will change the bounds of your MVC’s view to fit (note your “springs” and “struts” defined in Interface Builder and the view’s contentMode therefore become important during this resizing).

Segues

Only in iSO 5 and later. To create a segue in your Storyboard, hold down Ctrl and drag from the source object (e.g. a button) to the destination view controller.

Fig 8

Creating a Segue

Segues always instantiate a new instance of a view controller. Segues ALWAYS instantiate a NEW instance of a view controller. That’s not a Ctrl-V stutter- I said it twice as it’s important! They always create a new instance from scratch. This allows iOS to dispose of the destination view controllers and free up memory as soon as they’re dismissed.

Segue styles (at the time of writing) can be Push, Modal or Custom (your own subclass of UIStoryboardSegue). Push is used inside a UINavigationController. The iPad also supports Replace which allows you to replace the right-hand view of a UISplitViewController. The style can be set in the Storyboard by selecting the segue and choosing it from a list as in the slide below.

Fig 9

Specifying a segue style (and identifier)

The slide below shows how you can embed your view controller (often your startup one) in a Navigation Controller using the Storyboard interface. The process is similar for embedding within a Tab Bar Controller.

Fig 10

Embedding your view controller in a Navigation Controller.

This leads to this…

Fig 11Your view controller is added to the Navigation Controller as the rootViewController @property (an outlet).

Fig 12Here’s an example of how your view could appear embedded within a Navigation Controller. Notice that the “back” button takes it’s label text from the title @property of the previous UIViewController and the title of the current View Controller is shown at the top.

Fig 13

Using a UINavigationController

A really quick way to set the title @property is just to double-click it directly in the Storyboard and type it in.

Fig 14

Entering the title @property for your View Controller.

Pressing the “Back” button pops a pushed MVC back to the original, source MVC, but you can also do this programmatically using the UINavigationController instance method:

– (void) popViewControllerAnimated: (BOOL) animated

It’s rare but sometimes handy to call this. In this example, we actually call this function from within the controller on screen – i.e. the one to be “popped” – when its display is no longer required.

Fig 15

Popping a view controller programmatically.

All UIViewControllers have a navigationController @property. If the controller is not embedded in a Navigation Controller this will be set to nil. There are similar properties to access other container controllers such as tabBarController.

Triggering a segue from code:

Fig 16When a segue fires, the destination view controller is instantiated with all its outlets then the following message is sent to the source view controller to give it the chance to pass it information:Fig 17A common pattern here is to set ‘self‘ as the delegate for the the new, destination controller using the id type. Using the id type is important! DO NOT PASS THE ACTUAL TYPE. Always treat the new View controller as you would treat a view – give it as little information as possible. This approach greatly enhances the portability (“re-usability”) of your controller and code.

You can also instantiate a view controller programmatically using the Storyboard method:

– (id)instantiateViewControllerWithIdentifier:(NSString *)identifier

You can obtain a reference to the Storyboard by calling self.storyboard – as long as self was created from the same Storyboard.

Fig 18

Instantiating a view controller from the Storyboard programmatically.

Note the use of pushViewController in this example which assumes the current controller is embedded in a Navigation Controller.

Tip: Did you know a UILabel control can have more than one line of text simply by selecting it in your Storyboard and setting the “Lines” attribute to a number greater than 1?

Using and Abusing UIViewControllers

Jonah Williams has some life changing advice on the proper and improper use of UIViewControllers in his post here. This post will switch on the light bulb for anyone coming to iOS development from another platform such as .NET.

This is his (and Apple’s) advice In a nutshell:

  • One (and only one) view controller should be responsible for a whole hierarchy (or screenful) of UIViews.
  • Mostly, you should only use one view controller per screen. Essentially the rootViewController of the current UIWindow should be the only UIViewController with a visible view.
  • Each different screen should have a different view controller i.e. one controller should not control more than one screen.
  • You should NOT nest custom UIViewControllers within a view hierarchy.
  • If more than one UIViewController hangs off the application’s UIWindow, only one of these will get the messages for changes in orientation. The other(s) will NOT get these messages.
  • Nested UIViewControllers are not guaranteed, or likely, to receive messages for changes in orientation or lifecycle messages such as viewDidAppear:, viewWillAppear:, viewDidDisappear: and viewWillDisappear: even though they inherit from UIViewController. Only the topmost UIViewController is certain to get these messages.

Some interesting discussions on this point on StackOverFlow:

iPhone viewWillAppear not firing

Am I abusing UIViewController Subclassing? – Nice quote from this:

Each screenfull should have one master VC Subclass, with all the subviews controlled instead by custom controllers (which happen to control views) which are subclasses of simple NSObject.

In this case, UIViewControllers should only be directly to the Window or UINavigationController, UITabBarController etc?

Also, this quote from Apple’s View Controller Programming Guide:

View controllers are directly associated with a single view object but that object is often just the root view of a much larger view hierarchy that is also managed by the view controller. The view controller acts as the central coordinating agent for the view hierarchy, handling exchanges between its views and any relevant controller or data objects. A single view controller typically manages the views associated with a single screen’s worth of content, although in iPad applications this may not always be the case.

With iOS 5 and the introduction of Custom Container View Controllers, much of this will change (see Pat Zearfoss’s comment, below). But it is important to understand the above as a starting point.