I'm creating a reference app for a game showing everything the user needs to know in order to be good at the game. Weapons, maps, random information, etc.
I am 1/10 of the way done and I already have over 45 views controllers in my storyboard. I only have one storyboard since I don't know how to create another one and link it to the first storyboard. The storyboard is starting to lag a little bit. How many views is too many views?
Once I'm done, I'm guessing I'll have over 100 view controllers in one storyboard. Is that too many? If yes, is there a simple way to fix that problem?
(I have so many views controllers because I created one for every individual item.)
I would create 5 storyboards (one for every category in the main menu) to see if it would reduce the lag, but I don't want to do that if it's not going to help.
You can create multiple storyboards in one application and Apple do not stops you from doing that. It is highly recommend to divide your app screens into modules and put those modules into different storyboards and navigate between them flawlessly.
You can have a look at this library for integrating multiple stroyboards in your application:
https://github.com/rob-brown/RBStoryboardLink
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 am busy to learn building applications for iOS and started creating one by myself. I am currently running against the following and am curious about the process of other iOS developers out here.
Populair apps like Twitter has multiple sections within a view controller. What is the best method to organize a layout on one Storyboard with multiple sections like a header section with labels, a tableview and a mapview?
"What is the best way to..." type questions are not a good fit for SO. That leads to opinion-based answers, and possible arguments.
Better to ask "What are some options to..." type questions.
If you are looking to create a modular design where you divide your screen into discrete tiles, you can look at using container views and embed segues. With that design you can make a view controller responsible for a section of the screen. Then you can embed one of those view controllers in another view controller wherever you want it.
I won't say it is "the best" way, but it is an approach that can be useful.
I am new to iOS and have recently finished some classes.
Now, I'm onto my first app with Swift. I wanted to know:
Is it necessary to define all views/screens in the storyboard right in
the beginning, with proper navigation controllers?
What is better, define all in the beginning or keep adding as need
arises in the future?
Keep adding as needed.
You'll always be finding or coming up with new features, and at times you'll need to insert view controllers between other view controllers (adding an extra step, for example).
Within view controllers, you'll also find the need to put items into containers. That's where clicking the item/s (selecting them), and going to the menu, selecting "Editor" and then "Embed In" comes in really handy. For example, you may want to put a series of items into a scrollview after you've already laid them out properly, because they don't display properly on an iPhone (and you had done all of your testing in Simulator on an iPad first).
No it's not, you can create all views programmatically without using a storyboard at all. Its's just your choice what works better for you.
First of all, you can use storyboards for your UI (and navigation), use .xibs (only UI) or create everything programmatically. Each of these has its pros and cons. Also you can mix and match all these. For example have a storyboard, some views with .xibs and some views created programmatically all in the same project. You just have to choose what fits best your needs.
You don't have to create everything in the storyboard right in the beginning. Create only the views you need to start coding and then add more views as you progress your app development.
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.
I have read a lot about creating a lite and a paid version with Xcode and in my app I am using multiple targets and preprocessor macros as described in this Stackoverflow post. However, I don't know how to handle different targets with a Storyboard.
For example, in my storyboard I have a table view controller with static cells. In the paid version it has four cells, in the lite version has one extra cell whereas the rest of the storyboard remains unchanged. Is there a way to achieve that kind of behavior?
(Creating a new storyboard for the lite version (or duplicating it) is not an option for me as I have dozens of view controllers and 98% of the views and UI elements are identical in both versions. It would make the project difficult to maintain.)
For example, in my storyboard I have a table view controller with static cells. In the paid version it has four cells, in the lite version has one extra cell whereas the rest of the storyboard remains unchanged. Is there a way to achieve that kind of behavior?
If you hadn't boxed yourself in by using a static table, this problem wouldn't have arisen in the first place; you'd be configuring the table in code, which can be conditional — end of issue.
As things stand, you'll need two different scenes in the storyboard, one for the paid version, the other for the lite version. Then:
If this scene is reached by a segue, you'll need two different segues that reach this scene, and you'll decide in code which one to trigger (and trigger it in code, not automatically).
If this scene is the initial view controller, you'll need to instantiate it initially in code rather than letting UIApplicationMain do this for you. Or, in that case, use two different storyboards for just this one scene, and then segue to another storyboard.
(And do keep in mind that multiple storyboards are a great way to organize your scenes in any case. I don't necessarily mean multiple alternative storyboards; multiple sequential storyboards can keep your storyboard from becoming overly complex. It sounds to me from your question as if all you need to do is understand how storyboards work - they are not magic, you know - and be more nimble in your use of them. Your entire deer-in-the-headlights fear of duplicating your storyboard - "I have dozens of view controllers" - suggests you've already gone way too far down the wrong road. Programming is like solving a Rubik's Cube: if you're in the middle of it and your response to someone trying to change something is "don't touch it!", you're doing it wrong.)