InterfaceBuilder generates this method for me in fooAppDelegate.m:
- (void)applicationDidFinishLaunching:(UIApplication *)application {
// Override point for customization after app launch
[window addSubview:[navigationController view]];
[window makeKeyAndVisible];
}
IB also puts UIWindow *window; in fooAppDelegate.h and #synthesize window; in fooAppDelegate.m, and correspondingly for navigationController. IB generates code to release window and navigationController in dealloc.
I cannot see any code that allocates and initializes the window and the navigationController. I wonder where that happens.
Ari.
Inside of the XIB file, there is code that instantiates the objects that are stored inside of it.
That is why the UIWindow instance is a IBOutlet.
Anything that is a IBOutlet is typically instantiated from the XIB file.
Interface Builder is NOT a code generator, it's a live object factory.
"Interface Builder saves an application's interface as a bundle that contains the interface objects and relationships used in the application. These objects are archived (a process also known as serialization or marshalling in other contexts) into either an XML file or a NeXT-style property list file with a .nib extension. Upon running an application, the proper NIB objects are unarchived, connected into the binary of their owning application, and awakened"
Related
I have a simple iOS application with one UIViewController beneath a UINavigationController. The UIViewController has an IBOutlet for an NSManagedObjectContext.
The AppDelegate has an IBOutlet for the nav controller - but not the view controller. The view controller is automatically instantiated ala the XIB process (as a child of the nav controller).
With this setup, how does one cleanly assign or pass the app delegate's NSManagedObjectContext to the view controller's IBOutlet property. There is a nav controller in the way :) and the app delegate doesn't have a direct property for the UIViewController.
It is a weird problem in that, I want to link a property from one XIB component to another component's property. Most of the XIB work I've done takes a property and points it to an object in the XIB which in turn - gets instantiated ala the normal process but in this case, the context is being created correctly in the app delegate, I just want to pass it on to the view controller when it instantiates it.
You don't need to pass it, just grab it from the app delegate as required:
#import "MyAppDleegate.h"
NSManagedObjectContext* moc = [(MyAppDelegate*)[UIApplication sharedApplication].delegate managedObjectContext];
Apple's docs recommend that you pass references to your managed object context to the classes the require them instead of referencing it from your app delegate.
Here's what the application:didFinishLaunchingWithOptions: looks like in one of my Core Data projects.
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
LocationsViewController *lvc = (LocationsViewController *)self.navigationController.topViewController;
lvc.managedObjectContext = self.managedObjectContext;
assert(lvc.managedObjectContext != nil);
[self.window addSubview:self.navigationController.view];
[self.window makeKeyAndVisible];
return YES;
}
You'll see that I also start with a UINavigationController with a single root view controller.
You've got the right idea, but the problem you're wrestling with seems to be entirely of your own creation. You say that your app delegate has an outlet for the navigation controller, but not for the nav controller's root view controller, because you've set up your nib such that the view controller is created when the nib is loaded. There's nothing wrong with that, but there's also no reason that the app delegate shouldn't have an outlet for that controller. Indeed, the entire reason for outlets is to get references to things that are loaded from a nib.
Add an outlet to your app delegate for your root view controller, and connect it. The app delegate can then give the controller a reference to the managed object context.
With respect to your question about multiple view controllers, I wonder what sort of real-world app might have view controller (A), which needs data, load another view controller (B) which doesn't need any data, followed by a third (C) which again needs data? A realistic example might help, if you have one.
Remember that you don't have to pass the entire managed object context to each successive view controller. You can instead pass just the part of the model that the controller will need to do its work by passing a managed object.
I am trying to figure out the relationship between the appdelegate, RootViewControoler, and UIApplication. Here is what I kinda have figured out so far:
When starting your application up, main.m gets loaded.
From here, your MainWindow.xib gets loaded.
In your MainWindow.xib, your File's Owner is of type UIApplication.
You set your UIApplication's delegate to your AppDelegate.
In your AppDelegate's source code, you can set your RootViewController to be the first view shown.
Is this right? What prompts AppDelegate to initially run it's
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { }
method?
When an Objective-C application starts, it starts by running the function named main(). It doesn't have to be in the file "main.m" but that's how the Xcode wizard sets things up.
Inside the wizard-produced main() function, there is this line:
int retVal = UIApplicationMain(argc, argv, nil, nil);
That is what starts the "UIKit" framework that makes up the entire application. Inside UIApplicationMain, an object of type UIApplication is created. And part of what UIApplication does when the application starts is call the applicationDidFinishLaunchingWithOptions method on the delegate member of the UIApplication class. This delegate is set up in the MainWindow.xib file to be an instance of your ProjectAppDelegate class, a subclass of NSObject that conforms to the UIApplicationDelegate protocol.
What prompts AppDelegate to initially
run it's ...
Because in your MainWindow.xib file you have connected (well the project wizard did the connection actually) the File's Owner (which is the UIApplication object)'s "delegate" outlet to the UIApplicationDelegate object in the the .xib file, and the class of the UIApplicationDelegate is set to your app's UIApplicationDelegate subclass.
And there's nothing magic about "MainWindow.xib", it could be called "Foo.xib", what's important is that the property in your Info.plist file called "Main nib file base name" is "MainWindow". Trying renaming MainWindow.xib to Foo.xib and changing the "Main nib file base name" in your Info.plist to "Foo" and you'll see it still works.
EDIT: more about RootController
Again, there's nothing magic about the so-called "RootController". This is just the name of the UIViewController subclass created for you by the Xcode new project wizard.
The wizard places code in the project for two classes: ProjectAppDelegate and ProjectViewController. The ProjectAppDelegate class contains two outlet members:
IBOutlet UIWindow *window;
IBOutlet ProjectViewController *viewController;
in the MainWindow.xib file, instances of both UIWindow and ProjectViewController are placed, and hooked up to the above outlets in ProjectAppDelegate.
What gets your stuff up on the screen is this code in your ProjectAppDelegate class:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
// Override point for customization after application launch.
// Add the view controller's view to the window and display.
[self.window addSubview:viewController.view];
[self.window makeKeyAndVisible];
return YES;
}
Again, nothing really magic about this: the project wizard created code that adds your "root" ViewController's view to the window's view, and makes the window visible. Your "root" view controller was create in the .xib file, and hooked up to the ProjectAppDelegate outlet.
It is very instructive to try to create an application entirely by yourself without using any of the files from the wizard. You'll learn a lot about how .xib files work and how they relate to code objects.
The starting point of iOS apps is always the main() function (thanks #bogatyr) which usually contains code similar to,
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
The last two parameters of UIApplicationMain are important and specify the principal class name, and the application delegate. If they are nil, then Info.plist will be looked up for the main window xib (usually MainWindow.xib).
// If nil is specified for principalClassName, the value for NSPrincipalClass
// from the Info.plist is used. If there is no NSPrincipalClass key specified, the
// UIApplication class is used. The delegate class will be instantiated
// using init.
.. UIApplicationMain(int argc, char *argv[], NSString *principalClassName, NSString *delegateClassName);
It is not necessary to set the File Owner through xib, and they can be specified directly in this UIApplicationMain function.
principalClassName can be the string UIApplication or a subclass of UIApplication. Similarly delegateClassName can be directly specified in this method. The delegate class is instantiated using init as the docs say. Suppose we specify our delegate class - MyAppDelegate as a string,
UIApplicationMain(int argc, char *argv[], nil, #"MyAppDelegate");
First an instance of UIApplication is instantiated, which will then create the delegate class from this string using NSClassFromString I suppose.
Once delegateObject has been instantiated, and application is ready, this delegateObject will be informed using the delegate method, didFinishLaunchingWithOptions.
Class delegateClass = NSClassFromString(#"MyAppDelegate");
id <UIApplicationDelegate> delegateObject = [[delegateClass alloc] init];
// load whatever else is needed, then launch the app
// once everything is done, call the delegate object to
// notify app is launched
[delegateObject application:self didFinishLaunchingWithOptions:...];
This is how UIApplication would handle it programmatically, if no nib is used. Using a nib in the middle is not much different.
Since your AppDelegate is a delegate of UIApplication - it listens to all notifications that UIApplication class posts during it's lifecycle. didFinishLaunching notification is one of them and it causes your AppDelegate to call aforementioned method.
For Universal — iPhone + iPad — apps you can specify that different NIBs load on each platform, either in the target Info panel or by adding NSMainNibFile~ipad and NSMainNibFile~iphone keys to your Info.plist. Alternatively, you can add a MainWindow~ipad.xib NIB to your target, it will be loaded on the iPad instead of MainWindow.xib, based on the NSMainNibFile key in Info.plist.
If you need more control and customization for a Universal app you can load the starting NIB manually. The "Universal" project template has the boilerplate for this method, so the quickest way to get started using this technique is to just create a new iOS project with the Universal profile.
In the above examples the Main NIB File is set in Info.plist (target settings) so that you will already have a NIB loaded when your application delegate is invoked. Usually in this setup a MyAppDelegate object will also be archived in the NIB (with some IBOutlets) and the NIB's File's Owner will be set to UIApplication.
For a universal project to be able to accommodate two alternative layouts, the Main NIB File key is left out of Info.plist. Then it instantiates the application delegate object programmatically in UIApplicationMain:
#import "MYAppDelegate.h"
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([MYAppDelegate class]));
}
}
Then check your environment and settings and load the appropriate NIB in application:DidFinishLaunchingWithOptions:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
_window = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];
// Override point for customization after application launch.
if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPhone) {
_viewController = [[[MYViewController alloc] initWithNibName:#"MYViewController_iPhone" bundle:nil] autorelease];
} else {
_viewController = [[[MYViewController alloc] initWithNibName:#"MYViewController_iPad" bundle:nil] autorelease];
}
_window.rootViewController = _viewController;
[_window makeKeyAndVisible];
return YES;
}
- (void)dealloc {
[_window release];
[_viewController release];
[super dealloc];
}
The new step is to create a root MYViewController manually, loading the appropriate NIB. In this setup the File's Owner is your shiny new MYViewController rather than UIApplication. If you want, MYViewController can adopt much of what you may have been using your application delegate for - which is often to encapsulate the core model class of the app, act as a data source and delegate for the views and other things in the NIB.
So you're expected to have some root UIView in the NIB, and it should be hooked up to the view outlet of the File's Owner (MYViewController).
Note that MYViewController's NIB isn't actually loaded until the first time the MYViewController.view property is accessed. Only then will [MyViewController viewDidLoad] be called! The most likely time for this to occur is when you add it to the root window.
In the template code shown above the root UIWindow is instantiated by the app delegate, but there's no reason you couldn't include it in your NIB instead. If you choose to do this, be careful. If you set the rootViewController of the window in the NIB to the File's owner in that case, it will cause the controller's view to be added to the window when the window is activated. Be careful constructing that first NIB in any case.
The app delegate doesn't necessarily need to have a reference to your root UIWindow if you want MYViewController to manage it, but it may be cleaner overall to keep the root window out of your NIBs and manage it in the app delegate.
Outside of that (!) there's not much different from the single-platform approach.
MainWindow.xib is defined in your info.plist as the Main nib file base name. In your MainWindow.xib, you define the first controller that you want to load, in your case, RootViewController.
didFinishLaunchingWithOptions: is part of the UIApplicationDelegate protocol. This method (in iOS4.0+) is always known to be the first to be called when launching an application.
I'm having this problem because I originially made everything in the main NIB, but then after reading learned that it is better to use subviews.
I've got my IBActions in the AppDelegate, and I've successfully connected and loaded my subviews. However, when I try to connect my buttons in the subviews to the IBActions in the AppDelegate, the IBActions appear under the "First Responder". They seem to connect fine, but when running the application they do not trigger the IBActions (I've confirmed this with some NSLogs, it's not an error in the code within the IBActions). What am I doing wrong?
Thanks!
The AppDelegate should only be used for very specific items such as implementing the UIApplicationDelegate protocol (i.e. methods like applicationDidFinishLaunching) or in some cases storing global variables.
You should keep IBActions and other outlets in their respective view controller files (i.e. if you created MyViewController.h and MyViewController.m which are linked with MyViewController.xib where you have some buttons, images, etc.). They can then be hooked up via dragging the inspector control you want (i.e. TouchUpInside) to the File's Owner.
Something you should read to better understand view controllers: http://developer.apple.com/iphone/library/featuredarticles/ViewControllerPGforiPhoneOS/Introduction/Introduction.html
Typically it is best to create a unique view controller for each view you will present to the user. For instance, if I had a main screen and then an "about" or a settings screen, I would make each of those their own view controller. It helps organize things better than using one view with a whole bunch of subviews that you hide/show and will also improve loading times and general performance.
Update for your 2nd question in the comments about accessing the app delegate:
First, you need to import the .h file (i.e. #import "AppDelegate.h") for the app delegate into whichever view controller .m file you wanna use to access whatever variables, arrays, etc you have stored in the app delegate files. Make sure you synthesize whichever objects you create in the app delegate's .h file in the app delegate's .m file so the getters and setters are created (so you can access them).
Then in the view controller .m file, in whichever method you are using:
-(void)someMethod {
// here we just create a shortcut to the app delegate called "theAppDelegate"
YourAppDelegateFileNameHere *theAppDelegate = (YourAppDelegateFileNameHere *)[[UIApplication sharedApplication] delegate];
// now you can use the dot notation if you wanna access a variable
int SomeNewInteger = theAppDelegate.someIntegerYouHaveStored;
// or some array you have stored
return [theAppDelegate.someArrayYouCreated count];
}
Hope that helps!
I am new to iPhone and objective c. I have spent hours and hours and hours reading documents and trying to understand how things work. I have RTFM or at least am in the process.
My main problem is that I want to understand how to specify where an event gets passed to and the only way I have been able to do it is by specifying delegates but I am certain there is an easier/quicker way in IB.
So, an example.
Lets say I have 20 different views and view controllers and one MyAppDelegate.
I want to be able to build all of these different Xib files in IB and add however many buttons and text fields and whatever and then specify that they all produce some event in the MyAppDelegate object. To do this I added a MyAppDelegate object in each view controller in IB's list view. Then I created an IBAction method in MyAppDelegate in XCode and went back to IB and linked all of the events to the MyAppDelegate object in each Xib file.
However when I tried running it it just crashed with a bad read exception.
My guess is that each Xib file is putting a MyAppDelegate object pointer that has nothing to do with the eventual MyAppDelegate adress that will actually be created at runtime.
So my question is...how can I do this?!!!
If you create an instance of MyAppDelegate in each nib file then, yes, you do end up with a lot of different instances of the class when all the nibs load. The app delegate is not identified by class or even protocol but rather by being the object pointed to by the application instance's delegate property. To find the true app delegate, you have have to ask the application object itself for its delegate
You should have all your view controllers descend from a parent view controller class that has an appDelegate property. Implement something like this:
#import "MyAppDelegateClass.h"
#interface ViewControllerBaseClass :UIViewController {
MyAppDelegateClass *appDelegate;
}
#property(nonatomic, retain) *appDelegate;
#end
#implementation ViewControllerBaseClass
#synthesize appDelegate;
-(MyAppDelegateClass *) appDelegate{
self.appDelegate=(MyAppDelegateClass *)[[UIApplication sharedInstance] delegate];
return appDelegate;
}
#end
When the view controller needs the app delegate it just calls self.appDelegate. If you want to access an attribute of the app delegate use self.appDelegate.attributeName.
The important thing is that you ask the application for its specific delegate instance at runtime. You can't do that from a nib file.
I'm not entirely clear what exactly you're trying to do, but it's probably a bad idea. There should only be one app delegate per application, and it should deal with behavior for the whole application. Typically, the app delegate initializes the root view controller(s) and displays them, but not much else (other than handling things like opening and saving data sources).
The view controllers (subclasses of UIViewController) should interact with the XIBs. Having the view-specific behavior in the view controllers makes the app much easier to manage and maintain. Typically, there should be 0 or 1 XIBs per view controller (more than that is complicated). You set up the interaction with the views using the Target/Action pattern with IBOutlets and IBActions (see here for a complete guide). It's generally a bad idea to make view controllers or XIBs dependent on the app delegate (since reducing dependencies again makes the code easier to manage).
In general you should be making a view controller for each of the views you are building, and link events to those view controllers - not the app delegate. In fact usually no event ever is wired to the app delegate from any nib file, even in the sample projects you'll note that view controllers are created and held onto by the app delegate, but it does not receive events.
I am new to the iPhone SDK and am trying to create 3 views and switch between them. Data will come from a server and I will basically be showing 1 view and caching the other two. So far I am just trying to create a view and display it at run-time. My code is listed below. It shows only a blank screen and I think I am missing a key concept. Any Help?
#import <UIKit/UIKit.h>
#import "ImageViewController.h"
#interface Test5ViewController : UIViewController
{
IBOutlet UIView *rootView;
ImageViewController *curImage;
ImageViewController *nextImage;
ImageViewController *prevImage;
}
#property(nonatomic,retain) IBOutlet UIView *rootView;
#property(nonatomic,retain) ImageViewController *curImage;
#property(nonatomic,retain) ImageViewController *nextImage;
#property(nonatomic,retain) ImageViewController *prevImage;
#end
and
- (void)loadView
{
self.curImage = [[ImageViewController alloc]initWithNibName:#"ImageView" bundle:[NSBundle mainBundle]];
UIImage *pic = [UIImage imageNamed:#"baby-gorilla.jpg"];
[self.curImage assignImage:pic];
self.rootView = self.curImage.view;
}
and
#import <UIKit/UIKit.h>
#interface ImageViewController : UIViewController
{
IBOutlet UIImageView *image;
}
-(void)assignImage:(UIImage *)screenShotToSet;
#property(nonatomic,retain) IBOutlet UIImageView *image;
#end
Welcome to the iPhone SDK!
In general, there are two ways to get any view displayed.
First, and most commonly, you use a NIB file created by the Interface Builder. This is usually the easiest way to get started and I would recommend it for what you're trying to do here. It's too lengthy to describe all the steps you need to do for what you have here, but basically start in xcode by creating a new file and selecting "user interfaces" and choose View XIB. This will create a basic NIB file (they're called NIBs rather than XIBs for historical reasons). The first step in interface builder is to change the class name of the "File's Owner" to your UIViewController subclass (Test5ViewController). You can then drop anything that IB will allow into the view window or even replace the pre-supplied view object with one of your own. And here's the trick: make sure the view outlet (supplied by the UIViewController superclass) is connected to a view. Once this is done, this view will be automatically loaded when your NIB is loaded. You can then just put your UIViewController subclass (Test5ViewController) in your MainWindow.xib NIB file to get it automatically loaded, and you're in business.
Now, the way you're doing it here is the second way. Some people like to code this way all the time and not user interface builder. And while it's definitely necessary sometimes and always more flexible, it makes you understand what is happening a bit better. There may be other things, but the main thing you're missing is that in your code above, you have nothing that is adding your view into the view hierarchy. You need to check first that you have an UIApplicationDelegate subclass and it needs to load your "root" UIViewController class. All initial project creation types in xcode do this (except Window-based application). It is code like:
[window addSubview:rootController.view];
Once this is done, if your view controller wasn't loaded by the NIB (described briefly above), your loadView method will be called, expecting you to build your own view hierarchy. Above, you created the view(s), but failed to put them in a hierarchy. You need something like:
[self.view addSubview:curImage.view];
No view will be rendered until added to the view hierarchy. Make sure to look up the UIView class in the documentation and understand the variety of ways to add and remove views to the view hierarchy.
A couple things I should warn you about:
* your code above is leaking. You need to review how objective-C properties work. There's lots on this site about it. More than I have time to write about here.
* don't create a rootView property in the case you have here. There already is one in the superclass (UIViewController). It's just 'view'. Use that for saving your root view.
I hope this helps you get started. It can be bewildering at first, but you'll soon get it going! I recommend building and rewriting and rebuilding a lot of sample code before you do your "real" application. The SDK has many great samples.