UIView vs Container View

Question

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.

massive explanation! -> http://stackoverflow.com/a/23403979/294884 — Fattie, Dec 12 '16 at 20:51
@JoeBlow - Nice example of beginning a scene, *but* I don't see how that link answers the question of why/when to use a UIContainerView. IMHO, that top level "container view" could just as well be a regular "view". As the accepted answer below explains, "you use UIContainerView when you need to embed *another view controller*". So unless your scene needs multiple view **controllers**, UIContainerView is not necessary. — ToolmakerSteve, Mar 09 '17 at 23:56
@ToolmakerSteve - that's precisely correct. container views give you "another view controller". And in practice other than in Hello, World apps ......... you always need "another view controller". Indeed. — Fattie, Feb 01 '20 at 00:05
@Fattie - But you don't need a view controller for *every* view that you add - the question is when to add a container view, vs. when to merely add a view. My point was: that link doesn't add any information that helps in *deciding between those two*. I was merely pointing that out, as it is a lot of info to read. — ToolmakerSteve, Feb 01 '20 at 18:45

score 29 · Answer 1 · edited Aug 16 '17 at 12:06

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.

score 9 · Answer 2 · edited Mar 10 '17 at 00:29

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!

score 1 · Answer 3 · answered Jul 21 '14 at 08:18

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 :)

Does not answer the question. The question is about why use a container view instead of a regular UIView, given that *any* view is capable of containing other views. To be useful, need to clarify what a container view can do, that a regular view cannot do. (But it does contain links that might be useful to someone, so I did not downvote, even though it doesn't answer the question.) — ToolmakerSteve, Mar 10 '17 at 00:02

UIView vs Container View

3 Answers3

Linked