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.
Related
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 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
I am writing a text editing app. I target iOS 6 and 7, and use storyboards and autolayout.
I thought this layout for the welcome screen would work well:
<Files in a table view>
<Instructions to user>
<Settings>
The settings view is pretty complex, and will probably benefit from having its own view controller. The instructions view is static, and has no logic.
I can think of three ways to organize this:
Create this as a table with three sections, where the 1st section is the list of files, and the 2nd and 3rd section are big, custom cells with.
Wrap all three views in a scrollview
Wrap the instructions and settings in a scrollview
I prefer the first solution, as it seems to be the, most natural way for the user to navigate, but I haven't seen any examples of adding a viewcontroller as a cell for a tableview anywhere, and haven't been able to google me any. Prototype cells do not seem like the right way to go for the settings view/controller either.
Best practice, suggestions, input?
Apple recommends only one view controller per "screen," so that rules out option 1. I wouldn't want to even start to attempt to embed a viewcontroller in a table cell and that just smells very wrong in any case.
You have three independent views that you want to scroll, and that clearly calls for a UIScrollView. As for the best way to organize this, I recommend creating modular UIView subclasses: one for the table, one for the instructions, one for the settings. See my answer on this question as to how you can package up views as reusable (not important in your case) and modular widgets: UIView and initWithFrame and a NIB file. How can i get the NIB file loaded?. Then you can create delegate interfaces for each one, and set your main view controller to implement them in order to communicate with each of the three "widgets."
I am pretty new to IOS but have completed a couple of simple apps.
I have read a number of books, which have helped me getting started, but I am missing som more generel advice on how to best structure an app - especially with regards to UI.
I know this is a very general question, so I will try to put up a specific problem. Suggestions on how to structure this particular app .. or pointers on good reads regarding similar topics would be highly appreciated.
Now the UI of this particular iPad App will look as follows:
The main screen is divided horisontally in two.
Upper two thirds is a sort of canvas / work space
Lower third is a toolbox with various items, which can be dragged to the work space.
The toolbox has different views which holds items in various categories. Lets say: One view with various geometric figures and one wiew with various colors. The user can choose which category to show in the toolbox.
Finally at the top of the screen is a toolbar with a single button.
I am a bit confused as to how to structure my views / ViewControllers. Maybe a lot of my trouble stems from me not fully understanding Apples guideline as to how to use various UI Elements - please feel free to say so if this is the case.
This is how I would start out.
I would construct a main ViewController controlling a main view. The main view would hold the upper toolbar. To this view I would add two subviews. One for the work space and one for the toolbox. The toolbox view confuses me a bit. My idea is making this a tabbed view with one tab for each category of items. However as I understand it, it is bound to cause lots of trouble nesting viewcontrollers which would be the case. Does this imply that using a tabviewcontroller to control only part of the screen is against guidelines? Would it be much better to make up my own 'tabbar' and simply switch between subviews when a tab is tabbed?
Does this also imply, that having a popup view, covering only part of the screen, with a navigationcontroller is equally bad practice? Or would this have to be a modal view? And how about a tableviewcontroller with a view taking up only part of the screen? I fail to see how to accomplish these things without effectively nesting viewcontrollers.
I am sure I got something completely upside down?
Best regards
Thomas
Nesting ViewControllers is not a problem. In fact, View Controller Containment was introduced in iOS 5 to make this even easier. However, it was still possible before the new containment functions.
The easiest way to nest two ViewControllers is the following:
SubViewController *theSubView = [[SubViewController alloc] init];
[self.view addSubview:theSubView.view];
The subview will then be controlled by the SubViewController and will be "nested" in the main ViewController. (This code would be part of the main ViewController.)
To use the new(er) View Controller Containment methods you will make the SubViewController a childViewController of the main ViewController.
There is an excellent video from WWDC 2011 that goes over View Controller Containment. You will need to be a developer to access it here. It is called "Implementing UIViewController Containment."
I would not advise to use the TabBarController in a nested format, it would be easier for you to just build your own view switching method or even use a UIScrollView with pagingEnabled.
As far as popup views with NavigationControllers, this is a common practice. There is nothing wrong with creating a popup with a NavigationController inside of it for doing something like, accessing app settings, or configuring a tool from you palette, or accessing saved projects, whatever you can imagine.
I hope this gets you off to a good start.
More of a "best practice" question with regards to good application design. I have an application that has a number of popover controllers, each with different content. My first instinct was to create a new TableViewController for the content of each popover.
Is this the best way to go about things? I was wondering if it was possible or more tidy to handle the display of all this content within one TableViewController, and present different arrays of content depending on the popover?
Thanks
Unless your delegate/data source code is very similar between all tables I would recommend keeping the classes apart. It will make your code more modifiable in the future if you want to sub-split out one of these views or add additional popovers.