Now that Apple has released storyboarding, are xibs deprecated? I've found some of my old tricks (i.e. connecting other views in ib) to not work anymore. But yet at the same time it's nice to have all my views in one file. Thoughts?
Deprecated? Not yet.
Outdated? Yes. Since iOS 5, many new Interface Builder features (like static table view cells and unwind segues) are only for storyboards and not xibs.
Apple also recommends using storyboards in their own documentation:
View Controller Programming Guide for iOS:
In short, creating a user interface means instantiating and configuring many objects and establishing the relationships between them, which can be time consuming and error prone.
Instead, use Interface Builder to create storyboards.
Table View Programming Guide for iOS:
The easiest and recommended way to create and manage a table view is to use a custom UITableViewController object in a storyboard.
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:
Is Multiple Storyboard in single project is better than single storyboard??if yes then why??
Which is better Single Storyboard or Multiple Storyboard??
Any one please clear me the above queries.
It depends on the project requirement. If you are good enough with the size classes and auto-layout and also if the requirement flow is almost similar for all the devices then go with single storyboard.
By default in Xcode 6 or later, recommending to use single storyBoard.
If you have a bigger app and/or not only one man team:
You should NOT use single story board. Like its name says, it is a "STORY" board. You should have one Story in one Board. This keeps the readability and maintainability of the storyboard.
If you have a team, it is a nightmare to "merge" one single story board if 2 made changes in it at the same time. It is more or less impossible. But if you have for each story a corresponding storyboard, even in a scrum team you can manage to work on one storyboard only one person, that you do not need merging.
There are a lot usefull documents and workshops in internet if you google "ios storyboard git merge ...."
When to Use Storyboards
Finally, while Storyboards are best used for scenarios involving multiple view controllers, it’s also defensible to use a Storyboard when working with a single table view controller for three reasons:
The ability to design table cell prototypes in-place helps keep the pieces together.
Multiple cell templates can be designed inside the parent table view controller.
It’s possible to create static table views (a long awaited addition that’s unfortunately only available in Storyboards).
When Not to Use iOS Storyboards
A few cases:
The view has a complicated or dynamic layout, best-implemented with code.
The view is already implemented with NIBs or code.
When to Use NIBs for iOS UI Design
A subset of all uses cases would be:
Modal views
Simple login and registration views
Settings
Popup windows
Reusable view templates
Reusable table cell templates
Meanwhile…
When Not to Use NIBs
You should avoid using NIBs for:
Views with dynamic content, where the layout changes significantly depending on content.
Views that by nature are not easily designable in the Interface Builder.
View controllers with complicated transitions that could be simplified with Storyboarding.
Apple's docs say that you may have multiple storyboards. Unfortunately they don't go into any real detail on how to do that. As you've found out, Interface Builder won't help you, so you'll have to do it in code. It works much like loading XIBs:
[UIStoryboard storyboardWithName:#”MyNewStoryboard” bundle:myBundle]
Having said that, if you don't "want one big/bloated storyboard" as then XIBs really are the way to go. That 'bigness' is the benefit: all the transitions between VCs are laid out in one place. Having multiple storyboards is really so that you can support multiple different and unrelated flows through your app: for example, one storyboard for a complex configuration flow and another one for the main user flow.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Currently we use Storyboard over xib in all projects. But in my view if you want to make reusable view (custom view or Tableview cell) which can be re-used in different view controllers, you must use xib files as in storyboard there is no way we can make single view object separately.
Note that I am using Storyboard for workflow (view controllers with segues all around) of entire application. Only for reusable tableview cells I am using XIB.
I have searched in lot of apple documents as well as WWDC videos but I could not find any concrete proof from Apple developers which says that XIBs are here to stay or you should use XIB for custom views.
If any of you guys have any kind of links which gives somewhat confidence that we can still use XIB without fear of apple removing it, it would really be appreciated.
Storyboards are recommended when you don't reuse views.
Once you want to reuse something in multiple views/storyboards, then you need XIBs. You already mentioned the example of custom cells. That is something I need quite often and I want to use the same cell in multiple table views. I do the same with charts. I create a chart view in which I set colors etc. and I reuse it everywhere, only putting different data in it. This saves me a lot of code in respect to style/appearance and makes the app easily maintainable. In case of change (e.g. because of new iOS version), I need to change everything on a single place.
Furthermore, I want to have views (e.g. cells) for iPhone and iPad and let the system determine which one to use. For this, again, I need XIBs. I use the notation with ~iphone or ~ipad at the end and I don't have to write code for retrieving the correct view.
This are two things that you simply cannot do without XIBs. So, following the Apple guidelines, my approach is to use storyboards whenever possible and XIBs only when I need them (mainly because of reusability). But there are real cases when one needs XIBs! Simply ignoring them is not a good practice for sure. Actually, in each project I have storyboards as well as XIBs.
Edit: I just found a great post explaining the disadvantages of storyboards. There are plenty of things that I was not aware of.
Also, you don't have to use either exclusively. You can still use XIB files even if most of your work is in storyboard. And using either also doesn't restrict you from creating a view that isn't built in IB at all.
Storyboard has plenty, plenty of advantages. Particularly when you start bringing new people in on the project. Without getting engulfed looking at hundreds of thousands of lines of code, a new developer can look at the storyboard and in 30 minutes or less get a quite good idea of the flow of the app.
With that said, you should never limit yourself to anything. Limiting yourself to just storyboard and never using XIB or building a view completely in code is like saying "We're only going to use NSArrays, and never NSDictionary or NSSet". Instead of a silly limitation, you should always just be sure you're using the right tool for the job.
My opinion is use which one is appropriate for that context, here is some guidelines:
When to use nibs
Modularity is key to well designed nib files
Use nibs to store views, subviews, custom controls or repeated views
There’s no way to represent the relationship between screens of related content
When to use Storyboards
Storyboards are best used to represent screens of content and the connections between those screens
Give due care and attention to the prepareForSegue:sender: method
Modularity is still applicable when designing storyboards
General Guidlines
Decompose your projects into nibs and storyboards
Views, subviews and custom controls should be contained within separate nib files
Use storyboards when designing full screen content and there are clear relationships between scenes
Consider whether the interface needs to be static or dynamic
Use separate storyboards to encapsulate reusable sequences of scenes
Use separate storyboards for unrelated scenes
Table view cells that can be reused across different controllers belong in nib files
I'm trying to develop a universal iOS app and ideally I'm trying to get as much code re-use as possible.
I'm using storyboards so the UI is segmented into scenes.
In the iPhone storyboard the particular scene in question is best suited to a table view.
In the iPad storyboard, the equivalent scene in the storyboard would ideally implement a UICollectionView and so render the content in a grid.
Both views should implement a pull-to-refresh control which in one case is going to call a [UITableView reloadData] and in the other a [UICollectionView reloadData].
Anybody any advice on how to get the maximum amount of code re-use, ie. what does the controller class look like?
1 option would be to have 1 monolithic class that conforms to both the UITableView protocols and the UICollectionView protocols but this doesn't feel right.
Another option would be to have a base class and then subclass it with specialisations for iPhone and iPad. Whilst this feels cleaner, I'm still thinking there might be a better way. In my first attempt at this it felt like there was more code in the specialisation classes than there was in the base class.
The third plan I've considered is simply to use a UICollectionView in both apps therefore eliminating the complexity of the controller. Hopefully I could force the layout of the collection view to be a grid on the iPad whilst tell it to mimic a table view on the iPhone.
Whilst on the face of it this sounds easy I'm struggling to make a UICollectionView work exactly like a table view would do normally.
Any advice guys?
Many thanks,
CA.
If you are not using some of the specific UITableView features[1], making UICollectionView look exactly like a table is trivial. I think I would go for using UICollectionView as it will allow more flexibility in the future and you will have to use it anyways.
When you are talking about code reuse you probably mean the DRY principle. It just says you should not write the same code or the same information twice, but I don't think this is your main issue here.
I would use a UITableViewController on the iPhone and a UICollectionViewController on the iPad. I think this is the cleanest and easiest way to go. What exactly do you hope to reuse among both controllers? The both require two different delegate protocols, so most of the methods will be specific to one platform. You will need two NSFetchedResultsController if you're using Core Data, but reusing the fetched results controller code only makes sense if you need the same data on both platforms.
If you create a new universal project in Xcode you will get a basic project setup that looks different on iPhone and iPad. Try to understand it (there are some details to pay attention to) before you start programming, I think it will answer at least some of your questions.
I want to create a custom UIProperty Control that is not more than a UILabel and a UITextField grouped together and add it to IB's Custom Objects list to reuse in other Nibs.
I found a lot of documentation and everything points to creating a Xcode or IB plugin project, but everything refers to Xcode 3.x and there are no parallels in many spots.
Anyone cares to help?
Thank you in advance
Unfortunately, it's not easy, if even possible at all. Unlike Xcode 3, in XCode 4, Apple has pretty much eliminated this feature. They now say you must create the class manually first and then associate the controller object using Interface Builder.
InterfaceBuilder Docs explain how to do it now in Xcode 4 using a custom object.
And from the xcode 4 transition guide:
After adding the source file templates to your project, drag a custom view object from the library into the nib file. After adding the custom view to your nib, select the custom view and assign the correct class to it in the class field under Custom Class in the Identity inspector
Some more resources:
iphone-creating-custom-objects-for-interface-builder
Interface Builder Help - Custom Object
Xcode 4 doesn't do plugins.
Creating something that will be customizable in IB doesn't seem to be possible at this point. I think the strategy being used by and large is to avoid IB and do it all in code (e.g. most everything on cocoacontrols.com).