My question is slightly different then my title suggest.
I have worked with xib. Now i am trying to work with storyboard.
My question is if we are navigate through one class from another class, is StoryBoard giving benefit for better memory management.
Suppose we have 2 ViewControllers: ViewControllerA and ViewControllerB.
We are trying to go through ViewControllerA --> ViewControllerB.
Now, in Xib our approach is below;
ViewControllerB *VCB = [ [ViewControllerB alloc] init];
[self.navigationController pushViewController: VCB Animated: YES];
Where in Story Board,
-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
if ([segue.identifier isEqualToString:#"Second"])
{
SecondViewController *objSecond = (SecondViewController*)[segue destinationViewController];
}
}
And Do,
[self performSegueWithIdentifier:#"Second" sender:self];
So, My question is We alloc our class in Xib, Where in storyBoard we aren't.
So is there any memory allocation advantages in storyboard?
My point of view that a professional developer MUST use xibs, but a hobbyist, new to programming, developer might be helped if he uses storyboard.
Storyboard
After a 3 year project work with a single storyboard I can tell a lot of disadvantages:
1) It REALLY gets VERY VERY slow to build even for a very very very little think ( every single view in it must be rebuild ). Also it is very hard to edit even with an iMac with 8 or 16 gb ram if the Storyboard gets bigger. It's even hard to open it.
2) No reusability. There is no way you can import immediately a View/ViewController with its view to another project. It will be connected with other ViewControllers, Views Or Segues and that will make it like a big "don't touch" think.
3) there is so much lag when the project gets bigger even for the smallest layout constraint to be added or edited, that you never want to touch it.
4) If you use the cells by automatic cell addition of storyboard, you cannot use the same cell build in two points.
Advantage:
1) Automatic Cells (But this is also a disadvantage because a cell cannot be reused as is to another view)
2) Segues etc would make it easy for someone to understand with a single point of view what is happening.
Xibs:
1) Fully portable.
2) Open/Edit/Build SO MUCH MUCH MUCH faster than a storyboard that gets bigger
conclusion:
If you are a hobbyist developer who will make an app for his business for fun, you should use storyboard because it will it easier to understand things.
BUT, if you a professional developer, you MUST use xibs for VCs, Cells, etc, Because this is the only way to make them really reusable and portable, in order to gain so much time for the next project, or even when having to make a little change or build the storyboard again.
Explanation why xibs are more "reusable and portable" for me:
Things in programming must be kept in different models, files, entities, modules. One must be as least dependent on another thing as it can get
It is not to tell which one is the best. because which one is good to tell based on team requirement.
If you are a single developer, it is good to use storyboard because it consumes less time. If the team consists of many developers, use xib, otherwise, it is not easy to merge the modules/tasks.
xcode-using-storyboards-and-xibs-versus-creating-views-programmatically
Using XIBs
Advantages:
You can quickly put together a UI
Straight-forward implementation for small apps with a minimal number of screens
You can have separate XIBs for different localizations (ie. languages or countries)
Great at laying out elements and visually spotting misalignments. It’s easy to make a slight adjustment to the layout
Disadvantages:
It’s difficult to merge conflicts when working in a team environment (hard to diff, merge and read)
Highly dynamic views are impossible to describe as a XIB
Performance wise, it’s slower than creating views through code because the xib needs to be read from the disk and analysed/parsed
XIBs lack customizations that you can do in code such as Quartz stuff (drop shadows, round corners)
Harder to debug (i.e. if you forget to make a connection in Interface Builder or make a wrong connection)
Storyboards
Advantages:
Storyboards are nice for apps with a small to medium amount of screens and the requirements for navigation is relatively straightforward between views
You can mock up the flow of an application without writing much, if any, code
Disadvantages:
Storyboards are not compatible with pre-iOS 5 so it makes supporting iOS 4.3 impossible
It’s hard to work in parallel in a team environment because everyone’s modifying the same file
Along the same lines, merging conflicted storyboards in GIT will be a pain
People have experienced bugs in Xcode with the usage of storyboards (eg. having to frequently flush the DerivedData folder because of inconsistencies)
Comparing XIB and storyBoard, StoryBoard is fast.
But Actually fast when do the whole project in programatically.
in storyboard when we compile all storyBoard is Archive to file. and unArchive then run the application.
But, in programatically Classes are allocated at the run time only.
Recommended do project using storyboard.
story board is highly recommended from apple engineers now and highly recommended every thing is central and memory management is done by compiler. how ever pushing a controller is requested by designer in some case and have no issues. but storyboard is recommended and easy to understand view part of MVC
Using Storyboard would be a better option as far as memory utilisation is concerned although storyboards have other advantages also over xib files, Apple also recommends using storyboard over xib files.
Related
So I've been working on a project for a while that has so many view controllers, but I notice that now when I try to do a single edit in any view , storyboard hangs, or become unresponsive . what would be the solution for this issue ? is it possible at my current state to split up the whole storyboard into smaller ones ? and will that resolve the problem ? I'm using Xcode 9.3
Yes. You can have more than one storyboards in one project. In fact that's the preferred way to manage very large projects. To create more storyboards go to File Menu > New > File... and then select Storyboard from the User Interface section. Doing this should resolve your issue. However, if the issue still persist you can consider taking out the specific user interface into its own .xib file.
Update:
If I were in your position I would have considered using .xib files to create my user interface instead of using storyboards. Storyboards do have their advantages but there are some cons too if you use them. Like:
If you work in a team you will run into merge conflicts more often because someone else made a change in the storyboard.
I am still not a Guru in S/W design but, to me it seems like Storyboards violate the Single Responsibility Principle of S/W design.
You won't be using Segues in complex ui flows anyways so what's the point of having every thing in one file.
You won't be able to reuse your UITableViewCells interface. Prototype Cells are a good idea but if you have a UITableViewCell which is used in more than one UITableView you will have to replicate the UI in Storyboard.
In my experience, in a more complex and large project having everything in one Storyboard makes it even hard to comprehend the UI/UX flows as Segues from every view controller seem to connect with every other view controller to the point where it just stops making sense at all.
Yes, it is best practise to distribute viewConrollers into multiple storyboards so that you can open it quickly but it can lead your time to manage each storyboard identification programatically while accessing into code.
Otherwise, you can set storyboard View as : iPhone 5C so that it can load little bit faster than bigger devices.
Refer:
I know this is a question that has been asked quite a bit, but it's iOS 9 and I still don't have a clear idea about what to do. For starters, here is what I seem to be surmising from all the data available:
Storyboards let you create segues. [I've never been a big fan of this answer because segues are often the least harrowing part of creating the UI layout for me.]
Xibs can let you create multiple top-level views. (Storyboards vs. the old XIB way) [I don't think I've ever used this much, though it seems rather helpful.]
Storyboards - Creating UITableViewCells is easier. [In my opinion, it's cleaner to create xibs for the cells and just invoke them in cellForRowAtIndexPath].
Storyboards can turn into one giant ultramassive file that is hard to edit. [I've seen this happen in practice and it is a big drawback, but at the same time...]
Storyboards let you arrange all your Views in one place with the layout shown as well. [This seems to be a big help for me. But then, over the years I've found doing this in code much easier. Which brings me to my final question.]
What is the performance aspect of both of these two things. My app is essentially the following :
A top level hierarchy of interconnected view controllers, not more than 5.
A large number of disparate, independent view controllers that range from Scroll Views to TableViews to static Imageviews.
Autolayout, size classes, the works.
For each of these view controllers, what is the performance of creating a storyboard for each of them vs. creating a xib for each of them. More importantly, what would be a good way to lay out an app like the one I've mentioned.
You definitely want to use storyboards for laying out view controllers - simply because you get access to topLayoutGuide and bottomLayoutGuide which the XIB editor won't give you.
For other views, it's a matter of preference. I tend to use XIBs for table view cells simply because I tend to reuse them on different screens and prefer to have them in their own files.
I would actually advise against manually writing view code where possible simply because it's much harder to read and work out how views are laid out, especially for developers who didn't write the code originally! For simple, dynamically sized things this can be fine, but if you're trying to lay out view controllers with different constraints depending on the size class it's going to end up a bit of a mess.
Yes, it's a pain to deal with merge conflicts of these files, but with iOS 9 you can split up view controllers into different storyboards a lot more easily using view controller references. Personally I find the inconvenience of merging storyboards/XIBs the lesser evil of having to write everything in code.
It sounds like a Storyboard is the right thing for your current project. However, my experience has been that Xibs and Storyboards are problematic in the real world, for these reasons:
extremely idiosyncratic from developer to developer, so it is tricky to build good storyboards as a team
black boxes, so they require a tremendous amount of knowledge to master (unbelievable amount of hidden behavior). Only the most superficial semantics are covered in the documentation.
internationalization is made much harder by being split up, especially if you have internationalized messages not contained in the Storyboard/Xib.
backwards compatibility breaks annually / deprecation guaranteed over time. This is especially difficult if you try to maintain compatibility with older devices.
As soon as more than two devs started touching our code we rewrote everything to avoid Storyboards and Xibs altogether, and we became much more productive.
If you have to deal with any of those real world situations, I heartily recommend programmatically creating all of your views. There is even an app that makes this easier (and is way more scalable). I have no relationship with this company or product, but it is hands down a better solution.
http://www.paintcodeapp.com/
I have to implement the layout of a single screen, which is not connected to the overall app flow, and I was wondering if it makes sense to use a Storyboard.
Storyboards make sense for flow/navigation (multiple controller), have some convenient features like, iirc prototype cells which are not available in xib. And it also makes sense if I think maybe later the screen may become a "story" (more view controllers). But none of this advantages are useful for my particular case.
I was thinking anyways in using Storyboard, as it seems to be a bit more flexible than xib generally, but is there any disadvantage? Maybe performance penalty or such? Is there a preferred way to setup single view controller?
Go ahead..take the advantages of using storyboard. There is no disadvantages or performance issues particular to storyboards when compared to xib files. Its all about your convenience. As you said the single view controller may become a story in future, then the storyboard would be a right decision. And when to use xib? thats upto you, one ideal situation where i will choose xib is, if i have an independent controller that i want to share with other project also then i would choose xib.
The performance penalty would only bother under the circumstance which too many controllers (more than 10) with segues were squeezed in one Storyboard. Everything would be totally fine before that.
And if you have more than two people are trying to edit same storyboard file than you have to resolve conflict, which will be more tedious job.
Storyboard benefits:
a. easy demo purpose and fast implementation.
b. small team like two person.
c. Storyboard is providing complete view and navigation model.
XIB benefits:
a. You can modularize your code.
b. More people can work on different-different controller without affecting your xib or code.
Lately, when I navigate to my storyboard, I get the pinwheel animation for a few seconds and the laptop's fan goes into high gear for about a minute. This used not to happen, and I almost never hear the fan otherwise.
Firstly, is this indicative that there might be something wrong in my storyboard, or is it inevitable as the storyboard grows? The storyboard has about 25 VCs right now.
It will be adding many more VCs to the storyboard in the future. Some of them will be isolated, i.e., have no segues to any other VCs. Should I use nibs for those VCs in order to improve performance? Are there any drawbacks to using nibs in addition to a storyboard? Thanks
Yes, this will happen as the complexity of your storyboard increases. There are no technical issues using nibs in addition to a storyboard.
I prefer to use a third solution and have multiple storyboards each of which contains a logically distinct sub-set of view controllers. This retains the flexibility afforded by storyboards without allowing them to become too unwieldy.
You might be interested in http://www.raywenderlich.com/51992/storyboards-vs-nibs-vs-code-the-great-debate. Also read the comments.
All of our views are in a single storyboard. After we edit the interfaces we are responsible for, we find it is a disaster when we commit the storyboard. Do any better ways exist that make it easier to manage the storyBoard? Should we write UI with code instead of storyboard or xib? While it is really efficient to use storyboard.
What's generally worked for me and my team is to separate related functionality into different storyboards. So if one person is working on x portion of the app, stick all things x related there. As long as only one person is dealing with each component at a time, there's no chance for conflicts that blow up your whole storyboard.
Another thing to keep in mind if you can only use one storyboard, is to limit who can work on each ViewController in the storyboard. It's not the best idea to have multiple people working on the same controller anyways, since you will both be interfering with each others layout. I have found that as long as we stick to our own components, merges are super easy.
Your solution of using code instead of storyboard is also a very valid way to go about it. The decision between code and xib based approaches depends on the user. Code takes longer to get going, but is super easy to reuse, whereas xibs/storyboards make prototyping a snap but are very hard to reuse.
You need to read this links:
http://blog.waynehartman.com/archive/2012/01/07/uistoryboard-on-ios-5-the-good-the-bad-and-the.aspx
http://www.linkedin.com/groups/Which-is-better-StoryBoard-NIB-162305.S.185584395
Should I use storyboard and mercurial for team work?
Storyboard is one single file, so only one person can work on the storyboard at once. It is essential factor for working with team in iOS.
The following post helped me to understand answer on this question:
http://robsprogramknowledge.blogspot.pt/2012/01/uistoryboard-best-practices.html