I just noticed after adding a new ViewController that it isn't a UIViewController like the one created by Xcode. I didn't find an answer on google so I hope one of you could explain the difference between these two to me.
Edit
To clarify my question:
This is the declaration of my UIViewController:
#import <UIKit/UIKit.h>
#interface ViewController : UIViewController
And this is the declaration of my ViewController:
#import "ViewController.h"
#interface GameViewController : ViewController
What is the difference between these two ViewControllers?
What is the difference between these two ViewControllers?
Not a great deal, but it depends on the functionality defined in ViewController. It's fairly common to create a base class that contains common functionality you want in all derived classes, and view controller classes are no exception here.
However if ViewController contains no real functionality, then you can simply remove it and derive GameViewController directly from UIViewController:
#import <UIKit/UIKit.h>
#interface GameViewController : UIViewController
I would be very surprised if Xcode generated both ViewController and GameViewController in one operation, as you imply in your question, however. If it did, then that's new to me and I cannot see why it did it.
UIViewController provides infrastructure of the view, and when you make your own ViewController it is inherited from UIViewController. Just to be clear: you do not modify UIViewController, you subclass it, and then modify by your own.
UIViewController is a class provided by Apple. In order to perform UI customization for your app, you usually create subclasses of UIViewController.
ViewController is an example subclass of UIViewController.
A View Controller is a concept, is what manages a part of your user interface and interaction.
Based on the documentation:
View controllers are the foundation of your app’s internal structure. Every app has at least one view controller, and most apps have several. Each view controller manages a portion of your app’s user interface as well as the interactions between that interface and the underlying data. View controllers also facilitate transitions between different parts of your user interface.
An UIViewController is just the base class of this already defined "View Controller", you add a viewController as you said, but a viewController has a class associated to it, that can be a UIViewController, UITableViewController, or variations/subclasses.
Related
Say you have a 2 subclass of tableView controller.
They both have the same header and footer view on top of the bottom of the header. They both implement pull to refresh.
They both have some common features.
The only different is one is for displaying the whole businesses, the other is for displaying only businesses you bookmark.
It looks like they both need to have the same parent class and the different is resolved on the child class. The differences are minor anyway.
I suppose the parent has it's own XIB, the children has it's own XIB.
Hmm... How would that work out? With the exception of container UIViewController, each controller should view a fullview of content. So which view should we display? The child or the superClass? Should child view add it's superclass subview?
Anyone have ever tried that?
Any code sample on the web that use this approach?
It sounds like, based on the business logic you explain, that everything is in common, except the list of data you're presenting. You could expose a property on your UITableViewController subclass to set the business objects that your tableview presents:
#interface JTBusinessesTableViewController : UITableViewController
#property (nonatomic, strong) NSArray *businesses;
#end
The code that instantiates this class would set the business objects:
JTBusinessesTableViewController *businessListings; //Instantiate from XIB or Storyboard
businessListings.businesses = [self bookmarkedBusinesses];
[self.navigationController pushViewController:businessListings animated:YES]
The code for displaying all businesses isn't going to be much different:
JTBusinessesTableViewController *businessListings; //Instantiate from XIB or Storyboard
businessListings.businesses = [self allBusinesses]; // Here we assign all of them
[self.navigationController pushViewController:businessListings animated:YES]
You're just selectively giving this view controller, the business objects to display.
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.
In my storyboard, I have created a new UITableViewController object for which I would like to specify some custom code. I created a new controller with the following header:
#interface CustomController : UITableViewController
When I select the UITableViewController in the Storyboard view and navigate to the Identity Inspector, I can see my CustomController in the Custom Class drop-down. However, when I select it, I hear an error sound, which is referred to as "Morse" in the system preferences.
When I deselect the UITableViewController and re-select it, it has cleared my CustomController selection and replaced it with UITableViewController. I do not understand why XCode does not accept this, as from my understanding, this is all that is required to add your own code to a UITableViewController. I am not sure if I have encountered an XCode bug or if I have configured my class incorrectly.
It is possible to use a UIViewController as a UITableViewController, but you have to do some work. If you "convert" a UIViewController to a UITableViewController, you'll need to implement the UITableViewDelegate and UITableViewDatasource protocols. You may also need to provide an outlet for a UITableView. You'll also need to handle keyboard events. Basically a bunch of effort for not much return.
Probably best in your case to start fresh with a new UIViewController class inheritted from UITableViewController.
In a Navigation-based application, the method pushViewController:animated can be used. This is a method of the UINavigationController class. However, nowhere in the source files do I see any #import statements that import this class. The documentation doesn't show UIViewController as inheriting from UINavigationController.
So how are Navigation-based applications able to access this method?
UIViewController has a property called navigationController which is an instance of a UINavigationController. This is how it gets access to it.
I am new to Iphone Dev, seems doesn't really understand delegate things. Could we put mapkit view and tableview together in one view?
I searched over, and someone said we can't use more than one delegate in one viewcontroller. As I know mapkit require MKMapViewDelegate and tableview require UITableViewDelegate, am I right till this point?
Then does it mean, we can't put mapkit and tableview in one view together?
The things that make me also confused, I did simple app that use textview and mapkit together. I only pass MKMapViewDelegate to view controller. But textview also require delegate to close the keypad using textFieldShouldReturn. So i manage to link the delegate from IB file, but did't pass UITextFieldDelegate to view controller. And it works.
What is the difference if we link the delegate using IB or pass the delegate param to view controller?
Thanks
A view controller CAN be a delegate for both a map view and a table view. An object becomes a delegate simple by implementing the methods of the delegate protocol, in this case that's MKMapViewDelegate and UITableViewDataSource.
An object can implement any number of protocols. You tell the compiler that instances implement a protocol by adding it to the interface:
#interface MyObject : NSObject <UITableViewDataSource, MKMapViewDelegate>
{
...
There is no significant technical difference between setting a delegate in IB and in code. I would advise setting them in IB because using IB reduces the amount of code you write therefore reducing the possibility of your code failing.