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
I plan to develop an check list app that consists of multiple pages. Each page is going to display a list of simple Yes/No questions and a "Next" button at the bottom of the page.
In terms of the app design I see two options
One UIViewController with a stack of full page UIViews (layered, z-index). Switching from page 1 to 2 I'll use sendSubviewToBack
One UIViewController per page. Switching from page 1 to 2 I'll present the new ViewController.
Questions: What are are the PROS and CONS of these two approaches. Any other option that I've overseen? What are your experiences, suggestions?
Apple chose the one view controller per page approach in it's implementation of the same idea. That may be in part to maximize generality -- different users of UIPageViewController will obviously have different needs. But another consideration is memory; if you have a few dozen pages in the multiple subviews approach, you'll have a few dozen full-page subviews, and that's a quick way to use far more memory than you actually need at any given time.
If you do go with a single view controller and multiple subviews, consider instantiating the subviews only as you need them, and removing the ones that you don't need from the view hierarchy. Indeed, since it sounds like all your pages use the same format (checklist), it's hard to see why you'd ever need more than a single view for the pages. When the user selects a different page, you'd simply give the view a new set of data to draw.
Assuming you know how to write good code (reusing views / view controllers), they should have the same pros and same cons.
One pro in favour of the UIViewController approach is that it will most likely result in cleaner code. You also have the view lifecycle events like viewDidLoad, viewWillAppear, viewDidAppear, etc. which give you clearer view of what's happening.
I think it depends of what you are going to do on your views. If both have the same behavior with the datas, I would use just one UIViewController. If you have to make more and different treatments, I would use two UIViewController.
Using two also make easier a beautiful transition (handle by iOS) between them. If you use one, maybe you should use a UIScrollView and add the two views inside and scroll programmatically.
And another way to do that is to use a UITableView to show directly all the datas in one view.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I need to implement a screen that lists the data I receive from an API. There is a mode navigation bar button which changes how the data is displayed in the same screen (same view controller)
Added a gif at the end to make it easy to visualize. The concept I have is quite similar, but transition animation is not needed.
The task itself is pretty trivial, but I can't decide what's the best way to handle this "mode switch". I came up with below options.
Option 1: Having 2 different view controllers for each mode. ContainerVC holds a state, and changes childVC when mode is switched. I think this is the best approach when the data is different - such as in segmented control. Since the data used in both child view controllers are same in my case, it may be problematic to manage this.
Option 2: We have 2 different views for each mode (for example tableView - mapView) and we add/remove these subviews based on selected mode in same view controller. With this approach, my view controller can easily be massive and impossible to maintain in a heartbeat
Option 3: Similar to option 2, but instead of add/remove we show/hide one of the views.
I am not sure if there are other approaches that provides a cleaner way to solve this problem, and I'd be happy to read resources/documentation to read you share
If only the position of the views changes you could just update the constraints. If the views are totally different depending on the mode, I would definitely use a container view controller instead of hiding / showing the views for performance reasons. You can store the two view controllers (each of which manages a view for a single mode) in a container property, when the mode changes the container toggles the visible clild (removes the current child and its view, then places the other view controller in the hierarchy). I suggest you to store the data only in the container, then you can pass a container reference to the children (maybe during initialization), so children can access the same model data through the container, this avoids repetition or conflict.
Otherwise you could also use a single view controller with a method that is called when the mode changes. In that method you can simply remove the current views (not just hide them) and insert the others.
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 5 years ago.
Improve this question
I'm building a few information screens and they have different layout/design (ie. can't be generalised), since they are all information screens I've put them in one storyboard, however they are not connected by any segue, it's just based on response I show different information screens.
I'm a bit uncertain that if it's a good practice to do this? I can't think of another way for doing this which is better, separated XIBs? different storyboards? Or a single screen with dynamically updated layout/content based on design (this sounds like a bad idea)?
The only downside I can think of, is that the storyboard won't have a initial screen, which feels a bit against the purpose of storyboard - you are telling a "story" by screens in a navigation flow.
Am I thinking correctly, is there a better way to do this?
Thanks!
Here are two good reasons not to put independent scenes in a single storyboard:
A larger storyboard takes longer to load and save.
If this is a multi-person project, you’re more likely to run into merge conflicts.
Here’s one good reason to put independent scenes in a single storyboard:
You will often need to modify several of the scenes at once.
Usually it’s simpler and lighter-weight to use individual XIBs unless you actually need storyboard-specific features like segues.
One advantage of adding the screens in a storyboard is, you can connect them via storyboard references.
It is not always necessary for a story board to have an initial controller.
Actually it is more of a personal choice to choose story board vs xib in your scenario.
Let's just stipulate, shall we, that having multiple screens but not representing them through multiple view controllers and their views is just dumb. View controllers exist for a reason; use them. So your choices for making a view controller's view are:
Create the interface entirely in code
Use a xib file
Use a storyboard
You are asking to choose between the last two. But as far as you are concerned, there is nothing to choose between, because:
A xib file is a way of generating a nib. So many xib files give you many nibs.
A storyboard is a collection of nibs (i.e. it's multiple nibs in one) — with the added feature that you can include segues.
If you don't use segues, a storyboard is many nibs and that's all it is — just like having many xib files. So if you are not going to use segues between view controllers in your storyboard, then there is no advantage or disadvantage one way or the other: it just depends on your personal style.
Personally I think the storyboard interface is a pain to use, plus if you want to instantiate a view controller from a storyboard without using a segue, you have to give it an identifier and cast to the view controller class, whereas if you instantiate a view controller with an eponymous xib, you instantiate it by class and it loads its view automatically, which is far neater.
So I'd lean towards using separate xib files, but it's a matter of opinion / taste, and de gustibus non disputandum.
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 7 years ago.
Improve this question
I've been building iOS apps for a few years now. While I'm usually using a Navigation Controller to manage my View Controllers, I'm wandering what would be the impacts of someone building an iOS app using only one UIViewController to manage all it's views. That way, the developer would navigate between it's views by assigning a new view to the only UIViewController.
Let's say that developer is not planning to use Storyboard and that he doesn't mind build Views programmatically.
Is there an advantage to build an app this way? What are the downsides?
Let's be clear, I am not planning to build an app this way. I'm only wandering what would be the impacts from a theoretical aspect.
Is there an advantage to build an app this way? What are the downsides?
There's absolutely nothing wrong with making views come and go nimbly within a single view controller. I do it all the time and so do you, probably.
But now let's consider an extreme case along with the problem of where to put functionality. Let's say I have 10 different views with 10 different sets of subview functionality (buttons that do things, and so forth), all replacing one another in the interface. It's easy to imagine that one view controller governing all of these might get a little top-heavy with code. If each view has its own view controller, on the other hand, each view's controller functionality is in a separate view controller. This will likely make for more maintainable code in the long run.
The navigation controller architecture is a case in point. It separates the code that performs the transition between views (the navigation controller, which moves views in and out and deals with the Back button and so forth) from the code that implements the functionality of those views (the child view controllers that are pushed and popped on the navigation controller's stack). That's pretty darned clean and elegant, and is something you should probably want to use or emulate, not abandon.
Apple chose the one view controller per page approach in it's https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIPageViewControllerClassReferenceClassRef/index.html. That may be in part to maximize generality -- different users of UIPageViewController will obviously have different needs. But another consideration is memory; if you have a few dozen pages in the multiple subviews approach, you'll have a few dozen full-page subviews, and that's a quick way to use far more memory than you actually need at any given time.
If you do go with a single view controller and multiple subviews, consider instantiating the subviews only as you need them, and removing the ones that you don't need from the view hierarchy. Indeed, since it sounds like all your pages use the same format (checklist), it's hard to see why you'd ever need more than a single view for the pages. When the user selects a different page, you'd simply give the view a new set of data to draw.
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 7 years ago.
Improve this question
I writing an app that has many table views and depending on a number of factors those table views might show some sections and hide others.
I have, for instance, "active" objects and "archived" objects. When a user selects one he is taken to a same table view, but if the object is active some sections are shown and if it's archived other sections are shown. Now I'm thinking of adding other properties to those objects, like "finished", besides "active" and "archived". The thing is that the code for that table view controller is getting more and more complicated trying to figure out which sections to show or to hide depending on each property of the selected object. So I'm thinking of using different table views, one for archived objects, another for active objects, another for finished objects. But although they have many different sections there are also some sections in common that should be shown for all those objects.
So what should I do in a situation like this? Should I use three different table views with three different view controllers, one for each property of my objects (and I might even add more!), and repeat the same code many times for the sections that are common between them, or should I keep using one view controller and make its code more and more complicated trying to determine what sections to show or to hide? Or should I do something in between? Or something else entirely?
Thanks in advance,
Daniel
Edit: I didn't think this was a matter of opinion, but apparently it is. There must be some objective things to consider, though. What's the impact of having many unnecessary scenes in a storyboard, for instance? Is it so negligible that it would be ok to create a new scene for every little change instead of doing things programmatically in the same view controller?
In my opinion, you should have 3 separate view controllers.
While you develop and refine your app, you will definitely notice you have repeated code in a lot of places. When you notice that repeated code, try and abstract it into your Model layer and out of your View / Controller layer.
If you ever get to a point where your 3 controllers end up being almost identical, then you can combine them.
There isn't a definitive right or wrong answer to this; its a problem that you will learn to recognize and solve with experience.
Good luck with your app! :-)
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 9 years ago.
Improve this question
For example, if I required a UITableView to appear beneath additional content in a view, would it be best practice to either:
add a UITableView as a subview, or
add a container view holding a UITableViewController?
As far as I know, both would provide the same user experience, however I am interested to know which method would be considered best practice?
You have several options:
Add a UITableView and make the containing view controller the table view's data source and delegate.
Add a UITableView and make some other class the table view's data source and delegate.
Create a separate view controller with the table and then add the 2nd view controller as a child view controller of 1st.
The choice depends on the appropriate division of responsibility and encapsulation.
Options 2 & 3 allow for reuse if you ever need to embed the table view in more than one view controller.
There is no simple answer to your question. It all depends on your needs, your data, and your app's structure.
The general rule for iOS, especially for the iPhone/iPod touch form factor, is that you should have only one view controller on the screen at any given time. The only case I can think of when you would want to violate that guideline is when you have a subview that has a lot of logic built in to it, and the subview needs to be included in multiple other views. For example, a popover should have its own view controller because it might need to be shown in conjunction with multiple other view controllers.
In your case, I would strongly suggest just adding the UITableView as a subview unless (1) the table view has a lot of logic that isn’t related to that of the parent view controller, or (2) you will need to display the same table view in another part of your app.
I would rather use a container view controller for the following reasons:
It can be reused in another part of the application.
Maintains single-responsibility of the objects (Main view controller focuses on displaying information about the model, and the table view controller handles displaying information about a relationship in the model, for example).
Keeps source files smaller and easier to read.
Easier to build tests for.
Ultimately though, they are both valid solutions.