Apple mobile developers and storyboards

It’s been a while now since apple released a version of XCode with a graphical tool that allows developers to create a storyboard. The storyboard contains a WYSIWYG view of the user interface and provides a quick way to link UI elements to their associated code. Early releases of XCode did not include the storyboard feature and as a result, many apple developers prefer to generate their user interfaces programatically.

Reasons for not using a story board tend to be associated with the size of the project or the number of developers. When working with version control systems like SVN and GIT, it is quite common for developers to overwrite other developer’s changes if a single story board is used for the project. What a number of developers don’t seem to know is that XCode supports multiple story boards.

By using multiple storyboards developers can break larger project into a number of bite sized chunks. This helps define work items and allows for a clearer view of program flow. To transition to a new storyboard the programmer would use the following code.

    // Get the storyboard named secondStoryBoard from the main bundle:
UIStoryboard *secondStoryBoard = [UIStoryboard storyboardWithName:@”GroupPicturesStoryboard” bundle:nil];

// Load the initial view controller from the storyboard.
// Set this by selecting ‘Is Initial View Controller’ on the appropriate view controller in the storyboard.
UIViewController *theInitialViewController = [secondStoryBoard instantiateViewControllerWithIdentifier:@”GroupPics”];

// Then push the new view controller in the usual way:
[self.navigationController pushViewController:theInitialViewController animated:YES];

Note that apple has not yet designed a way to graphically link storyboards so developers must move from one board to the other programatically. To get back to the main storyboard just pop the previous view controller off the stack.

 [self.navigationController popViewControllerAnimated:YES];

Experienced IOS designers will bypass the storyboard in order to reuse and create custom UI elements, but companies will pay the price for this later on. Code that doesn’t use storyboards will be harder to support and may not be supported by future versions of XCode. Apple tends to be somewhat like mother nature in that it’s not good to fool with them.

In many cases the supportability gained by duplicating UI components far exceeds the expense of the extra code. Yes you may have to make a change in more than one place, but the “ViewControllers” are self contained, easy to understand and very portable.

If you’re not using storyboards now, you should give them a second look. If you are having a programed designed, insist that the design includes storyboards and that all UI components are contained in them.


This entry was posted in General and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *