View life cycle

View is an important part of the application, the implementation of the function is closely related, and the view controller controls the view, its importance is self-evident throughout the application.

1. View life cycle and view Controller relationship

Based on the 4 states of the view, let's take a look at the life cycle of the view controller. In a different life cycle of the view, the view controller will callback different methods, as shown in 1.

Figure 1 Some of the main methods of the view controller

When the view controller has been instantiated and the view is loaded into memory, the Viewdidload method is called when the view does not appear. In this approach, it is common to initialize the controlled view.
Viewwillappear: Methods and Viewdidappear: methods are called before and after the view is visible, Viewwilldisappear: Methods and Viewdiddisappear: methods are called before and after the view is invisible. 4 methods call the corresponding method of the parent class to implement its function, the location of the method can be adjusted according to the actual situation when encoding, see the following code:

-(void) Viewwillappear: (BOOL) animated {     [Super Viewwillappear:yes];     

The Viewdidload method is called only once when the application is running, and the above 4 methods can be repeatedly called several times, they are widely used but also have a strong skill. For example, some applications use a gravity accelerometer, which constantly polls the device for real-time acceleration of gravity in the z-axis, x-axis, and y-axis direction of the device. Continuous polling is bound to consume a lot of power and thus affect battery life, we use these 4 methods to open or close the gravity accelerometer in a timely manner to achieve the purpose of saving electricity. How to use these 4 methods to achieve "timely" is a question worth thinking about.

In low memory situations, IOS calls Didreceivememorywarning: and Viewdidunload: Methods. After iOS 6, viewdidunload is no longer used: Only didreceivememorywarning is supported:. Didreceivememorywarning: The main function of the method is to free up memory, including some member variables in the view controller and the release of the view. Examples are as follows:

-(void) didreceivememorywarning {     Self.button = nil;     Self.mystringd = nil;      [MYSTRINGC release];    ARC Memory Management case not     [Super didreceivememorywarning];}

In addition to the above 5 method view controllers, there are many other methods.

2.iOS UI State Retention and recovery

The IOS design specification requires that when an app exits (including when it is terminated), it needs to maintain the state of the UI elements in the interface, and when it comes in again, the state is the same as when it exits. After iOS, Apple provides the following APIs to make it easy to maintain and restore your UI state.
In iOS, we can achieve state retention and recovery in the following 3 places:

? Application Delegate Object
? View Controller
? Custom View

The recovery identity is a setup item that iOS adds in order to implement UI state retention and recovery. We also need to make some changes in the application delegate object appdelegate Code section, adding the following code:

-(BOOL) Application: (UIApplication *) application shouldsaveapplicationstate:     (Nscoder *) Coder {     return YES;}  -(BOOL) Application: (UIApplication *) application shouldrestoreapplicationstate:     (Nscoder *) Coder {     return YES; }  -(void) Application: (UIApplication *) application Willencoderestorablestatewithcoder:     (Nscoder *) Coder {     [Coder encodefloat:2.0 forkey:@ "Version"];}  -(void) Application: (UIApplication *) application Diddecoderestorablestatewithcoder:     (Nscoder *) Coder {     float lastver = [coder decodefloatforkey:@ "Version"];     

　

Where the Application:shouldsaveapplicationstate: method is called when the application exits, is responsible for controlling whether the state is allowed to be saved, returns Yes if the condition can be saved, no is not saved.
Application:shouldrestoreapplicationstate: The method is called at application startup and is responsible for controlling whether the state of the last exit was resumed, yes indicates recoverable, and no indicates that no recovery is possible.
Application:willencoderestorablestatewithcoder: Method is called at save time, which implements UI state or data saving, where [coder encodefloat:2.0 forkey:@ " The Version "] statement is to save simple data.
Application:diddecoderestorablestatewithcoder: The method is called at restore time to implement UI state or data recovery in this method, where [coder decodefloatforkey:@ "Version" ] Statement to restore the last saved data.
To implement the hold and restore of controls in a specific interface, you also need to add some code to its view controller. The code we added in VIEWCONTROLLER.M is as follows:

-(void) Encoderestorablestatewithcoder: (Nscoder *) coder{     [Super Encoderestorablestatewithcoder:coder];     [Coder EncodeObject:self.txtField.text Forkey:ksavekey]; }  -(void) Decoderestorablestatewithcoder: (Nscoder *) coder {     [super Decoderestorablestatewithcoder:coder];     

After iOS 6, the view controller has added two methods--encoderestorablestatewithcoder: and Decoderestorablestatewithcoder: To implement the Save and restore of controls or data in the controller. Where Encoderestorablestatewithcoder: method is called at save time, [coder encodeobject:self. TxtField.textforKey:kSaveKey] The Decoderestorablestatewithcoder statement saves the contents of the text box according to the specified key, which is called when the method is resumed, and [coder Decodeobjectforkey:ksavekey] is called when the contents of the text box are restored. Saving and restoring is actually the process of encoding and decoding an archive file.

　

View life cycle