I'm new to Objective-C and iOS programming. I've read through a few of Apple's "Getting Started" docs and I've downloaded a few sample applications to try and get familiar with what is going on in the app. What I'm confused about is what exactly happens from the application's launch. I see in main.m that UIApplicationMain gets called and invokes the AppDelegate. From what I've read, now, if applicationDidFinishLaunching returns true, the app will enter the main event loop.
Is this all correct? If so, how do I tie my code to events? Where do I create instances of my classes when an event occurs?
Finally, from my understanding, Xcode now creates all template apps with storyboards. However, some applications I am looking at are a bit older and don't use storyboards, but I don't see .xib or .nib files anywhere in the directory, but the applications successfully build. Am I wrong in assuming that applications require these files?
An application does not require a .xib or .nib to run. Many programmers do not use any of the visual design tools that generate storyboards or .nib files. You can define your UI completely in code if you wish.
The call to UIApplicationMain in main.m creates a singleton UIApplication object, sets up an event loop, and sets up your UIApplicationDelegate which works in tandem with UIApplication so you can customize the behavior of your app at key points in its lifecycle. UIApplication manages the event loop for you. It receives events from the system and dispatches them to your code for handling.
In order to really understand event handling you need to understand the responder chain. If you look at the superclass of your app delegate you will see it is UIResponder. This is the interface that lets objects respond to and handle events. It is the superclass of UIApplication and UIView and handles most of the raw event handling for you. Events follow a defined path through your code. In the simplest case, touch events, UIApplication pops an event from the event loop and hands it off to UIWindow. UIWindow will perform a hit test to try and deliver it directly to the UIView under the finger. It gets more complicated and motion events take a different path but the point is that much of the raw event processing is handled for you by UIKit. All you really need to do is setup your UIWindow and its rootViewController and events will follow a specific delivery path through all your UIKit responders. You can read about the responder chain in detail here https://developer.apple.com/library/ios/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/event_delivery_responder_chain/event_delivery_responder_chain.html.
When your app starts, the following delegate methods will get called in this order:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions;
- (void)applicationDidBecomeActive:(UIApplication *)application;
In addition, your initial view controller will get created and shown and the following methods will get called (assuming you are using storyboards or xib files):
-(void)viewDidLoad;
-(void) viewWillAppear:(BOOL)animated;
As for "tying your code to events", what type of events are you talking about? What are you trying to accomplish?
You no longer need to use xib files if you are using storyboards, however, you can if you want to.
Related
I was using Xcode 4.1 and after upgrading to 4.2, things started to become out of date. I am using many examples from different books, such as Big Nerd Ranch Guides, which do not use Storyboards and the Windows-Based Application had been changed to "Empty" Application.
With these new changes, I feel like the books and tutorials I had been using to start have become outdated. In many of these examples, they say to write the methods and variables in the delegate header files for 4.1. With the new 4.2 Xcode, there is an AppDelegate and ViewController. Should I still be writing the methods and class members in the AppDelegate, or should I be now writing them in the Controller file?
I am confused. Does Apple now want us to create our controller and reference it through the delegate?
When your app is run, it creates an instance of UIApplication. You want to know things that only the UIApplication object knows (did we just get switched to the background? did we just open?) so you use the delegate pattern to get it. When you start a new project Apple starts you off with an already-assigned App Delegate. You can open up MainWindow.nib and inspect your App Delegate to see how it is connected to your UIApplication instance (File's Owner, in this case).
In general you only want to put code in there that has to do with the basic functionality of your app. Launch, quit, go to background and come to foreground are when you'll be doing things in the App Delegate.
Most everything else should go in your view controllers or model objects. Since 'delegate' is just a design pattern, your view controllers can be delegates of other objects. For example, if you present a UITableView, you will assign a view controller as it's delegate in order to respond to events such as selection and scrolling. Your app has many delegates, but it only has one App Delegate.
The AppDelegate is really just a "launcher" for your app. Ie: You shouldn't be writing much code in it at all.
If you're concerned with "set up" code, do it in your View Controller, under viewDidLoad.
Could anyone tell me when we use the AppDelegate.m and AppDelegate.h during iPhone programming? I have used only the ViewController.m and ViewController.h for basic learning. I just want to know when and why AppDelegate is used.
Both define classes, but the classes are used for different things. ViewController.h/m define a view controller class that manages a hierarchy of views -- basically, one screen of an application. You might have multiple screens that each have their own view controller.
AppDelegate.h/m define a class that manages the application overall. The app will create one instance of that class and send that object messages that let the delegate influence the app's behavior at well-defined times. For example, -application:didFinishLaunchingWithOptions: is sent when the app has finished launching and is ready to do something interesting. Take a look at the UIApplicationDelegate reference page for a list of messages that the app delegate can implement to modify the behavior of the application.
I would like to add the following to #Caleb's answer.
If care is not taken, the AppDelegate could easily become one of the most accessed objects in the application. I usually refrain from calling methods in the AppDelegate from any of my ViewControllers. Unless, something needs to be reported to the AppDelegate that would influence the behaviour of the whole application.
I keep my AppDelegate for the following:
initialization: whatever needs to be done on the very first launch (after an install or an update)
data migration from version to version (e.g. if you use CoreData and migrations)
configuration of objects linked via IBOutlets from MainWindow.xib
determining the initial orientation to launch in
saving uncommitted data / state prior to the application being terminated or entering background mode
registering for the Apple Push Notification Service and sending the device token to our server
opening one of the supported application URLs (e.g. maps://)
For other use case scenarios and a more thourough description of the AppDelegate, see the iOS Application Programming Guide.
The view-controller. h/m is responsible of controlling the connection between your model and your view (more on MVC here).
AppDelegate. h/m is responsible for the life-cycle of your application. What to do when the user press the home button and exit your app, what to do when the app enter background. Things like this.
I am developing app with finding audio frequency by using FFT. In my app, I am not able to call application delegate method in app delegate class as given in below, but I could able to call other custom methods in app delegate class. What mistake I have done?
Please help me!
(void)applicationDidFinishLaunching:(UIApplication *)application
It looks like your project files have got a bit mixed up. To be honest, it's probably easier to start with a new application template as a base and then add your changes into it. If that is not possible, have a look at the following
In your {project_name}.plist file under the Resources folder you should see a setting
Main nib file base name
This will tell you which nib file is loaded at the start (normally MainWindow). Open this file and have a look for 'Files Owner' 'UIApplication'. Right click on this and there should be a link to the delegate. If it isn't there, then that's your problem
Check to make sure your application delegate inherits from NSObject and NOT NSApplication as NSApplication is a singleton. Otherwise your application object will be its own delegate.
You should now be using application:didFinishLaunchingWithOptions:
I come from an iPhone OS development background. I'm now trying to write apps for OSX, but I don't understand where cocoa on OSX decides where the program gets control.
I can see the main function, but where does program control go from there? Say for example I want to programatically create a window with an NSView in it once the app has finished launching - how would I do that? There is no app delegate created that I can see, in iPhone OS I would wait for the -(void) applicationDidFinishLaunching:(UIApplication *)application
method to be called. I really don't want to use the Interface Builder or NIB files to setup my window/view. How would I go about this?
It's much the same as the iPhone. In your application controller class, override NSApplication's applicationDidFinishLaunching delegate method. If you used the standard Xcode project template your app controller is already instantiated in your Interface Builder MainMenu.xib and set to be the application's delegate; if not you'll need to drag it in there and set up those connections yourself.
Speaking more generally, an OS X app begins its life in the main method, where Cocoa will automatically set up your application's run loop and load the .xib file you specify in Info.plist. This xib is usually where your application controller is instantiated. By overriding one of the methods such as +initialize, -init, -applicationWillFinishLaunching or -applicationDidFinishLaunching (which all have subtly different behaviors) you can load additional controllers and nibs with objects that interact with the run loop at a future date, so you can continue to execute code after your launch method has finished.
This question already has an answer here:
Closed 13 years ago.
Possible Duplicate:
iPhone Interface Builder and Delegates
What is the relationship between these three component in the Objective C / iPhone world? I found that the App Delegate have some relationship with the UI and the variable in code. It match the variable and related UI object on the view. But I found that the File's owner have the outlet called delegate that related to the Application delegate, what is their relationship. Also, the first responder, it seems it just receive some effect only. What's going on between there stuff?
One at a time:
File's Owner: This is the object that loads the xib file. In a completely generic sense, this is the object passed as the owner parameter to -[NSBundle loadNibNamed:owner:]. When working with a nib for a UIViewController subclass, this is usually the UIViewController subclass itself. Further reading: Resource Programming Guide: Nib Files
First Responder: This is the view that receives untargeted events (i.e. those sent with a target of nil) first. The useful part of this is that it's connected to the idea of the responder chain, which is a mechanism by which things higher up in the view hierarchy can capture unhandled and deal with them. This concept originated on the Mac, and is particularly useful for implementing something like the "Copy" menu item. The first responder is the target of the "Copy" menu item, meaning that the selected text field gets a chance to handle the copy event first, then its superview, and so on. Further reading: iPhone Application Programming Guide: Event Handling
Application Delegate: This is simply the delegate of the application's UIApplication object. It typically receives general status messages about the application, such as when it starts, ends and what not. It's a good spot to kick off things that need to happen when your app starts or shuts down. Further reading: Cocoa Fundamentals Guide: Delegates and Data Sources
Hope that helps.