I am having UIViewController which I want to use as a base controller for other view controllers. Base controller has a UICollectionView which has all the UICollectionViewCell prototype and some other stub views designed in storyboard.
All the child view controllers have one thing in common which is UICollectionView and has their own views in storyboard. I want to use the prototype cells designed in base view controller's collection view to populate child view controller's UICollectionView. I don't want to copy paste prototype cells from base controller's collection view to child controller collection view.
Base controller perform some actions on cell selection which are common to all child controllers. Child controller should be able to ask for any prototype cell from base controller, child will decide which cell to populate using cell identifiers.
I should be able to instantiate child controllers instead of base controller using their storyboard identifiers. I want to do maximum things in storyboard.
How this can be accomplished? Please suggest or any other better approach.
I am programming in Objective-C.
After digging a lot I found that its not possible to re-use prototyped UICollectionViewCell so I ended up creating separate XIB for each collection view cell.
This is what I did:
Created XIBs for collection view cells.
Wrote a base class BaseViewController which has a UICollectionView IBOutlet declared in its .h file. BaseViewController class confirms to UICollectionViewDelegate and UICollectionViewDataSource protocols.
2.1 In BaseViewController viewDidLoad method, registered all cell XIBs to UICollectionView.
2.2 Implemented delegate and data source methods which handle generic events. If needed child class can override those methods and perform specific tasks.
Create child view controllers in storyboard which have UICollectionView.
3.1 Connected UICollectionView to super's UICollectionView IBOutlet defined in .h file.
Now all done! Now I could dequeue any cell that is registered in super or if child view controller wants some specific cells it can prototype them in its own UICollectionView in storyboard and do the job.
Most of the times in my case didSelectItem was doing some generic operation in base class which were common to all child view controllers so I just dont implement it or if want to perform some other operations in addition to generic operations I implement the method and call super's implementation and after that do my stuff. All cell size and layout related methods are implemented by base view controller. Now I could create a new child view controller with collection view with minimal code and proper event handling.
Hope this helps someone. Thanks.
Related
Most of the time, owners of xib is a UIViewController.
I sort of use it my self.
Still I am confused why.
I suppose, the viewDidLoad and viewWillAppear is kind of the main selling point.
Is that it?
What are the advantage of using UIViewController as owners of an XIB?
A UIViewController object is the main way for views to appear within an iOS window.
Apple provides this as a fundamental, foundational building block (along with so many others) which you can use to build upon quickly and get your app out to market.
And when you subclass UIViewController, you're able to do lots of beautiful customizations which can be collected and eventually turned into (hopefully decent) products. When you subclass a UIViewController, you need to set the "owner" of a XIB file to that subclassed view controller (e.g. ThioViewController), so that way the app knows what object (and user interface) is being instantiated.
Hopefully this isn't too super abstract of an explanation.
First, spend a bit time to understand MVC http://en.wikipedia.org/wiki/Model–view–controller
This is the milestone of Objective-C (not only) development.
UIViewController is controller for all your views (inside this viewController). It provide starting point for you to create views on the screen, manipulate the views, handle actions from views etc.
You can create UIViewController programmatically.
XIB is representation of the screen which you can comfortably operate in Interface Builder to create and customize design of your application screen or one of the screens.
Since XIB represent the screen(view) it must be the controller which controls all the view on the screen - UIViewController or UINavigationController or other type of controller depending of your needs.
Most of time you will subclass UIViewController and use it to achieve you goals.
UIViewController have several subclasses which inherit directly from it (UINavigationController, UITabBarController).
Also UIViewController hav several methods (some of them)
-(void)viewDidLoad
This method is called after the view controller has loaded its view hierarchy into memory. This method is called regardless of whether the view hierarchy was loaded from a nib file or created programmatically in the loadView method. You usually override this method to perform additional initialization on views that were loaded from nib files.
and
-(void)viewWillAppear:(BOOL)animated
Parameters
animated
If YES, the view is being added to the window using an animation.
Discussion
This method is called before the receiver’s view is about to be added to a view hierarchy and before any animations are configured for showing the view. You can override this method to perform custom tasks associated with displaying the view. For example, you might use this method to change the orientation or style of the status bar to coordinate with the orientation or style of the view being presented. If you override this method, you must call super at some point in your implementation.
Please check Apple documentation for more information
https://developer.apple.com/LIBRARY/IOS/documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html
I am new to storyboard. I used to make my view using code. I have a question.
I created a view controller
#interface FunctionViewController : UIViewController
And I have use my code to add
a full screen button (alpha : 0.5)
a popup-like view in the middle (not full screen)
Then I created another Viewcontroller
#interface PlayFunctionViewController : FunctionViewController
and add some views on the popup-like view
I want to recreate these stuff by using storyboard.
How can I build these using interface builder and storyboard so that
I don't need to layout the full screen button and the popup-like view in every subclass of FunctionViewController?
You can't inherit the layout of a superclass in a subclass in a storyboard, i.e. if you visually lay out elements in a view controller in a storyboard and connect them to code, subclasses of that view controller, and even other instances of the same class, will have to be laid out individually, and will not automatically be populated or updated.
In other words, in a storyboard, you will have to manually lay out and connect all your interface elements in every individual instance and subclass that you add to the storyboard. This gives you flexibility in that you can reuse multiple instances of the same class throughout your app and lay them out differently, but it does not give you the ability to inherit layouts.
If you want to inherit your layout in subclasses, do your layout programmatically in the viewDidLoad of your superclass, and then all of your subclasses will have those interface elements, even if you design and lay them out in your storyboard (they will not be visible in the storyboard, but they will appear when you build and run your app).
Basically, if you want to have interface elements that are the same in a class and all its subclasses, create them programmatically, and they will exist in all instances and subclass instances, even if you create and design the instances themselves in your storyboard.
You can mix code and storyboard, so you can create some elements in your storyboard, but others that need to be present in all instances and subclasses, in code.
I ran into a similar issue, and though it was time consuming but creating a delegate and reusing it in multiple view controllers was a much better solution. Although that beats the whole point of 'Inheritance'.
As we all know, table views in Cocoa Touch are one of the niftiest pieces of framework elements that's out there. As a convenience, Apple gave us a nice view controller class to encapsulate the functionality of a table view in a vc, the UITableViewController.
At the same time, there are times that we want to utilize the functionality of a table view without having it take up the whole screen. However, there seems to be no way to do this by subclassing UITableViewController. Instead, I had to hookup a table view and manually subscribe to the UITableViewDelegate and UITableViewDataSource. If I try to subclass UITableViewController, my app crashes before it can even put the view on-screen...
My question is, is there something I'm missing? When subclassing UITableViewController, I hook up my custom table view to the tableView property in UITableViewController. Is there something else I have to do?
UITableViewController only adds minor conveniences over UIViewController: it creates and positions the table view, hooks up the delegate & datasource (to itself, generally), passes the view controller editing property through to the table, and does a couple of useful UI bits when the view appears. (See [the docs][1] for details.)
Just about all of the above are either A) things that you're needing to change in order to have a non-fullscreen table, or B) things that you can do in a line or two each, and which UITableViewController only does for your convenience. For cases like this, you're better off using your own UIViewController subclass.
Step 1: Subclass UIViewController instead of UITableViewController
MyTableViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
Step 2: Use interface builder to drop a tableView and custom View
Step 3: Declare the tableView property as IBOutlet in your MyTableViewController header file and bind it to the tableView in the interface builder
IMHO, This process would give you more flexibility.
I have a UIViewController, with a UITableView which takes up half the screen.
I also have a subclassed UITableViewController, but I can't figure out how I would associate the subclassed UITableViewController with my table?
It is not clear from your question exactly why you are trying to create a UITableViewController and a UIViewController in this case. Do you have 2 different tables you are trying to control? Or are you trying to do something special to have 2 different controllers managing different parts of a view/subview hierarchy?
Typically, the table for a UITableViewController is created automatically or within a NIB file. From the UITableViewController documentation:
If a nib file is specified via the initWithNibName:bundle: method
(which is declared by the superclass UIViewController),
UITableViewController loads the table view archived in the nib file.
Otherwise, it creates an unconfigured UITableView object with the
correct dimensions and autoresize mask. You can access this view
through the tableView property.
So you would usually not need to associate your subclassed UITableViewController with its table because that is taken care of for you.
I'm trying to understand how these two are connected. Every time you make a UIViewController does it also automatically come with its own UIView?
Also are these from Cocoa or Objective-C?
UIViewController is a Cocoa Touch class built for the purpose of managing UIViews. It expects to have a view hierarchy, but you don't "automatically" get a view (this is slightly inaccurate; see edit below). Usually you will obtain views by calling initWithNibName on your view controller.
There is some built-in magic in Interface Builder which knows that if File's Owner is a UIViewController (or subclass), there is a property called view. That's about it.
Once you have linked a view controller and a view, the view controller does a fair amount of work for you: it registers as a responder for view touch events, registers for device rotation notifications (and handles them automatically, if you wish), helps you take care of some of the details of animation, and handles low-memory conditions semi-automatically.
Edit: correction—if you don't call initWithNibName or set the view property manually, the view property getter will invoke loadView if view is nil. The default implementation of loadView will see if you've set nibBundle and nibName and attempt to load the view from there (which is why you don't have to call initWithNibName, most of the time), but if those properties aren't set, it will instantiate a UIView object with default values. So technically, yes, it does automatically come with its own UIView, but most of the time that's of little value.
UIViewController doesn't automatically come with a view. You have to make a view in the -loadView method. By default, this loads the view from the nib file you've specified. You can also override this method to make a custom view if you prefer not to use a nib.
Also, the view is not created right when the UIViewController is created. UIViewController uses a technique known as lazy-loading to defer the creation of a view until the view is actually accessed for the first time.