I am a newbie, and I am wondering what a ViewController is. I've tried to look at the description, but I find it too complicated. I'm working on Xcode 3 and am trying to link two pages together.
Since you tagged this question with xcode3.2 i'll assume you're asking about UIViewController.
It's one of the UIKit Framework classes.
One of its most important properties is its view (which is an instance of UIView) that usually holds one or more subviews.
What differentiates it from simple UIView are its methods for memory management, handling appearance, implementation in UINavigationController hierarchy...
The dull information on UIViewController can be found here: UIViewController Class Reference
You're definetly want to take a look at View Controller Programming Guide for iOS and View Controller Catalog for iOS.
Related
I've been digging online and in Apple's docs, but I can't seem to identify what iOS version is required to use UIContainerView. I'm a little frustrated that this tidbit of information is eluding me...
UIContainerView does not exist as a class.
According to the about page of the uicontainerview tag in StackOverflow:
There is no UIContainerView class, but there is a pattern that uses a UIViewController as a container for one or more ViewControllers. This pattern is also in the Xcode object library with the name Container View.
See, for example, the answers to this question:
There is no such class called UIContainerView. You need to create an outlet of UIView and connect that to your container view.
It is confusing because IB lablels it as UIContainerView, but it's type is really just a UIView.
I was left with continuing the code of a senior developer, where I came across a coding pattern that was not only bizarre, but got me curious about a lot of things. The pattern, however, that I spoke about had something like this:
There is a UIViewController the view of which has an instance of extended UIView attached to it as a subview.
This custom UIView class has a reference of the above-stated UIViewController.
There are a series of methods defined within the UIViewController that are responsible for handling events at the UIView.
Since this UIViewController exists as a reference, our custom view calls those event-handling methods through this reference!
In such a system of code, what are the memory implications? How is this any different from the delegate pattern? Under what circumstances using this sort of coding okay?
While this pattern is a little curious, I would hesitate to condemn this without more information about what this child view is doing and what it needs to inform the view controller about. There is, admittedly, a faint code smell here, and if I were to hazard a guess, I'd bet that this view is likely doing stuff that one would now generally put in a view controller.
Often, when adding a subview that has any significant complexity (or is likely to be reused in different views), one would consider an iOS 5 feature, "view controller containment" (see the Creating Custom Container View Controllers section of the View Controller Programming Guide or WWDC 2011 video Implementing UIViewController Containment).
If using storyboards, you can achieve much of this using the special "Container View" control introduced with iOS 6, found in Interface Builder's "Object Library" (in the bottom of the right panel in the standard Xcode layout). If doing this programmatically, just make sure to call the appropriate methods listed in the "Managing Child View Controllers in a Custom Container" section of the UIViewController Class Reference.
When using view controller containment, you have a parent view controller (the main view controller) and the child view controller (the view controller that is managing the subview). And in this scenario, it's very common to design a custom protocol by which a child view controller notifies its parent view controller of particular events. But rather than adding your own custom delegate property, you can use the built-in parentViewController property which is automatically populated when you adopt the above "view controller containment" pattern.
Having said all of this, I might let practical concerns drive whether the existing code base needs to be refactored or not. Perhaps the code predates iOS 5, but is a solid implementation of what we might have done back in the day. Bottom line, if it works, is otherwise well written, and has the delineation of responsibilities clearly defined, you might decide to just leave well enough alone. And if it's a little ambiguous (as the absence of a discussion of a protocol might suggest), perhaps just start by introducing a formal protocol between the child view and the view controller to make the interface explicit. Whether a more radical refactoring of the code (to use something like view controller containment) is called for is hard for us to advise on the basis of the limited information provided thus far.
I have a view that contains a mapview and a tableview, similar to how to the facebook nearby places screen looks in the facebook app looks.
I put the screen together using interface builder. I have outlets to the tableview and map. And, I set the UIViewController that controls the main view to be the delegate for both the mapview and table view. Everything works perfectly.
However, this main UIViewController is now pretty messy because it has to respond to methods on behalf of it's own view, the mkmapview and the uitableview. However, data is somewhat shared between the map and the table view.
I am wondering if this is where UIViewController containment comes in? Or, if I should should just make custom objects to act as delegates for those two views. I am looking for the correct design pattern to use in modern iOS. A few years ago just mashing it all into the same controller would be the way to go. Maybe it still is the way to go.
Both your ideas are good thoughts, but...
Controller containment is typically used for more navigation related purposes, like a UINavigationController.
Custom objects that do some of the delegate/datasource work, that's a good thought too, but a little clumsy to the extent that they share data with the view controller and each other. This might be a good solution especially if other view controllers will need the same delegate/datasource behavior.
A third alternative, and probably the best of the three, is to create class extensions of the view controller (see apple doc here). These can be thought of as parts of your class in different files.
I have a UIViewController having two parts:
a UIView
a bar having multiple drop down menus arranged horizontally and having thumbnail images at the top
Because second part is little complex I've decided it to be a UIViewController but now I have some concerns:
Because I have drop down menu, menu will exceeds the bounds of the bar. How can I handle it?
Is it a good way to have a UIViewController inside a UIViewController?
How can I implement a drop down menu? As far I know IOS doesn't have drop down menus.
To use a controller within another controller, you employ a custom container view controller.
See Creating Custom Container View Controllers section of the View Controller Programming Guide for iOS.
Also see the appropriate Implementing a Container Controller section of the UIViewController Class Reference.
Also refer to the WWDC 2011 video, Implementing UIViewController Containment
In iOS 6, you can set up storyboards with container views that automatically employ embed segues, saving you from needing to explicitly call addChildViewController and the like, if you're using storyboards. Check out the "container view" object in Interface Builder. If you're going to be changing the child controller, you'll have to employ the API referred to in the above links, but for the configuration of the first child, you can set that up in Interface Builder in iOS 6.
In this case, setting up a controller containment could be the right way. The only limitation is that it works for iOS 5 and greater.
Here, what you have to do:
// add as child VC
[self addChildViewController:_barViewController];
// add it to container view, calls willMoveToParentViewController for us
[_containerView addSubview:_barViewController.view];
// notify it that move is done
[_barViewController didMoveToParentViewController:self];
Here, you can find additional info Containing ViewControllers. Obviosly Apple doc is your friend. In addition, if you search for "uiviewcontroller containment" you can find a lot of tuts out there.
If your app needs to target devices where iOS 5 is not the minimum, you should rely on a UIViewController and two different views.
About drop down menus, in my opinion they don't work so well with touch interfaces. There are some alternatives, for example an instance of the UISegmentedControl class. Here you can read Apple UI design guidelines about segmented controls: http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/UIElementGuidelines/UIElementGuidelines.html#//apple_ref/doc/uid/TP40006556-CH13-SW1. If you explain a little bit more about your desired UI functionality we could offer you a better alternative from the user experience point of view.
If you insist with drop down menus, there are some third party control libraries available out there; for example: http://www.cocoacontrols.com/
I am building an app with many views and subviews.
I am trying to figure out how to approach creation of the subclass.
one simple example:
I have a table view with heads view and footer view. (I have much more complex views then this one, but I am trying to explain my point with a simple one).
In the beginning I didn't want to create views subclasses for every view, but I found that my code is getting complex and hard to navigate in.
Then I found my self creating a view for every subview in the main view. The truth is that I like it better cause my code is clearer to me. Th only thing is that I don't know what are to cons and pros of each approach.
How do you decide when to create a custom view or create it's code in the main view?
Thanks
I usually create a UIView subclass only when there is specific functionality that would be best done in such a class. This might be that the view is a control such as a keyboard to enter a value or a UITableViewCell subclass.
Otherwise I would generally not subclass UIView but just create the view hierarchy in Interface Builder or in code and then use the UIViewController subclass to do all the business logic.
Basically, in general with iOS programming, you want to have all the logic of how a "view" (or screen, or whatever you want to call it) in a UIViewController subclass. It's hard though to really give good advice without fully understanding your hierarchy.