I am little bit confused for unusual view hierachy present for UIWIndow.
If any one refer to apple UIKit Reference for UIWindow then UIView is the super class for UIWindow
NSObject->UIResponder->UIView->UIWindow.
But when one create a new project in XCode, there is a single MainWindows.xib and it contains the rest of views in the project.That means UIWindow is the super class for UIView.So UIWindow is child as well as Parent of UIView.Thats very confusing for any one.
So can any one have the clear idea related to this.
Don't confuse inheritance hierarchies with view hierarchies.
A UIView instance can have many subviews of type UIView so a UIWindow is a UIView and so it can contain other UIViews as subviews.
Look at all the other UI components like UIButton or a UILabel they are all inheriting from UIView, so you are able to add them to your view as subview.
Related
I have a reusable UIView with its own .xib file. This UIView would be added to different UIViewControllers as subviews. In the MVC design pattern, my reusable UIView should contain only code for the user interface(UILabels, UIButons, etc..). What I'm confused about is setting up the UILabels and UIButtons. Is the ViewController that contains my UIView responsible for setting up my UIView's UIButton click events and what my UILabel displays? The problem I'm having now is that I have multiple UIViewControllers that reuse the same UIView, but they all implement the same code that sets up my UIView. This end up with lots of duplicate code across my UIViewControllers. If I move the setup code to my UIView to reduce the duplicate code, doesn't that violate the MVC design pattern? Is there a way to create a "Controller" thats only responsible for setting up my UIView so I could reuse my UIView and Controller inside my UIViewControllers?
Assuming that by setup you mean instructing the UIView on how to draw itself based on some object, this is exactly what the drawRect method is for. UIView also provides an initWithFrame method and you can even create your own initializer if you want. One more option is to create a function in your UIView subclass that will take what ever info you are displaying and will setup the view way you want. Something like: setupCustomViewWithMyObject(object).
All this to say that your setup code should be in your UIView subclass and you are not violating anything.
I have a multi-viewcontroller app.
The main view of the main VC is subclassed so I can use Core Graphics animations. It's called "animations" class.
On the storyboard, I add a UIView called "MainArea" as a subview of the "animations". I have a VC called "MainAreaVC". As you know it has a property of "view". How can I make the "MainArea" subview the default UIView of my "MainAreaVC"?
The other option is to just make the "MainArea" view a property of my "MainAreaVC" and use this. I just don't want the "MainAreaVC"'s default "view" property just hanging out doing nothing.
The view in a UIViewController is the bottom view: it is always the one at the root of the tree hierarchy, and appears behind everything else, possibly clipping subviews.
You can change the view Class, but no matter what you do, by design it must be at the root. If, somehow, you managed to point to one of your subviews, that subview would in essence become the root.
Comment:
You do not have to add a view of type animations containing another view of type mainArea. You can have 'MainAreainherit fromanimations, and drag suchMainArea` in the storyboard.
In a storyboard, I'd like to describe a UICollectionViewController that has a plain UIView as its root view (the view parameter). The root view will be a container holding the UICollectionView as a child, with another UIView in front of it.
(I want to place my own UIGestureRecognisers in front of the UIColellectionView's to pick up pans and pinches. I'll disable the UIColellectionView's "User Interaction").
The storyboard editor doesn't seem to want me to do this if I drag a UICollectionViewController from the "Object Library". Can it be done? Would I be better off subclassing from UIViewController instead of UICollectionViewController?
The very short answer to the questions: Yes, it must. UICollectionViewController requires it's [self view] to be the UICollectionView instance.
Instead of doing this, have a top level UIViewController owning the UICollectionViewController as a child. This suitably separates the code / logic / ownership of each of the views and correctly allocates controllers for each section of your 'view'.
If you are setting up from code, use UIViewController as the owner of the top level view and use addChildViewController: to handle the nested collection view controller.
If you are setting up from a storyboard, have a UIViewController scene that has a view hierarchy of your choosing but includes a "Container View" object from the storyboard editor's "Object Library" somewhere in it. Have the UICollectionViewController in a separate scene. Point the "Container View" you added at the UICollectionViewController's scene in the storyboard.
UICollectionViewController Is a lot more restrictive than UICollectionView. Same goes for UITableViewController. UITableViewController for example won't let you add another UIView to it without effecting to the UITableView hierarchy table view.
As a matter effect, I hardly use those ViewControllers and always prefer to use the original UICollectionView.
Just drag a UIViewController to your story board and drag a UICollectionView on top of it.
I have a flow issue in my iOS app from my subclassed UIView to its parent UIViewController.
Basically, I have a nib called preferences. It contains two sliders, two labels, and another UIView that will display a shape dictated by the two scroll bars (Stroke and opacity). I successfully painted the subclassed ui to the screen by setting the custom class of the UIView to a separate UIView we'll call subView. I have setters/getters for the scroll bars and they print out their values. How do i let the uiview class (pointed at the ui nib object) to update and redraw since it isn't referenced in the parent preferences class? I tried syntax like this:
[code]
IBOutlet SubClassUIView *subclassUI
[/code]
to no effect. It seems best to point a custom class at the UIView.
Any suggestions and advice would be much appreciated.
TL;DR can't modify subclassed uiview from "parent" uiviewcontroller
Sorry folks, i figured it out.
In addition to passing in a custom class that shares the same type as the IBOutlet (such as a UIView),
there MUST be a link referencing every object in in the .xib to its parent. In this case, the parent UIViewController needed a reference from the custom class ui to a IBOutlet UI. From there, some simple casting from generic and boring UIView to the custom class's unique methods makes for a complete flow.
Using proper MCV with Objective-C can a UIView subclass have #propertys?
i.e. in the .h file
#class MyViewSubclass;
#interface MyViewSubclass : UIView
#property (strong, nonatomic) UILabel *labelLabel;
#property (strong, nonatomic) UILabel *valueLabel;
#end
or should this be done in a UIViewController subclass?
Thanks in advance.
It is most common to subclass UIViewController to manage the labels, fields, images, and other views within a view hierarchy. However, if you are creating a reusable component view that will be used throughout your application, then it's perfectly appropriate to subclass UIView and add properties to your subclass.
From Apple's iOS App Programming Guide:
View controller objects manage the presentation of your app’s content on screen. A view controller manages a single view and its collection of subviews. When presented, the view controller makes its views visible by installing them in the app’s window.
The UIViewController class is the base class for all view controller objects. It provides default functionality for loading views, presenting them, rotating them in response to device rotations, and several other standard system behaviors. UIKit and other frameworks define additional view controller classes to implement standard system interfaces such as the image picker, tab bar interface, and navigation interface.
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/AppArchitecture/AppArchitecture.html#//apple_ref/doc/uid/TP40007072-CH3-SW1
It's good for views to have properties, but don't mix model logic into a view. The properties in a view should describe how the property looks, not what the property holds. I would avoid having a property named valueLabel in a view.
An example of view property names is UITableViewCell. It has properties imageView, textLabel, and detailTextLabel.
It's perfectly reasonable for a UIView subclass to have properties. You might need them to implement layoutSubviews, for example.
It is perfectly reasonable, also if you want to create a reusable component that allows for interaction and better flexibility, take a look at UIControl (which is a subclass of UIView)