How to Use UIApplicationMain to Develop Your iOS App - dummies

How to Use UIApplicationMain to Develop Your iOS App

By Jesse Feiler

The UIApplicationMain function is important for iOS app development. It creates the application object (a singleton — the only — UIApplication object) and the application delegate (a class created for you by the Xcode template). It also sets up the main event loop, including the app’s run loop and begins processing events.

UIApplication provides application-wide control

The UIApplication object provides the application-wide control and coordination for an iOS app. It’s responsible for handling the initial routing of incoming user events as well as for dispatching action messages from control objects to the appropriate target objects.

The application object sends messages to its application delegate to allow you to respond in an application-unique way to occurrences such as application launch, low-memory warnings, and state transitions such as moving into background and back into foreground.

Delegation is a mechanism used to avoid subclassing complex UIKit objects, such as the UIApplication object. Instead of subclassing and overriding methods in a framework or other object, you go ahead and use that object unmodified and opt for putting your custom code inside a delegate object instead.

The Application Delegate object is responsible for handling several critical system messages and must be present in every iOS app. The object can be an instance of any class you like, as long as it adopts the UIApplicationDelegate protocol. In the template, you’ll find that it’s a subclass of UIResponder, which enables it to respond to and handle events. (UIApplication is also derived from UIResponder.)

The methods of this UIApplicationDelegate protocol correspond to behaviors that are needed during the application life cycle and are your way of implementing this custom behavior. You’ll often find yourself writing code to handle the following:

  • Initialization in your application delegate’s application:didFinishLaunchingWithOptions: method.

  • State transitions such as moving in and out of background and foreground.

  • Low-memory warnings.

The UIApplication is a singleton object. To get a reference to it, you send the sharedApplication message to the UIApplication class. Sending the object the message gives you a pointer to the delegate object:

AppDelegate *appDelegate =    [[UIApplication sharedApplication] delegate];

UIApplicationMain loads the storyboard

If the application’s Info.plist file specifies a storyboard file, the UIApplication function loads it. The app’s Info.plist file provides a map to the high-level structure of the app.

To see the file, select it under the Supporting Files heading in the Project navigator. The file dutifully appears in the Editor area.

image0.jpg

A nib file is a resource file that contains the specifications for one or more objects and is used to graphically create your user interface using Interface Builder in apps when you’ve opted not to use a storyboard.

If you’re using a storyboard, the initial view controller is instantiated for you. The Initial View Controller setting is a View Controller property. It is set for you by most of the Xcode templates.

Note the check box in the View Controller attributes in the Utility area. In the iPad storyboard file, the initial view controller is a Split view controller that was included by the template. The nib-loader will also instantiate both Navigation controllers as well as their Root view controllers.

image1.jpg

In the iPhone storyboard file, the initial view controller is a Navigation controller that uses a Table View controller as its root view controller.

UIApplication sends the application:didFinishLaunchingWithOptions: message to its delegate

If the method is implemented in the application delegate, the application:didFinishLaunchingWithOptions: message is sent to the application delegate.

Launch time is a particularly important point in an application’s life cycle. In addition to the user launching an app by tapping its icon, an app can be launched to respond to a specific type of event. An Options dictionary passed to the application:didFinishLaunchingWithOptions: method provides information about the reason for the launch.

The application:didFinishLaunchingWithOptions: message is sent to the delegate when the app has launched and its storyboard has been loaded. In this step, as you will see, you initialize and set up your app. At the time this message is sent, your app is in the inactive state. At some point after this method returns, your app will become active and will receive the applicationDidBecomeActive: message when it enters the foreground.

Ideally, you get your users directly into the app as quickly as possible without those outdated welcome screens. In fact, the way in which you do this is to provide one or more launch images that you typically place in your app’s asset catalog.

A launch image is the background of the first screen the user sees. An easy way to create them is to set a breakpoint in a viewDidLoad method for the first view the user will see. Stop the action just before you add any data to the view.

At runtime, the launch image for the appropriate device and orientation will be presented immediately, and, if you look very carefully, you’ll be able to see the content appear to be quickly placed on the background.

The class interface (declared in the .h file) lists the messages to which an object of that class can respond. The actual code for implementing a message is called a method and will be found in the associated .m file. When you want to have an object execute a method, you send it a message. The message is what you want done, while the method is how to do it.

Don’t load large data structures that your app won’t use right away. If your app requires time to load data from the network, get your interface up and running first and then launch the task that takes a longer time on a background thread.

In the templates that don’t use a storyboard, the application:didFinishLaunchingWithOptions:method allocates and initializes the window and the Split view controller, adds it all to the window, and makes the window visible.

In a storyboard-based app, this is all done by the storyboard for you, and the application:didFinishLaunchingWithOptions:method does nothing other than return.