ios-deep parsing the life cycle of iOS apps

Summary:iOS applications are generally composed of code and system frameworks that are written by themselves, and the system framework provides some basic infrastructure for the app to run, while developers write their own code to customize the appearance and behavior of the app to learn about iOS Infrastructure and how it works can be helpful for writing apps.

iOS applications are typically made up of code and system frameworks that are written by themselves (System frameworks), which provides some basic infrastructure for all apps to run, and you provide your own code to customize the look and behavior of your app. Therefore, understanding iOS infrastructure and how they work can be helpful for writing apps.

Main function Entry

All the portals of C-based apps are main functions, but iOS apps are a little different. The difference is that you don't have to write the main function for your iOS app yourself, which is provided when you create a project using Xcode. Unless something special happens, you should not modify the main function implementation that Xcode provides. The sample code is as follows:

[CPP]View Plaincopy

1. #import <UIKit/UIKit.h>
2. #import "AppDelegate.h"
4. int main (int argc, char * argv[])
5. {
6. @autoreleasepool {
7. return Uiapplicationmain (argc, argv, Nil, Nsstringfromclass ([Appdelegate class]));
8. }
9. }

The above example code has a very important function uiapplicationmain, which is mainly to create several core objects of the app to handle the following procedures:

1. Load the user interface from the available storyboard files;
2. Call Appdelegate custom code to do some initialization settings;
3. Put the app in the main Run loop environment to respond to and handle events generated by user interaction.

architecture of the application

iOS applications follow the Model-view-controller architecture, which is responsible for storing data and processing business logic, and view is responsible for displaying data and interacting with the user, the controller is the intermediary between the two, coordinating model and View collaboration. Their rules of communication are as follows:

1. Controller can access model and View,model and view cannot access each other.

2. When the view interacts with the user to generate an event, it is handled using the Target-action method.

3. When view needs to process some special UI logic or get a data source, it is handled by delegate or data source to the controller.

4. Model cannot communicate directly with the controller, and when the model has data updates, it is possible to notify the controller to update the view by notification or KVO (Key Value observing).

After understanding the MVC design Patterns of iOS, we never know what the key objects are in the MVC model and what are the main responsibilities of the iOS application?

• UIApplication Object

Events generated when a user interacts with an iOS device (Multitouch events,motion event,remote control event) is referred to the UIApplication object for distribution to Control Objects (Uicontrol) corresponds to the target objects to process and manage the entire event loop, while some important events about the app runtime are delegated to the app delegate for processing.

• APP Delegate Objects

The app delegate object follows the Uiapplicationdelegate protocol, responding to important events when the app is running (app Launcher, app out of memory, app termination, switching to another app, cutting back to the app), Used primarily for apps that initialize some important data structures at startup, for example, initialize UIWindow, set some properties, and add Rootviewcontroller to the window.

• View Controller Object

View Controller has a view property that is the root view in the view hierarchy, and you can add sub-view to build complex view;controller there are viewdidload, Viewwillappear and other methods to manage the view's life cycle, and because it inherits Uiresponder, all also responds to and handles user events.

• Documents and Data Model objects

The data model object is primarily used to store the information. For example, when the app searches for a switch address, it has a history search address history, and when the app is next launched, it reads and displays the search address history.

The Document object (inherited Uidocument) is used to manage some or all of the data Model objects. Document objects are not required, but provide a convenient way to group data that is part of a single file or multiple files.

• UIWindow Object

The UIWindow object is at the top of the view hierarchy, acts as a basic container without displaying content, and if you want to display content, add a content view to the window.

It is also an inherited uiresponder, so it will also respond to and handle user events.

• View, control, Layer object

The View object can manage the view hierarchy through methods such as Addsubview and Removefromsuperview, using Layoutsubviews, Methods such as layoutifneeded and setneedslayout layout view hierarchies, you can override the DrawRect method or use the Layer property to construct complex graphical appearances and animations when you find that the system provides a view that does not meet your desired appearance requirements. Also, UIView also inherits Uiresponder, so it can handle user events as well.

A control object is typically a view that handles a particular type of user interaction, often with a button, switch, Text field, and so on.

In addition to using view and control to build the view hierarchy to influence the app's appearance, you can use the core animation frame's Layer object to render the view appearance and build complex animations.

