Ive been tearing my hair out over the last couple of days trying to understand this one seemingly basic concept of iOS development:
If I want to have two or more View Controllers displayed and usable in the same "screenful", is this:
Let me rephrase a bit:
If I wanted to have, in an iPad app, a UIView
(A) that takes up a large portion of the left side of the screen, and a second UIView
(B) that takes up the rest of the right side of the screen, and I wanted to add a button to UIView
B that when clicked would use the Modal transition to slide up a UITableview
to replace UIView B, and this UITableview
would then act like a typical UITableviewController
whereby when the user picks an item from the table, the typical events are sent to the tableview controller to push in a new set of items, is this possible?
It just seems to me that if Im already able to easily create two separate UIViewControllers, and have a button in one VC modally bring up the second VC, why cant I combine this functionality so that one VC has two children VCs, and those children VCs handle their own modal transitions.
Or is the best practice in a case like this to simply have one VC that handles everything, and then manually handle animating the slides in / out of various views after various clicks on various UI elements?
As you can tell, I think Ive read too many different, conflicting responses to questions similar to this that Ive gotten entirely confused about whats what anymore. If anyone out there understands what Im getting at and can lend a helping explanation or some pointers Id greatly appreciate it.
In iOS Development, a View Controller is responsible for displaying the data of our iOS application on the screen. It acts as an interface between its Views (created by the developer) and the application data. Each ViewController in the Storyboard is assigned a Class that inherits the UIViewController class.
Views are for display, model objects are for data, controllers are the glue in between them.
Overview. You use view controllers to manage your UIKit app's interface. A view controller manages a single root view, which may itself contain any number of subviews. User interactions with that view hierarchy are handled by your view controller, which coordinates with other objects of your app as needed.
The answer depends on whether you need to support iOS 4 or not. If yes, the answer is:
Answer number 1 - With the exception of Apple's own container controllers, notably UITabBarController, UINavigationController, UISplitViewController, UIPageViewController and UIPopoverController (did I miss any?) there is no properly supported way to have multiple view controllers active on the same screen, managing different portions of the view. View controller methods such as presentModalViewController, etc all work on the assumption that there is a single "frontmost" view controller that owns the whole screen, and if you try to have multiple view controllers manage different parts of the view, all kinds of things will break, such as forwarding of screen rotation events and resizing/positioning of views after a page transition.
However if you only need to support iOS 5, the answer is:
Answer number 2 - No problem! Just make sure that all your sub-page-view controllers are correctly hooked up to a master view controller that manages the whole page. That means that in addition to the controllers' views being subviews of a common parent view, the controllers themselves should be child-controllers of a common parent controller. As long as the controller's parentViewController properties are all set correctly, you should be able to manage this kind of composite interface without too much hassle.
Unfortunately, Apple only added public setters for childViewControllers and parentViewControllers in iOS5. In iOS4 and earlier you're limited to Apple's own container controller arrangements and cannot create your own (at least, not without event forwarding issues).
So assuming you need to support iOS4 for now, answer number 3 seems like your best bet: Build your interface using multiple views but a single controller. This isn't too bad though. You can create custom view subclasses that manage heir own subviews (for example there's no rule that says a tableViewDataSource or delegate has to be a UIViewController subclass, or that a button IBAction has to be a method on a view controller instead of another view).
You'll actually find that most of the functionality you normally build into a view controller can be built into a "smart" container view instead, allowing you to split your screen into multiple standalone "controller-views" that manage their own contents.
The only bit that's tricky is doing stuff like transitions between one view and the next. For this you won't be able to use the standard presentModalViewController or pushViewController methods, you'll have to do the animations yourself using CATransitions or UIView animations.
This is definitively possible in IOS 4 :
You have a view controller "A" with its view :
On IOS5 just use the method on your view controller "A" :
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With