IOS Loadview and issues that are noted in initializing view in Loadview. (Dead loops are not scary)

After Xcode 4.2, I basically do not use xib files, although the Xib file has a lot of fun, can quickly code-building windows, can reduce a lot of code to build the trouble, in fact, can use xib or good, mainly my machine open xib to edit too slow, run, Antique machines, so don't like xib (personal reasons). Some people say that Xib will make the code run slow, really? Theoretically, the app will run, read the Info.plist file first, then find the MainWindow xib, and then interpret the code in Xib to evolve into OC code for instantiation. With regular code constructs, the direct use code without translating the data in the Xib, save a step, perhaps this is the reason for it. OK, this first don't discuss, back to Loadview, each VC (Viewcontroller) will generate a Loadview method, of course, in many cases not in this method to write windows, but in the viewdidload to write. Let's look at the trigger conditions for the Loadview call.

APP runs, first run Init and then run

 -  (ID) initwithnibname: (nsstring *) Nibnameornil bundle: (nsbundle *) Nibbundleornil To find out if there are no view views in Xib. If there is, then no longer go loadview. If this time your VC is no xib, which is obviously after this method, is not found any view, that is, Self.view is still nil. Then, run Loadview, this time will be triggered, if in Loadview, do nothing, also do not instantiate a view. The program continues to run into the viewdidload, if there is still no materialized view. There is no window on this VC. There is a lot of time here when there will be a misunderstanding   (dead loop).    Well, let's explain the conditions of the dead loop.  1, no xib. 2, Viewcontroller in the Loadview method does not do any instantiation self.view operation. such as:-(Void) loadview{wrote a lot of code, but it's best not to do one of the following two ways. Mode one: Use [supper loadview] when instantiating;                   //Mode II: Self.view = [UIView alloc] ....    &N Bsp;  }3, Self.view was called in Viewdidload.   As long as these three conditions are met at the same time, must die cycle. The way a moment, called [Supper Loadview] This time by the parent class produced a (0,20,width,height). The width and height are based on the ipad, or the iphone is different, but the origin coordinates must be (0,20) to remove the status bar. Mode two, does not have any assignable value to Self.view, so makes self.view = nil; In the case of condition two satisfies, the program runs to step three, this time, if the self is called here. View. Because self. View is empty in step two, so it's back to Loadview. But because Loadview did not instantiate Self.view, so after running the Loadview, and continue to run viewdidload, but because viewdidload in the case of no instantiation, the self is used. View. So there is a phenomenon that will be called back and forth now.   Well, know how to victorious. Resolve the dead loop.   In step two, the processing method has three: A, the entire-(void) Loadview shield off. Let the parent class create a view for themselves. This is the most common, because when Viewcontroller is generated, the code is commented out in the default code. b, add a sentence in the Loadview [Supper Loadview]; Personally, it is not advisable to write this, of course, if you understand the relationship between the view, it does not matter. C, in Loadview, use the materialized view to assign a value to the Self.view. Note: The add operation crashes by using the = sign instead of using [Self.view Addsubview] because Self.view is a null pointer at this point.   In addition, you can also start in step three, even if there is no materialized view in step two, but in step three, the corresponding instantiation operation can still be resolved. This is usually why we do not open-loadview comments, but directly in the Viewdidload to add the window.    OK, the above dead loop has been introduced, by the way, using the following two methods to instantiate the window to note the place.  1, [[Uiscreen mainscreen] bounds]     The returned rect is the size (0,0) of the coordinate origin, which includes the status bar.  
2, [[UIScreen Mainscreen]applicationframe] The returned rect is (0,20) the size of the coordinate point, excluding the status bar. The view generated by [supper Loadview] is usually generated by this. If in Loadview, call [supper loadview]; or use Self.view =[[[UIView alloc]initwithframe:[[uiscreen Mainscreen] Applicationframe]]autorelease]; This allows you to use addsubview between the parent and child layers, and you will see a cascade window with an offset of 20. The reason is that the origin of the rect returned by both methods is (0,20);D emo:a Viewcontroller-(void) Loadview
{
[Super Loadview];
Self.view = [[[UIView alloc] Initwithframe:[[uiscreen Mainscreen]applicationframe]] autorelease];

Self.view = [[UIView alloc]initwithframe:cgrectmake (0, 0, 200, 400)];

Self.view.backgroundColor = [Uicolor Greencolor];

BVC *BVC = [[BVC alloc]init];
NSLog (@ "BVC View%@", Bvc.view);
[Self.view AddSubview:bvc.view];

} B Viewcontroller in-(void) Loadview
{

[Super Loadview];
Self.view = [[[UIView alloc] Initwithframe:[[uiscreen Mainscreen]applicationframe]] autorelease];
Self.view = [[UIView alloc]initwithframe:cgrectmake (0, 0, 200, 400)];

Self.view.backgroundColor = [Uicolor Redcolor];

CVC *CVC = [CVC alloc]init];
[Self.view AddSubview:cvc.view];

} c Viewcontroller in-(void) Loadview
{
[Super Loadview];
Self.view = [[[UIView alloc] Initwithframe:[[uiscreen Mainscreen]applicationframe]] autorelease];
Self.view = [[UIView alloc]initwithframe:cgrectmake (0, 0, 100, 300)];

Self.view.backgroundColor = [Uicolor Bluecolor];
Last run Effect: If you want the child view to directly cover the size of the parent view, you can use [[UIScreen mainscreen] bounds] or specify the origin when instantiating directly with UIView. That's it, hope it helps you.

IOS Loadview and issues that are noted in initializing view in Loadview. (Dead loops are not scary)