So here is the problem I am trying to solve.
In each viewController I am trying to insert ads and the actual control elements. I finished couple of tutorial on raywenderlinch.com to understand that how people professionally put ads in their app. They used UIViews to have two views under mainview of view controller. So I completely understood that one subview hold the ads and another is holding actual app contents. if Ad is loaded take up the screen or else let other view have all available area.
After I came back to xcode I started coding the way I learned there. but when I was dropping UIView on storyboard, I saw containerView, which I think was not present when the tutorial was written.
So I am here to ask about the both approach and their pros and cons.
So basically its UIView vs ContainerView. Which way I should do, and why ?
Any help would be greatly appreciated.
You use UIView when you already have a view and you do not need to have a dedicated view controller to build and handle interactions within it.
From the UIView help page:
UIView object claims a rectangular region of its enclosing superview (its parent in the view hierarchy) and is responsible for all drawing in that region ...
Simplified structure:
YourViewController ---(has)---> UIView
You use UIContainerView when you need to embed another view controller in the one that you already have. The embedded view controller is in charge of returning a view for the region that the UIViewContainer occupies. Therefore, your UIContainerView knows which view controller to use to render UIView inside the region it occupies.
From the UIContainerView help page:
Container View defines a region within a view controller's view subgraph that can include a child view controller.
Simplified structure:
YourViewController ---(has)---> SubViewController ---(has)---> UIView
That SubViewController returns a view and handles its events.
As an alternative answer, you can also consider the use case instead of the technical differences. For example: Why use a container view?
A common use for container views is to reuse (share) a view, directly in the storyboard. Previously, reusing a view required creating a separate "xib" file, and programmatically adding that view when the view controller was loaded.
The above image is from this extremely simple, easy to follow guide that walks you through how to setup a container view that is shared between 2+ view controllers.
A few other thoughts on when to use it:
A navigation bar is part of a UINavigationController, which is a container view controller. So, if you wanted to build a custom alternative, you'd probably use a container view.
A container might help anytime that you want to temporarily show a complex view on top of your current VC but can't/don't want to present another VC modally. This approach still allows you to build that temporary view in interface builder, to setup auto layout constraints for it, etc
I also found a guide explaining that there's a way to switch out different container views based on the situation, allowing your VC to have sub-sections which are very dynamic, yet without having to build those sub-sections programmatically. A picture, from that guide, exhibiting what I'm referring to:
Hopefully this helps people who are trying to figure out when a container view applies to them. If you have other example use cases, please edit/add them or leave them in the comments!
If you see in detail these container view of UIView class type. To get the insights of why we need containerView you should see below portion
In most ways, a container view controller is just like a content view controller. It manages views and content, coordinates with other objects in your app, and responds to events in the responder chain. Before designing a container controller, you should already be familiar with designing content view controllers. The design questions in “Creating Custom Content View Controllers” also apply when creating containers.
for more detail about container view goto link
But before you begin you should have an understanding of
and also you can check this tutorial for how to use container view.
Thus you can go for both the approaches.
Hope this will help you. happy coding :)
Related
I have a container view inside of a view controller and I want to switch the view controller in the container view when a button is pressed in the main view. Any suggestions? Also if it is possible I would prefer swift if you give any examples.
Thanks
If you have not started your work yet I would suggest using UITabViewController in place of container view in UIViewController. Using UITabViewController has one advantage over using container view that you dont have to manage Child View Controller your UITabViewController manages it all. As apple documentation says UITabBarController is a specialized view controller that manages a radio-style selection interface.
But if you have already started working on container view, you may want it working.I too learned regarding container view from the same link which #iOSGeek has shared. Every things is clearly explained. You can follow the same link and you are good to go.
Hope it helps. Happy Coding!!
(I have read other questions and answers on this topic, but most are very old and do not relate to iOS 9 or 10.)
The app design calls for the top half of the display to always contain the same content. (An image being edited by the user.)
The bottom half of the display needs a UITableView. When a UITableViewCell is tapped, the bottom section needs to transition to a new UIViewController with slide-on animation, similar to how UINavigationController push segues work.
Problem: only the bottom view needs to transition to the new view controller(s), and back again. The upper half of the view hierarchy needs to remain unaffected. For this reason, I can't place everything inside a UINavigationController, and I can't have a UINavigationBar at the top of the screen.
Question: what approach should I take in such a situation, where I need only one UIView hierarchy to transition in push-segue fashion, but not anything else? Thanks.
Edited with Solution
Solution follows, for those following along at home.
Yes, you can actually use a UINavigationController for the bottom half.
If you are using Storyboards, the easiest way to do this is to use a container view for each part of the screen which you then can embed a UIViewController in for the top part and a UINavigationController in for the bottom part. If you are doing this programmatically, just add the view controllers as child view controllers to your app's initial view controller (see this answer for more info) which is essentially what the Storyboard will do for you automatically when using a container view.
As a child view controller, the UINavigationController will act independently from the top UIViewController and should behave as expected.
I recommend the programatic approach for the following reasons:
It helps you understand the inner workings of child/parent view controllers much better which will likely save you a significant amount of debugging time down the line.
It makes adding/removing/swapping child view controllers as simple as a few lines of code. Trying to do this with Storyboards is notoriously hacky and cumbersome.
It's much easier to keep track of changes using GIT (most mid-size/larger companies actually prohibit Storyboards for this very reason)
If you want change in part of the screen you can use container view. For details refer Swift - How to link two view controllers into one container view and switch between them using segmented control?
You can use multiple view in one view controller and can give animation like push or pop to show or hide it.
Second approach is you can use Container View which will give exact effect like navigation stack.
I'm currently building a custom view controller container for my iOS project and I nearly understand what I'm doing. The one thing I'm stuck on is how do you (properly - aka not a hack) add a view controller in PART of the Parent controller's frame. See how there are multiple view controllers/views in the email app? How does one build a custom controller container that designates the location of such sub-view controllers? How do you properly add such a controller? I'd like to know the "correct" way as designated by apple (best practice).
EDIT: After looking at this some more I was thinking a possible way would be to create views with custom sizing and then push those to the parent. Is this the correct way?
You sort of answered it yourself. The view you have as an example uses a UISplitViewController to show two separate views (left and right). Each of those views has a view controller that owns it. Note that the left side includes all of the view, like the search, nav bar, and toolbar. So just create two separate view controllers and add them to a UISplitViewController and you should be golden! The views themselves are created however you normally create views. Storyboards, NIBs, or in code works.
I am exploring the design options for an iPAD application with multiple views on the different part of the main screen. I am going to have different ViewController for each of the view. UI is quite different from what any of the available view controllers (UISplitViewController, UINavigationController etc.) provide. I have been reading about the container extension api of UIViewController (especially addChildViewController):
http://developer.apple.com/library/ios/#DOCUMENTATION/UIKit/Reference/UIViewController_Class/Reference/Reference.html
(Look for "Implementing a Container View Controller")
However, it seems to me that this functionality is mainly designed for applications with UI that transition from one view to another (transitionFromViewController...). In my case, all of the views are visible at the same time. However, they do interact with each other. So my questions:
Am I missing something w.r.t. container extension of View Controller? I will still probably end up using this just to keep the list of child view controllers but don't see much value.
Can you recommend any other api/pattern that I should be using?
Thank you.
You can easy access to childViewController.
self.childViewControllers will return an array with all childs.
I asked similar question couple days ago: Maybe this will help you:
Get container VC instead of view
Take a look at http://developer.apple.com/library/ios/#featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html.
Add your various view controllers to self.childViewControllers and add the views of the child controllers as subviews of self.view.
When using custom container view controller, I don't quite understand why the presenting view controller needs to specify the from, because being the container class, it should already know what's in the view hierarchy, no?
transitionFromViewController:toViewController:duration:options:animations:completion:
Container view controllers sometimes need to put the views of the contained controllers into specific subviews of their own view. (For example, a SplitViewController reimplementation might have left and right positioning views holding the master and detail controller views respectively.) Providing the fromViewController tells UIViewController where in the view hierarchy the new controller's view should be inserted, and also which specific view should be removed after the animation.
(contrary to another answer, the frames of the views aren't set for you at all. You do that, before the call, and in the animation block. The "Creating Custom Container View Controllers" system guide in the docs has a pretty good example.)
As it happens, actually using transitionFromViewController:... appears to be optional. You can manage your view hierarchy manually, with or without animations, and it works fine. I'm still forming my opinions, but I think I prefer to do it manually, to more easily handle cases where one of the VCs is nil.
This is done this way to allow you to have a view controller that has views with viewControllers in it. The from defines the originating view controller and gives the system the ability to position the animations appropriately.
Imaging you had a view with 4 views in it like tiles. the main view controller can consecutively call this on its "child" view controllers and with the from -> to specification, it won't make the assumption that the caller is the from viewController.