Uiviewcontroller life cycle and iOS program execution sequence

 Uiviewcontroller life cycle and iOS program execution sequenceCategory: iOS development 2012-05-14 20:07 20828 People read Comments (3) favorite reports Iosuiviewhierarchyaccessorinterfaceapple

When a view controller is created and displayed on the screen. Code Execution Order
1, alloc                             &NBS P     Create object, allocate space
2, init (initwithnibname) Initialize object, initialize Data
3, Loadview             nbsp             loading views from nib, usually this step does not need to interfere. Unless you are not using the Xib file to create the View
4, viewdidload                   loading complete, You can customize the data and dynamically create additional controls
5, viewwillappear               The view will appear before the screen, and this view will be displayed on the screen immediately.
6, Viewdidappear               View rendered on screen

When a view is removed from the screen and the execution order is destroyed, the order is almost the opposite of the above
1. Viewwilldisappear view will be removed from the screen before execution
2, Viewdiddisappear view has been removed from the screen, the user can not see this view
3. Dealloc view is destroyed, you need to release the objects you created in Init and viewdidload

About Viewdidunload: In the event of a memory warning, if this view is not the view being displayed on the current screen, Viewdidunload will be executed and all child views of this view will be destroyed to free up memory, when developers need to manually viewload, The objects created in the Viewdidload free memory. Because when the view is displayed again on the screen, Viewload and viewdidload are called again to construct the view again.

When we create an object of the Uiviewcontroller class, it is common for the system to generate several default methods, most of which are related to the invocation of the view, but the order in which these methods are called when the view is called, needs to be sorted out.

Usually the above methods include the following, which are methods of the Uiviewcontroller class:

-(void) viewdidload;

-(void) viewdidunload;

-(void) Viewwillappear: (BOOL) animated;

-(void) Viewdidappear: (BOOL) animated;

-(void) Viewwilldisappear: (BOOL) animated;

-(void) Viewdiddisappear: (BOOL) animated;

The following describes the order in which the app is called at runtime.

1)-(void) viewdidload;

An app loads the view into memory first by invoking the Loadview method or by loading the initial interface created in IB. The Viewdidload method is then called to make further settings. In general, we have a lot of content of initial data loading, initial setting and so on, this method is implemented in this way, so this method is a very common, very important method.

Note, however, that this method will only be called once when the app starts to load and will not be called again, so it can only be used for initial setup.

2)-(void) viewdidunload;

In the case of sufficient memory, the view of the software is usually kept in memory, but if there is not enough memory, some viewcontroller that are not being displayed will receive a warning of insufficient memory and then release the view they own to achieve the purpose of freeing the memory. But the system only frees up memory and does not release ownership of the object, so usually we need to take ownership of objects that do not need to be kept in memory, that is, to set their pointer to nil.

This method is not usually called when the view is transformed, but only when the system exits or a memory warning is received. But since we need to make sure we can react to it when we receive a memory warning, this approach usually needs to be implemented.

In addition, even after the home key is pressed on the device, the system does not necessarily call this method, because after IOS4, the system allows the app to hang in the background and continue to be stuck in memory, so Viewcontroller does not call this method to clear the memory.

3)-(void) Viewwillappear: (BOOL) animated;

After the system loads all the data, the view is displayed on the screen, and this method is called first. We usually use this method to make further settings for the view that will be displayed. For example, we can use this method to set how the device will be displayed in different directions.

On the other hand, when the app has multiple views, switching between views does not load the Viewdidload method again, so if the data needs to be updated when the view is transferred, it can only be implemented within this method. So this method is also very common.

4)-(void) Viewdidappear: (BOOL) animated;

Sometimes, for some special reason, we cannot update the view in the Viewwillapper method. Then you can override this method to further set the view that is being displayed.

5)-(void) Viewwilldisappear: (BOOL) animated;

When the view is transformed, the current view is called when it is about to be removed or overwritten, and this method is invoked to handle and set up some aftercare.

Since after IOS4, the system allows the app to hang in the background, the system does not call this method after the home key is pressed, because the app itself, the view that the application displays, is still the view at the time of the hang, so this method is not called.

6)-(void) Viewdiddisappear: (BOOL) animated;

We can override this method and do some other work on the view that has disappeared, or is overwritten, or has been hidden.

The flowchart of the above method can be expressed simply as follows:

Run app-> load view, call the Viewdidload method, call the Viewwillappear method, call the Viewdidappear method, and run normally

aaaaaaaa                                                                                              a                                                                                 | 

aaaaaaaa                                                                                               |                                                                                 | 

aaaaaaaa                                                                                               |  Loading New view                                                             | 

aaaaaaaa                                                                                               |                                                                                 | 

aaaaaaaa                                                                                               |                                                                                 v

Release object ownership <-call Viewdidunload <-receive memory warning <-call Viewdiddisappear <-call Viewwilldisappear <-app need to call another view

iOS Program start execution order

http://www.yifeiyang.net/iphone-developer-advanced-3-iphone-application-startup-process/

The difference between IOS development Loadview and Viewdidload

These two methods are essential to the development of the iphone. They can all be used to initialize some content when the view is loaded. But what difference do they have?

Viewdidload This method is called only when view is initialized from the nib file.

Loadview This method is called when the controller's view is nil. This method is used when creating a view programmatically. Such as:

2. -(void) Loadview {
3. UIView *view = [[UIView alloc] initwithframe:[uiscreen
4. Mainscreen]. Applicationframe];
5. [View Setbackgroundcolor:_color];
6. Self.view = view;
7. [View release];
8. }

You implement the Loadview method in the controller, then you may be called by the memory management control at some point when the application is running. If the device is low on memory, the view controller receives a didreceivememorywarning message. The default implementation is to check whether the current controller's view is in use. If its view is not inside the view hierarchy currently in use and your controller implements the Loadview method, the view will be release and the Loadview method will be re-used to create a new view.

--------------------------------------------------------------------------------------------------------------- -----------------------------

Don ' t read Self.view In-loadview. Only set it, don ' t get it.

The Self.view property accessor calls -loadview if the view isn ' t currently loaded. There ' s your infinite recursion.

The usual-to-build the view programmatically in-loadview, as demonstrated in Apple ' s pre-interface-builder examples, Is more like this:

UIView   * view  =   [[ UIView alloc ] init ...];  ...  [ view addSubview : whatever ];  [ view addSubview : whatever2 ];  ...  self . view  = view ;  [ view release ];  

and I don ' t blame you to not using IB. I ' ve stuck with this method for all of Instapaper and find myself much more comfortable with it than dealing with IB ' s com Plexities, interface quirks, and unexpected behind-the-scenes behavior.

Uiviewcontroller life cycle and iOS program execution sequence