I am planning to learn to develop applications using Story Boards. Can anyone please post some advantages and disadvantages while using StoryBoards?
When to use Storyboard and when to use XIBs
What are the benefits of using Storyboards instead of xib files in iOS programming?
iphone-sdk-development
I think these links are helpful and related to your question. Personally, I believe storyboards are better then nibs because they eliminate the need to code your transitions between views (unless you use custom transition with CA), and they have all the capabilities of nib files too.
Hope this helped.
-----------EDIT-----------
Here are some more links I found:
This one speaks about some of the cons of using storyboards.
UIStoryboard on iOS 5: The Good, The Bad, and the 'This Plain Sucks'
This one is mostly about the benefits.
What are the advantages of iOS 5.0 storyboarding over traditional UI layout?
It's mostly cons. Don't use Storyboards. Here's is a list of their problems, copied from iraycd:
Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.
Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.
Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.
Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.
Storyboards make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.
Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.
Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.
Storyboards are not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.
Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.
Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.
Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.
Storyboards don't allow you to add a subview to a UIImageView: Who knows why.
Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)
Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
Related
I'm working in a company where we have several iOS developers and we use GIT to work in the same projects together. We never use Storyboards or .xib files in our development process as it's nearly impossible to merge them correctly.
With the introduction of the iOS7 I thought about the fundamental differences between Storyboards and coding all the UI "the old way", without the use of Interface Builder.
Is there anyone here who does just that? And most importantly, is there something you CAN do in Storyboards that you can't do in code in XCode 5?
I'm going to split your question into two: NIBs, and storyboards.
As far as NIBs are concerned, source control issues can be painful but manageable, mainly because you've typically got one NIB file per view controller. You could imagine a situation where you have two developers working on two different sections of your NIB powered app without any merging issues. Storyboards are different, since you have one single file that describes most - if not all - of the UI of your application. Clearly there is a far greater potential for conflict issues there.
NIBs can be extremely useful and time saving, if used correctly. Here's an example: the iPhoto App on iPad has a very complex UI. The vast majority of that UI is laid out programatically. However, the app also uses NIBs to load in graphical elements which are then laid out in code. This is how the brush panel works - all the brushes are created in a NIB. This means that Apple don't have to have dozens of identical image/image view alloc/init pieces of code. All the creation can happen in a NIB (this was discussed in some detail in a WWDC 2012 session on the iPhoto UI - it's well worth tracking down).
So NIBs - sometimes good, can save you a lot of time, and whilst there are merge issues they can in many cases be easily managed and handled.
Then we come to storyboards. Storyboards are interesting. On the one hand, they are extremely helpful and useful for straightforward apps and developers new to the platform. I've just converted a UINavigationController based app from NIBs to storyboards and found some significant time savings (particularly around table views, since with storyboards you can take advantage of prototype cells).
However, if you're working on a large scale project with several developers I'm not convinced storyboards are that beneficial. There are, as you say, big issues with merge conflicts, and unlike NIBs it's not easy to resolve them since that single storyboard file controls all of your app UI.
Here's what I'd suggest (and feel free to ignore me!) - if you're currently developing apps and doing your layout/UI entirely in code consider whether NIBs might save you time. They may well not - they're not for everybody - but it's well worth at least considering. You may be surprised at how many large apps actually use NIBs (iPhoto, as I mentioned, but also many built-in apps provided by Apple, as well as many popular third party apps by large teams). I probably wouldn't consider storyboards unless you were a sole developer working on an app with fairly straightforward navigation. That's not to do down storyboards in any way - I love using them - it's just they're not really suitable for collaboration.
Somebody posted this comment in reply to your question - I wanted to discuss it:
There is nothing you can do in storyboard and can't do in code. Objects, gesture recognizers, segues, even constraints - are all available for you to build programmatically
This is technically true, but in reality there are things in storyboards/NIBs that are much easier than code. A good example of this is auto layout. Whilst you can certainly manage your auto layout contraints entirely in code, the harsh reality is that the ASCII auto layout representation is much harder to work with than the visual representation you get in IB. This is especially true on XCode 5, where there are massive improvements to auto layout in IB (I can't detail it too much as it's still under NDA, but Apple publically talk a bit about the changes here).
For me the only big drawback of storyboards is the slow loading time and the usual lag that comes when navigating the storyboard. I'm not talking about 2-5 view controllers apps. I'm talking about 10 and more...
My personal preference is smaller storyboards if I really have to use them(UITableView prototype cells) or just plain xibs.
Doing it in just plain code is just a matter of .... do you have enough time on your hands? :) Usually you wont gain a lot from doing it this way.
You should consider these issues in your dessision:
Development time -
Obviously, working with the xcode UI designer is much more faster and easy to learn when creating new applications from scratch.
In the programmatically way, you will have to define in code each and every element property you'll want to set.
Working with storyboard will make the development process much faster.
Code reuse -
When working with storyboard you will have to bind UI elements to the controller with bullets that adds additional hidden code in the storyboard file. Same stubs are added when creating segues between controller.
This addition hidden code will make make it more difficult to reuse the controllers in other apps that you'll build.
If you are planning to make mass reuse of you controllers code, than creating the UI elements programmatically will be more suitable.
Source code integration -
Conflicts resolving is a common thing when several developers commits changes to the file.
Creating and changing UI elements with storyboard additional changes are added to the storyboard file that sometimes makes the conflicts resolve kind of tricky.
On the other hand, when changing UI elements programmatically only the changes that you'll make will be added the the controller file.
I have a question about universal app. My app will not have storyboards or xib file. There is possibility to write universal iPhone/iPad application without it? I found some tutorial how to create universal app with storyboard, but i don't want (i can't) use this feature in my project.
If it is possible What should i do? If i have to made changes only in ViewControllers? I'm start to do this, i'm not changing old project so i can do anythng - what should i learn/what should i remember?
I'm targeting to iOS 5.
EDIT:
I have a screen information in resource file and my rootViewController or any other ViewController will be created in compile time, so i can't have xib file for that, i can't put button on xib with Interface Builder becouse i don't even know how many buttons i will have there. I don't know how many screens i've got till i hit run in my project.
Not only can you write any type of iOS app without Interface Builder, it is actually much more testable and pliable. Some auto layout tricks are difficult (not possible?) in IB style projects, as well.
There is an incredibly impressive library called Masonry that wraps the NSLayoutContraint syntax. This makes it quite pleasurable to subclass views while not having to use ugly VFL or incredibly verbose NSLayoutContraint syntax (not even going to address frame setting...blech!). IB style apps also promote bad software development practices and anti-patterns (just dumping everything in a view controller presentation-wise. No Separation of Concerns!). Also, it is more difficult to work on larger teams (IMHO even small teams) while utilizing Nibs, Xibs, and Storyboards due to merge issues.
On top of all of that, you gain a much deeper understanding of the classes you are working with (UIView, UIResponder, etc.) when writing code in this manner (once again IMHO). There is an interesting article outlining some of these issues in more detail: http://doing-it-wrong.mikeweller.com/2013/06/ios-app-architecture-and-tdd-1.html This is by no means the only article that discusses this problem. Also, this will help for your app delegate: creating a universal window-based iphone app without generated xib file
This is certainly possible, I have only used storyborads once in the many apps I have published. As for not using XIBs, I am not sure why you would want to do that. You can lay out your views at runtime in the init method, but I feel like that is just making things unduly hard on yourself. You can set a XIB up for the iPad and one for the iPhone so you can tailor the UI specifically to each device.
Perhaps if you go into a bit more detail about why you are imposing this requirement on yourself we can discuss if it si worth the effort to go down that road.
Good Luck.
Having used storyboards for a while now I have found them extremely useful however, they do have some limitations or at least unnatural ways of doing things. While it seems like a single storyboard should be used for your app, when you get to even a moderately sized application this presents several problems.
Working within teams is made more difficult as conflicts in Storyboards can be problematic to resolve (any tips with this would also be welcome)
The storyboard itself can become quite cluttered and unmanageable.
So my question is what are the best practices of use?
I have considered using a hybrid approach having logical tasks being split into separate storyboards, however this results in the UX flow being split between the code and the storyboard. To me this feels like the best way to create reusable actions such as login actions etc.
Also should I still consider a place for Xibs? This article has quite a good overview of many of the issues and it proposes that for scenes that only have one screen, xibs should be used in this case. Again this feels unusual to me with Apples support for instantiating unconnected scenes from a storyboard it would suggest that xibs won't have a place in the future but I could be wrong.
You are correct, breaking up the storyboards is the best way to go. Decomposition does more than just make parts of the UI more reusable. It also makes using storyboards in a team more manageable.
Lately, many of my storyboards have contained four or less scenes. It is easy enough for one person to solely build and maintain one or more of such UI modules. This practice reduces or eliminates merge conflicts.
In the case I do need something changed in a storyboard owned by someone else, I ask the owner first if he or she has any local changes. If so, I sometimes have the owner add the changes for me. Decomposition still requires some coordination, but it is substantially less than a full-app storyboard. Ever since I started this practice, I haven't had any merge difficulties.
As for XIBs, I don't think I wrote enough about them in my article. They are still very useful. They can be nice for single view controllers. However, this is not where they truly shine. XIBs have one advantage that storyboards may never have. The most basic unit of a XIB is a UIView, whereas the basic unit of a storyboard is a UIViewController. Since XIBs can hold collections of UIViews, they are great for visually creating custom controls. In a XIB, I can visually build a rotary dial or a GPS widget. Then I can drop these controls and widgets into storyboards or other XIBs. Such XIBs are seen more often in iPad apps since they have larger screens capable of holding many controls and widgets. It would be unnatural to build a UISwitch within in a UIViewController in a storyboard.
Now for the best news. It is possible to connect storyboards within Interface Builder and without writing any code. I was planning on releasing this technique after WWDC, since Apple may release similar functionality in iOS 6. However, since you asked, I decided to release it now. Rather than duplicate my explanations on how RBStoryboardLink works, you can find more details on my blog and on GitHub. This will make your UIStoryboard experiences much more enjoyable.
I found this article mentioned a lot of issues when using StoryBoard, one thing the author raised is using a huge of nib files in one StoryBoard, which I agreed he shouldn't do that, but there was other issues such as:
My root view controller has become a source view controller for lot of
segues and therefore its prepareForSegue: has become a stupidly large
method filled with a lot of “if (segue.identifier
isEqualToString:#”…”)” statements in a row
and
It is possible to assign view controllers in a storyboard an
identifier. Unfortunately this identifier property is not exposed in
the UIViewController class. This makes it very hard to perform safe
introspection of the view controller hierarchy at runtime. It would be
really nice if identifier was exposed for view controllers as well as
for segues.
and ...more other issues, I thought it does make sense, and I'm worry whether should or shouldn't use StoryBoard for now ??
Can someone explain in simple words the difference between .xib and .storyboard?
Apple introduced the concept of "storyboarding" in iOS5 SDK to simplify and better manage screens in your app. You can still use the .xib way of development.
Pre-storyboard, each UIViewController had an associated .xib with it. Storyboard achieves two things:
.storyboard is essentially one single file for all your screens in the app and it shows the flow of the screens. You can add segues/transitions between screens, this way. So, this minimizes the boilerplate code required to manage multiple screens.
Minimizes the overall number of files in an app.
You can avoid using Storyboard while creating a new project by leaving the "Use Storyboard" option unchecked.
You could refer this tutorial to get started.
Yes, you can still create a Window-based application for iOS 5. If you use the "empty project" template, you will see that a window is created for you in the app delegate. From there you can add XIB files as normal, or a new storyboard.
I'm assuming you mean "storyboards" rather than "timeline". Storyboards allow you to map out, visually, all of the views in your applications and how they interrelate. If you are just starting out with storyboards, there's an introduction to storyboards in the WWDC 2011 videos here. The 2011 Stanford iOS course on iTunes-U is also iOS 5-specific and covers storyboards and more.
A storyboard is like a canvas where you put all your .xib files. You no longer have any .xibs, you just have View Controllers directly on your canvas.
storyboard is a new feature available since the release of Xcode 4.2.
It offers a complete new way for iOS developer to create and design
user interface. Before the introduction of Storyboard, it’s especially
hard for beginner to create navigation (and tab) interface. Every
interface is stored in a separate xib file. On top of it, you have to
write code to link all interfaces together and describe how the
navigation works.
With Storyboards, all screens are stored in a single file. This gives
you a conceptual overview of the visual representation for the app and
shows you how the screens are connected. Xcode provides a built-in
editor to layout the Storyboards. You can define the transition (known
as segues) between various screens simply using point and click. This
doesn’t mean you do not need to write code for the user interface. But
Storyboards significantly reduce the amount of code you need to write.
Source: http://www.appcoda.com/use-storyboards-to-build-navigation-controller-and-table-view/
XIB:
Xib files are used with a single UIView.
2)It's very difficult to implement complex auto-layouts in xib.
3)It's utilizes more memory as compared to storyboard and quiet slow.
It is compatible from iOS5 and onwards
You can do localizations for different languages and countries using
different XIBs .
It's difficult to use same Xib to support multiple devices.
Storyboard
1)You can layout all your Scenes like View Controllers, Nav Controllers, TabBar Controllers, etc in a single storyboard.
2)You can use Auto Layout easily that defines mathematical relationships between elements defining their position and sizing.
3)Usually fast and allocates less memory.
4)It's not compatible prior to iOS 5 .
5)"Dynamic" and "Prototype" cells can be used easily.
6)Storyboards best to use for the apps with a small to medium amount of screens.
The best Answer I have seen : Xib Vs Storyboard in iOS
XIB and Storyboard are used for creating interfaces for users.
One important point is,xibs are used for creating a single view(it has single file owner at the top of the xib file), but in-case for viewcontroller, multiple screens can be added and its flow can also be monitored(it has separate file owners).
This is Cocoa Touch (et al), iPhone, XCode only.
After completing my first commercial iPhone app, I'm struggling a bit to find a way to start and expand an app from scratch which gives the most linear development (i.e., the least scrapping, re-write or re-organization of code, classes and resources) as app specs change and I learn more (mostly about what Cocoa Touch and other classes and components are designed to be capable of and the limitation of their customization).
So. File, New Project. Blank window based app? Create the controllers I need, with .xib if necessary, so I can localize them and do changes requested by the customer in IB? And then always subclass each class except those extremely unlikely to be customized? (I mean framework classes such as UIButton, CLLocation etc here.)
The question is a generic 'approach' type question, so I'll be happy to listen to handy dev practices you've found paid off. Do you have any tips for which 're-usable components' you've found have become very useful in subsequent projects?
Clients often describe programs in terms of 'first, this screen appears, and then you can click this button and on the new screen you can select... (and so on)' terms. Are there any good guides to go from there to vital early-stage app construction choices, i.e. 'functions-features-visuals description to open-ended-app-architecture'?
For example, in my app I went from NavBar, to Toolbar with items, to Toolbar with two custom subviews in order to accommodate the functions-features-visuals description. Maybe you have also done such a thing and have some advice to offer?
I'm also looking for open-ended approaches to sharing large ("loaded data") objects, or even simple booleans, between controllers and invoking methods in another controller, specifically starting processes such as animation and loading (example: trigger a load from a URL in the second tab viewcontroller after making sure an animation has been started in the first tab viewcontroller), as these two features apply to the app architecture building approach you advocate.
Any handy pointers appreciated. Thanks guys.
Closing this up as there's no single correct answer and was more suitable for the other forum, had I known it existed when I asked :)
If you want to know the method I ended up with, it's basically this:
Window-based blank app
Navigation Controller controls all, whether I need to or not (hide when not used)
Tab Bar Controller if necessary
Connect everything <-- unhelpful, I know.
Set up and check autorotation, it might get added to some view later.
Add one viewcontroller with xib for each view, you never know when they want an extra button somewhere. It's easier to copy code than make the max ultra superdynamic adjustable tableviewcontroller that does all list-navigation, etc.
Re-use a viewcontroller only when just the content differs in it, such as a detail viewcontroller.
Minimize code in each viewcontroller by writing functions and methods and shove them in a shared .m
Everything that's shared ends up in the App delegate, except subclassed stuff.
Modal viewcontrollers are always dynamically created and never have an xib.