At the end of chapter 24 the case against using storyboards seems to amount to:
They suck when developing in teams; and
If you want a view to hang around (and not be reinstantiated every time) Storyview doesn’t permit that.
But won’t most readers of this book be individual developers learning for the first time. That’s my situation. I’m not developing in a team environment. So far, at least, I’m not developing any apps that require a view to be retained throughout code execution.
It seems to me that the vast majority of your typical readers WOULD benefit from using Storyboard - especially for their first solo-effort apps.
Storyboarding sure looks interesting to me … and a whole lot easier than setting everything up manually.
I dislike storyboards. I also dislike ARC. They are designed to give you the illusion that the potatoes grow in the sky and you don’t need to water them. Without knowing what’s happening under the hood of the machine, it is very easy to write space, time and energy wasting programs.
That’s a purist view that I have some sympthy for. It’s somewhat akin to the assembly language programmers who complain that most programming is done in higher level languages.
But making iOS development easier has made it so that there are thousands more developers than there otherwise would be and hundreds of thousands of apps avaialable in the app store. My guess would be that 98% of non-gaming apps don’t tax the iPhone at all. Apple’s checks before the app goes onto the App store, combined with the fact that all apps have their own sandbox, pretty much wipes out the negative affect of inefficient/sloppy programming. Well, that and the marketplace - buggy programs get horrible reviews.
I’m all for making things easier. I love ARC. I couldn’t understand why it wasn’t available from the get go. Makes my coding life much easier.
I’d also be interested in finding out whether anything has changed since introduction of iOS 6 that would strengthen the case for storyboards. Would be interesting to get an one of the authors’ opinion.
I’m all for everything that makes anything easier. Storyboards, to me, don’t make anything easier. In the real world, creating an application is a long, drawn out process where you start with one application and end up with a very different one. If, at the beginning of the project, I could say “There will be 6 view controllers and they all look like this and this is how the user switches between them”, then storyboards would be great.
However, that’s not how it works out in practice. You end up having to change things. You end up having to add more view controllers, change transitions, add new transitions, etc. When instantiating a view controller and pushing it onto the nav stack is two lines of code (and I already have the implementation file open for the class I am editing), I don’t find it easier to find my storyboard file in the project nav, scroll around a bunch of ipad-sized screens with a segue lines going everywhere, locate the view controller I am working on, drag another view controller onto the screen, control click a bunch of connections, and then go and modify my segue override method. That isn’t easier, that is a waste of time.
I finally read this chapter and it is open for my why storybording is not using in this book. But I so exited about this technology (mb it is only because I am naive iOS-newbie)… so I dig in for others point of view. And I found some discussion stackoverflow.com/questions/1264 … g-ios-6-ap
It looks like storyboarding evolving and if you use git it is not so big problem to work on the storyborad as team. I spend few hours for articles and videos (I like how the IB team present new storyboard features on WWDC12 here developer.apple.com/videos/wwdc/2012/?id=407). And finally I decide to try it in my application.
Authors are you still recommend do not use stroyboards? May be there are some other points to do`t do so?
I started using storyboards for an app, and it’s pretty simple, but as Joe said, it has become quite a bit more complex as I’ve fleshed out the ideas that I had at the beginning. Now I’m finding that I want to do a lot of customization that seems would be cumbersome using the interface builder. I think what ibex10 said is true too. It seems easy with storyboards to lose track of what is actually going on.
And, I mean if I wanted to do something like Hypnosister or Hypnosis, or TouchTracker, through storyboards, how would I do that? Can you do that much customization with storyboards?
Let’s revive this thread now that iOS 7 is out of NDA. In the GA version of Xcode 5, you aren’t even given the option of using storyboards or not. You WILL include a storyboard. Well, ok, you can get rid of main.storyboard by deleting it along with the project info.plist entries and associated compiler flags. Apple doesn’t make it easy to get rid of storyboards.
Per this chapter, I did find I could delete the default viewcontroller and substitute a navigation controller, and I could delete the default tableviewcontroller that comes with the navigation controller and substitute a different controller.
So, are the pros/cons mentioned at the end of this chapter still valid? I’m running into all of the touch points mentioned throughout this thread on both sides of the topic. One of our local iOS geniuses, (Joe DeCarlo) swears by them now that he’s “figured them out”. When Apple changes the interface, you won’t be as affected if you’ve used storyboards (according to one argument).
One thought I’m having on a current project is to use storyboards for the general flow, and use methods with .xib files for some of the “widgets”. Is that the best approach? As for the quoted line above, that’s a very interesting question. I suppose you could create a viewcontroller method to associate with the storyboard view controller, then treat that as the controlling point for drawing the concentric circles and shake functions.
I’m sure this will be covered in the 4th edition of the book. Any chance of getting a preview of the content? Or any general comments?