I wanted to know if I have to create a new ViewController for each view I have. Let's say I have 3 views do I need 3 viewControllers or does 1 ViewController can manage all 3 views?
Edit: Views are Objects that I create with .xib file so following the description given me by Xcode 4.3.3: represents a rectangular region in which it draws and receive events.
My situation : What I want is the main View showing 3 buttons, each button leads to a new View. That's about it each of the 3 views will have about the same thing, a tableView to display data parsed from an XML.
Thanks again!
EndEdit
Thanks
Both are possible, depends on your needs. View controllers can easily manage more than one (sub)view (e.g. every UI control subclasses UIView and you can have many in a single view controller). Sometimes it's more convenient to put views in different view controllers, sometimes it's not.
Depends on your situation and what you want to present to the user. If those 3 view controllers have very similar functions and only minor differences, then you could use the same class and have an instance variable to indicate which mode you're in. For instance if you have a list of Songs, Playlists or Videos, those could be the same class, with an enum variable to differentiate between the 3 modes. If your views are significantly different however (like a Song list and a Video player) then you should usually have separate classes for them.
For iOS, general best practice has been for a single view controller to manage a single "screen (or "window", but of course there is only one of these on an iOS device). This view controller may support a variable number of view objects (certainly not a ratio of 1:1 views/view controller).
As of iOS 5, nesting multiple view controllers managing multiple views in single window is now technically supported, but I still consider it a practice best avoided.
One window = one view controller = multiple views.
In one view controller you can manage any number of views.
It is preferable to use a viewcontroller per view. the advantages of the approch is as follows:
Any time you can convert the Template of the application. (eg. from table view to tabview or split view can make quick change)
with each view controller you follow the MVC architecture.
if you have n controller than try to manage n MVC model so that you can shift any model any where easily.
Memory management will be easy (Push and Pop manage memory automatically.)
if we have sigle view controller and n number of view than it will be quite difficult to manage memory.
Also we need to keep the screen ID for each view and need to mantain also their switching.
there are N number of advantages if you use N numbers of viewcontroller over N number of views.
Related
I am using Xcode 6 and Swift.
I have some data that I'd like to represent in two or three different ways using a segmented control.
The first view is a list, the second is a grid, and the third is a table with some labels.
Despite the different appearances, they are all drawing from the same data source.
What is a sensible way to achieve this?
Should I drag 3 views onto 1 controller (the same view controller), and do all of my design/storyboarding within each view, add constraints as needed, and then just show/hide each view accordingly?
Is there a different or better way to do this, or is this about right?
Thanks so much!
Looking at the requirement, i feel TabViewController is best. Using segmented controller you need to take care of switching views yourself. You can have a TabViewController with 3 viewControllers and these view controllers can draw waterer data they need from your data source.
There are two elegant ways to this effectively and clearly.
1)You can use different xib for each 3 views and on runtime load appropriate xib of the different views.This approch should used if you have small and clear views.There is not much work need to handle like dataSource and delgations.The three views will manage by only one view controller.It will make all your views separate and easily managable.You can load diffrent views as
//Your view property
var uiview :UIView?
//load nib from bundle in view
self.uiview = NSBundle.mainBundle().loadNibNamed("myXib", owner: self, options: nil)[0] as? UIView
2)Use container viewcontroller.By doing this you can add the different controllers to your parent controller.This approach is very clean as different views are handled by differnt controllers but it is hard to write.Use this if you have heavy work need to do by each view.See WWDC video to get more help https://developer.apple.com/videos/wwdc/2011/?id=102
I think in your case 1st approach is appropriate use the three different xib and load it on runtime and add as subview of your viewController
I have a problem with my App for iPhone.
Enviroment: I have a TableView, that operates above an MutableArray datasource. An example would be Lap Times for Go cart pilots.
Datasource: I record lap times from both training sessions and from race and qualifying. I consider race + qualifying as one subset of data and training sessions as another subset of data because I think there is big psychological effect and my drivers have slower laps when racing because of fear of crashing into others. At this time I record both data in one array with a variable of Bool "fromRace". So I can filter racing and out of race times.
Human Interface: I created a TabBar that shows racing times in first Tab and training times in second Tab. It feels, like those Tabs contain basically the same view and operate on same data which I just filter using the same view controller since all the methods are the same.
Is it programatically correct to create two separate view controllers and two separate arrays for the datasource basically duplicating the code? Or try somehow to try to discover from which tab I came and alter the data presentation accordingly using just one view controller?
I hope I am clear on what I ask for.
Yes - broadly speaking, a UITabBar is used exclusively to switch between view controllers. That's how it's designed to operate - you load each 'slot' in the tab-bar up with a view controller.
That doesn't mean you have to create two separate view controllers - you could create two instances of the same view controller, and have some flag passed in upon initialisation that would display the data in a different way.
If you just wanted to have a single view controller adapt to display the data in different ways a UIToolBar would be a more appropriate UI element (perhaps with a segmented controller at the bottom).
I have a User Filter section of my iPad app. There is a segmented bar with 5 buttons for 5 types of filters.
Clicking each of the buttons will load up the respective view..
My question is.. would the best way to handle the UI of each filter to have several views in this nib and load/unload accordingly.. or would best practice be to create the information in a scrollable view?
below is the setup..
http://imgur.com/iuufU.png
Thanks in advance...
Generally, go with separate views. The Scrollable view is an approximation of what you're trying to achieve (by the looks of things), whereas the separate-views more closely reflect your aims.
Some typical dvantages:
if you change your UI design, e.g. if one of those filters has to go in a different page, but 4 stay here ... then it's easy to move the whole View without changing the eixsting ones.
you can put each view in a separate NIB file (if they're different), or loaded from a separate ViewController instance (if they're the same), and you get some of the advantages of Apple's automatica memory management of VC's / NIBs.
Usually, people start with the same view for each filter, using a single VC class (instantiated multiple times, once per tab).
Then, as the app evolves, they find that one tab needs a different layout, so they add another VC class, and only need to update the alloc/init line for that one tab.
The View controller programming guide states this regarding view controller's usage:
Each custom view controller object you
create is responsible for managing all
of the views in a single view
hierarchy. In iPhone applications, the
views in a view hierarchy
traditionally cover the entire screen,
but in iPad applications they may
cover only a portion of the screen.
The one-to-one correspondence between
a view controller and the views in its
view hierarchy is the key design
consideration. You should not use
multiple custom view controllers to
manage different portions of the same
view hierarchy. Similarly, you
should not use a single custom view
controller object to manage multiple
screens worth of content.
I understand that if we use multiple custom view controller's to control the parts of a view (i.e. a view controller to manage subViews of a main view which in turn is managed by a view controller) the default methods like:
didReceiveMemoryWarnings
viewWillAppear
viewWillDisappear
viewDidUnload
etc. etc. will not be called.
Apart from this, is there any other solid reason why we should not be using multiple view controllers to manage the respective subviews of a view?
The documentation also provide an alternative solution which reads as:
Note: If you want to divide a view
hierarchy into multiple subareas and
manage each one separately, use
generic controller objects (custom
objects descending from NSObject)
instead of view controller objects to
manage each subarea. Then use a single
view controller object to manage the
generic controller objects.
But there is no mention as to why multiple view controllers should not be preferred. My question is:
Why should not we prefer it this way?
I am concerned because I prefer using UIViewController's subclass to manage my views since I load them from nib each time and I segregate nibs for each view controllers. It becomes easy to cater the changes in later stages of the project. Is this wrong? Should I necessarily change my programming style, or is it ok if I go ahead with this approach?
Thanks,
Raj
Well, I'd say "as long as it works", you can keep on doing like you do !
But to keep things "cleaner", I'd use my own objects.
Since ViewControllers are designed with other general features in mind (like working with navigation controllers and tab bar controllers), which makes it a bit "heavy" for a simple usage, like you do.
Plus, like you mentioned, some events are only called when the viewController's view is added to the main window.
Can't you use your own objects with Interface Builder ? If you create one (or several) UIView IBOutlet(s), it should work the same.
I have an app that does use two UIViewControllers on a single screen. The child is a UITableViewController. I don't rely on any of the UIViewController behavior of the child -- only the UITableViewController methods. This is convenient because there are other cases where the child UITableViewController does manage the whole screen. And in that case, it does use the UIViewController methods. Questionable design? Maybe. It has worked fine for two years now. But I'm not sure I would recommend the pattern.
I am trying to wrap my head around controllers in Cocoa Touch. The main problem is that I would like to have more than one controller “on screen” at once – I want to have a large view (with controller A) composed of smaller views controlled by their own controllers (say B). I’d like to have it this way because the division makes the code much cleaner. What’s bad is that the additional controllers (of type B) are not “first-class citizens” on the screen, for example they do not receive the autorotation queries and notifications. (And cannot easily display modal controllers, they have to send the presentModal… message to their parent controller.)
What is the difference between the A and B controllers from Cocoa viewpoint? Does the system keep some kind of pointer to the “frontmost controller”, a privileged one to which it sends notifications and such stuff? Why don’t the other controllers receive them, even though their views are on the screen? Is having multiple controllers “on screen” considered a hack? Or is it supported and I am just missing some point? Thank you.
More about the problem I am trying to solve: I am writing a simple photo browser. Photos are displayed in full screen, user can swipe left or right to change photos. The A controller takes care of the scrolling part and the B controllers take care of each photo itself.
Isolating B seemed like a good idea, since the photos are loaded from network and there is a lot that can happen, like the network might be down et cetera. In the B controller the code is fairly simple, since B only works with one particular photo. If I moved the code to the A controller, things would get messy.
The only thing I don’t like about the current solution is that I have to manually work around B not being a “first-class” controller. I have to pass some calls manually through A to B and when B wants to display a modal dialog, it has to send the presentModal… to A. Which is ugly.
There is now a first-class support for this scenario since iOS 5, it’s called controller containment.
swift controller containment
objc controller containment.
It's not closely related to the original question but important. Apple clearly states in View Controller Programming Guide that a view controller is responsible for controlling exactly one screen's content:
"Each custom view controller object you create is responsible for managing exactly one screen’s worth of content. The one-to-one correspondence between a view controller and a screen is a very important consideration in the design of your application. You should not use multiple custom view controllers to manage different portions of the same screen. Similarly, you should not use a single custom view controller object to manage multiple screens worth of content.
Note: If you want to divide a single screen into multiple areas and manage each one separately, use generic controller objects (custom objects descending from NSObject) instead of view controller objects to manage each subsection of the screen. Then use a single view controller object to manage the generic controller objects. The view controller coordinates the overall screen interactions but forwards messages as needed to the generic controller objects it manages."
However in iPad Programming Guide they also say that there may be container view controllers:
"A view controller is responsible for a single view. Most of the time, a view controller’s view is expected to fill the entire span of the application window. In some cases, though, a view controller may be embedded inside another view controller (known as a container view controller) and presented along with other content. Navigation and tab bar controllers are examples of container view controllers."
Up to my current knowledge I would not use sub-view controllers in a view controller but try to subclass NSObject and send messages to them from my main view controller.
Also check this thread:
MGSplitViewController discussion
First, and this is important, view controllers don't get "on screen" -- views do. Your "top level" controller can certainly pass along the kinds of messages you're describing to its "sub-view-controllers". In fact, this is how most apps work. Consider an app that has a tab bar, and where the views use navigation controllers. You actually have several view controllers "running" at the same time, each with its own view on screen at once -- your "root" view controller will be an instance (or subclass) of UITabBarController, which then has several nested UINavigationControllers, each which will display nested view controllers (like an instance or a subclass of UITableViewController).
You might want to read up a bit on how responder chains work. Consider a touch event. It will be generated for the view closest to the top of the stack, that can receive events, which is also underneath the tap. If that view can't handle it, it gets passed up the view hierarchy food chain until something deals with it (and then eats it).
As to the specifics of your question, on the whole, I'm not sure exactly what the strategy you describe is really doing to benefit you in terms of complexity. It depends on how exactly you're implementing things, but having separate view controllers for each little subview may require more bookkeeping code than just having one view controller that knows about all its sub-view components.
This is a pretty old question, but since I guess there are people who might face the same problem today I'd like to share my solution.
I was writing this application that had this one screen with a lot of information, pagination, controls etc. Since according to Apple's MVC documentation on the role of ViewControllers, you should not implement the logic in view itself, or access the data model directly from it, I had to choose between having a Massive ViewController with a few thousand lines of code which was both hard to maintain and debug(even with unit tests) or find a new way.
My solution was to use UIContainerView like below:
this way, you can implement each part's logic in it's own ViewController, and the parent view controller takes care of constraints and sizing of the views.
Note: This answer is just a guide to show the way, you can find a good and detailed explanation on how it works and how to implement it HERE
Actually you can make it work earlier than iOS 5, since most of us are targeting 4.x and 5.x at the same time. I've created a solution that works in both, and it works great, few apps in appstore use it :) Read my article about this or just download and use a simple class that I've created for this purpose.