Storyboards/Nibs vs. Doing Everything With Code in iOS

When you start working on a new app, one major decision that needs to be made is whether you want to do all of the interface work graphically (through xibs/storyboards) or programatically. Each method has pros and cons. Hopefully this post will help you make the best choice for your project!

Why Storyboards are Actually Really Cool…

With my experience, I have found that the best time to use interface tools to build your app is when you are quickly prototyping something by yourself. If you are at a hackathon, or playing around with a new app idea, doing all the interface work in storyboards is actually quite ideal. You can very quickly iterate and pump out a half decent functioning app in very little time. Additionally, if you are just beginning iOS, it is incredibly helpful to have the ability to visualize how code is linked up to a functioning interface. Even though I usually don’t use interface builder in projects now, it greatly helped my understanding of iOS development by allowing me to visually link snippets of code to the graphics I would see on the screen. This is really cool, and makes concepts that can be hard to comprehend very intuitive. 

Why Storyboards Aren’t Always that Great…

So, even though Interface Builder and Storyboards are a really cool technology and are fantastic when learning and prototyping things on iOS, as you begin dealing with source control and collaborating with other developers, you will rapidly run into issues. For example, lets say I am on a team of developers, and by accident two developers fix the same bug or add or overwrite something on the same view using storyboards. This will cause a merge conflict (assuming you are doing source control with git). Now, since the actual interface “code” generated by Interface Builder is non-readable xml, it can be nearly impossibly to fix even the smallest merge conflict in a massive storyboard file. This could lead to massive amounts of work being lost or corrupted. This is a very bad thing. 

Next, since storyboards are essentially a level of abstraction on Cocoa, it can be much harder to do customization of UI. For example, if I wanted to recreate the now popular interface flow of sliding the main view controller to the right to access the side menu view controller, I would have to get a reference to the two view controllers and navigation controller stack.  If I built the app doing everything programmatically, this would be fairly straightforward and also be pretty clean code. With Storyboards however, just to get a reference to a single view controller I would have to do something like this:

MyViewController *controller = (MyViewController*)[mainStoryboard
instantiateViewControllerWithIdentifier: @”<Controller ID>”];

This is kind of gross and unnecessarily long code. Also, with this additional abstraction, it could be much harder to track down small bugs and other flaws. 

Finally, if you are working on a very large project over the course of a few months, if you have everything involving the interface in one place organized by the name of the view it is way easier to track down what happens where, and know where to add or remove code. If you have parts of interface “code” in a storyboard and part of what is driving the interface living in a .m file, it can become very confusing as to what actually controls what. 

 

 

 

Advertisements

Basic Model-View-Controller flow for iOS

So, one important thing to learn in iOS as well as in any language are some core concepts of software design. This would be the model view controller pattern.

In terms of an iOS project, a good way to think of how this could be implemented would be in a calculator application. The model of this project would store the methods that process the number, i.e. a method to add, a method to substract, a method that divides, and a method that multiples, etc.

For the sake of this application, lets assume each of the methods has an input of two doubles and returns a double as well. Essentially, our model will contain all the methods that do any action to the numbers in the calculator.

In our view controller, we will then make an instance of our model class. This will allow us to use all the instance methods we created in our model class in view controller class. Essentially, we want to pass the values from our view into the methods stored in our model.
Here is the header file:

 

//
//  CalculatorModel.h
//  ModelCalculator
//
//  Created by Andrew Rauh on 5/12/12.
//  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
//

#import <Foundation/Foundation.h>

@interface CalculatorModel : NSObject

- (double) addNumbers: (double) numberToAdd1 :(double) numberToAdd2;

- (double) subNumbers: (double) numberToSubtract1 :(double) numberToSubtract2;

@end

And here is the implementation file. (.m)


//
//  CalculatorModel.m
//  ModelCalculator
//
//  Created by Andrew Rauh on 5/12/12.
//  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
//

#import "CalculatorModel.h"

@implementation CalculatorModel

- (double) addNumbers: (double) numberToAdd1 :(double) numberToAdd2
{
    return (numberToAdd1+numberToAdd2);
}

- (double) subNumbers: (double) numberToSubtract1 :(double) numberToSubtract2
{
    return numberToSubtract1-numberToSubtract2;
}

@end

Now, we need to make an instance of this model class in our main view controller. So, do this:




//
//  ViewController.h
//  ModelCalculator
//
//  Created by Andrew Rauh on 5/12/12.
//  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
//

#import <UIKit/UIKit.h>
#import "CalculatorModel.h"

@interface ViewController : UIViewController {
    
    UIButton *button1;
    CalculatorModel *calculatorModel;
    
}


@property (nonatomic, strong) UIButton *button1;
@property (nonatomic, retain) CalculatorModel *calculatorModel;


@end


And finally, we will actually use and access these methods in our implementation file.

//
//  ViewController.m
//  ModelCalculator
//
//  Created by Andrew Rauh on 5/12/12.
//  Copyright (c) 2012 __MyCompanyName__. All rights reserved.
//

#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController
@synthesize button1, calculatorModel;



- (void)viewDidLoad
{
    [super viewDidLoad];
    calculatorModel = [[CalculatorModel alloc] init];
    
    
    
    //Then you could pass in values from your view into the model methods. 
    //in this case I am just passing two arbitrary values into the method to test it. 
    [calculatorModel addNumbers:3.4455 :5.3];
    NSLog(@"%f",[calculatorModel addNumbers:3.4455 :5.3] );
}

- (void)viewDidUnload
{
    [super viewDidUnload];
    // Release any retained subviews of the main view.
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    return (interfaceOrientation != UIInterfaceOrientationPortraitUpsideDown);
}

@end

I realize this is exceptionally simple, but hopefully it showed the basics of this development pattern for iOS!