Turn: Awakefromnib/loadview/viewdidload Summary

Transferred from: http://blog.csdn.net/sxfcct/article/details/7840969

Each iOS developer is certainly familiar with Loadview and viewdidload, although the use of these two functions is really very simple, but similar to the initwithnibname/awakefromnib/ It's very confusing to put initwithcoder together.

First, Loadview

Never call this function actively. The view controller calls this function when the property of the view is requested and the current view value is nil . If you create a view manually, you should reload the function and do not invoke [super Loadview] when overloaded. If you create a view with IB and initialize the view controller, that means you use the Initwithnibname:bundle: method, and you should not overload the Loadview function.

The default implementation of This method system is this:

1. Find information about the available nib files, and then load the nib file with this information //So the nib loading process is done in Loadview.

2; If there is no information about the nib file, a blank UIView object is created by default, and the object is assigned to Viewcontroller's main view.

So, if you decide to overload this function, you should also complete these steps:

The view of the handle class is assigned to the View property (the view you create must be a unique instance and not shared by any other controller), and the function you overload should not call super. This is also to maintain a single mapping between the main view and the controller.

Second, Viewdidload

This function is called after the controller has loaded the relevant views, regardless of whether the views are stored in the nib file or generated in the Loadview function.

This function is primarily useful for you to further initialize your views. Viewdidload is usually responsible for the initialization of the view and its sub-view data after it is loaded into memory, that is, the initialization of the data part of the views. In iOS 3.0 and later, you should reload the Viewdidunload function to free any references to the view or content inside it (sub-view, and so on).

In most cases, it is the follow-up work of nib files.

Third, Viewdidunload

This function is the opposite function of viewdidload. in the absence of program memory, this function is called by the controller to release its view and view-related objects. since the controller usually holds a reference to the view and the associated object, you must use this function to discard the ownership of these objects for memory recycling. but do not release data that is difficult to reconstruct.

usually the controller saves a reference to the views created by the nib file, but it may also hold a reference to the object that the Loadview function creates . The perfect method is to use the Synthesizer method:

1	self.myCertainView = nil;

The synth will release the view, and if you don't use the property, you have to explicitly release the view yourself.

Iv. Conclusion

So the process should look like this:

Loadview to load the view (regardless of the nib file or custom views) to the memory-->viewdidload function to further initialize these views (typically focused on data initialization)-when memory is low, Call viewdidunload function to release views

-When you need to use view, go back to the first step

So loop

you need to clarify two concepts, create a class, and instantiate a class. Creating a class and instantiating a class in Xcode is easy to distinguish, but sometimes confusing in the case of IB (Interface Builder). In fact, it is also very well differentiated to create a nib file alone, and there is no direct or indirect relationship with other classes that can be instantiated, This class or class (a nib file may also contain multiple classes) is not an opportunity to be instantiated, so this only creates a class with IB, without instantiating it. A true instantiation also requires reading the nib file by using the code in Xcode. Knowing these two differences, these methods are easier to identify.

Viewdidload is actually nothing to be confused about, no matter what path to load (Xcode or IB, where the load is instantiated) after view will definitely execute this method.

Loadview need to be in two different situations. When you instantiate a class through Xcode, you need to implement this method in your controller. It is not necessary to instantiate in IB.

Initwithnibname This method is created in the Controller's class in IB, but is used when instantiating the controller through Xcode.

Initwithcoder is called when a class is created in IB but is instantiated in Xocdde. For example, create a controller's nib file with IB and then use Initwithnibname in Xcode to Instantiate this controller, then the controller's Initwithcoder will be called.

awakefromnib
When the. nib file is loaded, a awakefromnib message is sent to each object in the. nib file, and each object can define its own awakefromnib function to respond to the message and perform some necessary actions. That is, when you create a view object through the nib file, execution awakefromnib.awakefromnib is called before Loadview.

Viewdidload
The viewdidload is executed when the view object is loaded into memory, so creating the object either through the nib file or the code will execute viewdidload.

-(void) Loadview

Description creates the view that the controller manages.

You should never call this method directly. The view controller calls this method when the It view property is requested and is currently nil. This method loads or creates a view and assigns it to the View property.

If The view controller has a associated nib file, this method loads the view from the nib file. A view controller has an associated nib file if the Nibname property returns a Non-nil value, which occurs if the view con Troller is instantiated from a storyboard, if you explicitly assigned it a nib file using the InitWithNibName:bundle:met Hod, or if IOS finds a nib file in the app bundle with a name based on the View controller '?? S class name. If The view controller does not has an associated nib file, this method creates a plain UIView object instead.

If you use Interface Builder to create your views and initialize the view controller, you must not override this method.

You can override the This method in the order to create your views manually. If you choose to does so, assign the root view of your view hierarchy to the View property. The view you create should is unique instances and should not being shared with any other view controller object. Your Custom implementation of this method should is not a call super.

If you want to perform any additional initialization of your views, does so in the Viewdidload method.

-(void) viewdidload

Description called after the controller '?? s view is loaded into memory.

This method was called after the view Controller had loaded its view hierarchy into memory. This method is called regardless of whether the view hierarchy were loaded from a nib file or created programmatically in T He Loadview method. You usually override the This method to perform additional initialization on the "were loaded from nib files."

-(void) awakefromnib

Description prepares the receiver for service after it had been loaded from an Interface Builder archive, or nib file.

The nib-loading infrastructure sends an AWAKEFROMNIB message to all object recreated from a nib archive ll the objects in the archive has been loaded and initialized. When a object receives an awakefromnib message, it's guaranteed to has all its outlet and action connections already ES Tablished.

Must call the super implementation of awakefromnib to give, parent classes the opportunity to perform any additional in Itialization they require. Although the default implementation of this method does nothing, many UIKit classes provide NON-EMPTY implementations. The super implementation at any point during your own awakefromnib method.

Note:note

During Interface Builder ' s test mode, this message was also sent to objects instantiated from loaded Interface builder p Lug-ins. Because Plug-ins link against the framework containing the object definition code, Interface Builder is able-call their Awakefromnib method when present. The same is isn't true for custom objects, that's you create for your Xcode projects. Interface Builder knows only about the defined outlets and actions of those objects; It does not has access to the actual code for them.

During the instantiation process, each object in the archive is unarchived and then initialized with the method befitting Its type. Objects that conform to the Nscoding protocol (including all subclasses of UIView and Uiviewcontroller) is initialized us ing their initwithcoder:method. All objects this does not conform to the Nscoding protocol is initialized using their Init method. After all objects has been instantiated and initialized, the nib-loading code reestablishes the outlet and action Connect Ions for all of those objects. It then calls the Awakefromnib method of the objects. For more detailed information on the steps followed during the nib-loading process, see nib Files in Resource programmi Ng Guide.

Important:important

Because the order in which objects be instantiated from a archive is not guaranteed, your initialization methods should Not send messages to other objects in the hierarchy. Messages to other objects can is sent safely from within an awakefromnib method.

Typically, implement awakefromnib for objects that require additional set up that cannot is done at design time. For example, you might use the "this" method to customize the default configuration of any controls to match user preferences or The values in other controls. You might also with it to the restore individual controls to some previous state of your application.

Turn: Awakefromnib/loadview/viewdidload Summary