Are storyboards forcing you to write ugly code? - iphone

Question

I've been developing everything with xib files because we needed to suport iOS4.
Now we are finally supporting only iOS5 and iOS6, so I decided to give storyboards a try, so everything is fine and easy, but I have found myself doing a lot of code like this:
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
if ([segue.identifier isEqualToString:#"AddPlayer"]) { //Ugly
UINavigationController * navigationController = segue.destinationViewController;
PlayerDetailViewController * playerDetailsViewController = [navigationController viewControllers][0]; //Super Ugly
playerDetailsViewController.delegate = self;
}
}
I don't know about you guys, but I found this code very ugly and error prone.
Is there a better way for working with Storyboards? Should I got back to xib files?

Answer 1

I worked with Storyboards quite a lot in the last app we built where I work and yeah, I agree the boilerplate code gets pretty annoying after some time, but as far as I know using prepareForSegue is the only way to pass parameters when using segues.
You can't assign properties/delegates on a custom view controller from the Storyboard itself.
Would I go back to using XIB's if I only target iOS 5 & 6? It
depends.
If I had to build a small - medium app (not too many views and not a lot of cross-navigation between them) I would definitely use Storyboards. But when you have a lot of views and a lot of back and forth navigation between them, it really gets complicated to keep the Storyboard nice and tidy, and it feels like you are forcing yourself to use something that actually isn't the best.
On the other hand I feel Storyboards make it much easier to get a feel of the flow and general look of the app when starting from scratch, and you can even use them to create mock-ups that will actually look like the real thing.
So in essence it boils down to what your needs are when starting a project.
EDIT:
Another thing to take into account: if you use SVN/Git or any other VCS to work with a team, Storyboard file conflicts are a total bitch.

Answer 2

I agree that is an ugly code and to smooth my vision I created a macro:
#define WhenSegueIdentifierDo(segueIdentifier, block) if([segue.identifier isEqualToString:segueIdentifier]) block();
And in my prepareForSegue:
WhenSegueIdentifierDo(kModalVC1ToVC2, ^
{
//code
});
WhenSegueIdentifierDo(kModalVC1ToVC3, ^
{
//code
});
I also use constants instead of hardcoded strings (although I cannot use them on storyboard) to keep it more beautiful. I also use a convention: k + type of transition + origin view controller name + to + destination view controller name.
You could also use
navigationController.topViewController
instead of
[navigationController viewControllers][0];
Just my 2 cents...

Answer 3

That's just the nature of the beast. Objective-C using Cocoa conventions produces - (hopefully) self documenting, albeit, verbose code. Looking at your example, I have no problems determining your intention.
Now, if you wanted to make it pretty, you could encapsulate all this into a macro so that it would be condensed to one line. While it may be prettier to behold, it would certainly add unnecessary complexity in maintaing the beast. The end user isn't going care how pretty the code is -- unless it prevents adding new features.
As for discussing storyboards ... they are certainly different but having used them now for six months, I do appreciate having all my nibs in one centralized place instead of spending the time to look for individual files. It's much easier for me to find things by visual layouts, then parsing camel cased file names. That's just me.
My advice, give them time. In a few months if you find them inhibiting your workflow, then by all means, go back to individual nibs. They aren't going anywhere. At least for awhile.
Just my two cents. Good luck!