Main Run Loop

The main run loop of an iOS application is to handle all user-related events. The UIApplication object sets the main run loop at startup and uses it to handle events and update the view-based interface. As its name shows, main run loop is the main thread running in the application. This ensures that the events associated with receiving the user are processed in an orderly manner.

Shows how the schema and user events for main run loop are ultimately handled by the application. When the user interacts with the device, the system generates an event associated with the interaction, which is then distributed by the application's Uikit through a special port. The application puts events into the queue and then distributes them to main run loop one by one. The UIApplication object is the first object that receives an event and then decides what to do with it. A touch event is typically distributed to the main Window object, which is then distributed to the touch view in turn. The Receive event object path for other events may be a little different.

Most events are distributed by using the main run loop, but some are not. Some events are sent to a delegate object or passed to the block you provide. To learn more about how to handle most types of events, including touch, remote control, motion, accelerometer, and gyroscopic events, see Event Handle Guide for IOS.

application state and multi-tasking

Sometimes the system switches from one state of the app to another to respond to events that occur in the system. For example, when a user presses the home key, a phone break, or another interrupt occurs, the currently running application switches state to respond. The status of the application is as follows:

• Not Running:app is not running yet
• Inactive:app running on foreground but not receiving events
• Active:app running in foreground and receiving events
• Background: Running in Background and executing code
• Suspended: Running in background but no code execution

Most state transitions call the delegate object's method to respond to the app's state change. The following summarizes all the methods of the delegate object, which you might use when the app state transitions.

• Application:willfinishlaunchingwithoptions:-This method is your first chance to execute code at startup
• Application:didfinishlaunchingwithoptions:-This method allows you to perform the final initialization operation before displaying the app to the user
• Applicationdidbecomeactive:-What needs to be done after the app has switched to the active state
• Applicationwillresignactive:-What you need to do when the app is going to switch from the foreground to the background
• Applicationdidenterbackground:-What needs to be done after the app has entered the background
• Applicationwillenterforeground:-The app will switch from the background to what the foreground needs to do, but the app is not active
• Applicationwillterminate:-What you need to do when the app is going to end

Now let's talk about the way the app starts, switches back and forth between the app and lock screen, and calls the methods that correspond to which delegate objects:

• App Launch and Active/inactive

As shown in the figure, when the app starts, it first switches from the not running state to the inactive state, at which point the Application:didfinishlaunchingwithoptions: method is called; The inactive state is then switched to the active state, at which point the Applicationdidbecomeactive: method is called.

When the app breaks, the active state switches to the inactive state, and the Applicationwillresignactive: method is called.

• Switch apps back and forth

As shown, when switching to another app, the state active switches to inactive, which calls Applicationwillresignactive: method, and then switches from inactive state to running state, This calls the Applicationdidenterbackground: method.

When switching back to the original app, the running state switches to the inactive state, at which point the Applicationwillenterforeground: method is called and then switched from the inactive state to the active state. Call Applicationdidbecomeactive: Method.

• Lock screen

How to do this, when the phone locks the screen, by the state active switch to inactive, this time call applicationwillresignactive:; and then switch from inactive state to running state, This calls the Applicationdidenterbackground: method.

For more information about app status switching and what to call app delegate, see the Session_320__adopting_multitasking_in_your_app video of the WWDC session.

termination of the application

The system is often launched for other apps because memory is not enough to reclaim memory and eventually need to terminate the application, but sometimes it will be due to the app for a long time to respond and terminate. If the app is running in the background and there is no pause, the system will call Applicationwillterminate before the application terminates: to save some important data for the user to revert to the app's original state the next time it starts.

Summary

This article summarizes what key objects are involved in iOS applications from start to finish, and when a user interacts with the system to generate an event, the system uses main run loop to manage the event loop, deciding which objects are to be handed over to the system and how to handle the event. And when the app launches, switches back and forth between the app and the lock screen, how the app's state switches and calls the corresponding app delegate objects to handle.

Extended Reading

• APP Programming Guide for IOS
• Developing IOS 7 App for IPhone and IPad
• Deep understanding of Runloop
• The realization principle of objective-c autorelease Pool

ios-deep parsing the life cycle of iOS apps