Questions about new IOS developers to be added

 

1. What is Prefix. pch used?

Is a tool to speed up compilation. Only header files that never change or rarely change can be added to prefix files. This allows the Framework Code to be compiled in advance and visible to all classes. However, if the header file added to the prefix file changes, all the code will be re-compiled, which is why only unchanged files can be added to the prefix file.

2. Why does if (self = [super init]) write this?

- (id) init{    if((self = [super init]))    {        //do init stuff here ...    }    return self;}

In the call of self = [super init], self is assigned the return value after the init message is sent to the parent object. If you were a C ++ programmer before, it would be very painful to see this scene. Don't be too frustrated. This line of code indicates that in Objective-C, the init method of the parent class must be manually called, and the modification operation will not be completed automatically. We use self to accept the returned value to prevent the returned value from being nil.

If you cannot fully understand how Objective-C programmers call [super init], another method may be easier to accept. This method is basically the same as the above method, but it is also different from the traditional method:

- (id) init{    self = [super init];    if(self != nil)    {        //do init stuff here ...    }    return self;}

3. Memory Management differences in current IOS versions

Versions earlier than iOS6.0

The viewDidUnload method is added to UIViewController. This method is paired with viewDIdLoad. When the system memory is insufficient, the didReceiveMemoryWarining method of UIViewController is called first, and didreceivemorywarining checks whether the view of the current ViewController is displayed on the window. If the view is not displayed on the window, didReceiveMemoryWarining will automatically destroy the viewcontroller view and all its sub-views, and then call the viewdidunload method of viewcontroller. If the current view of UIViewController is displayed on the window, the view of the viewcontroller will not be destroyed. Of course, viewDidunload will not be called.

Memory warning: Calling didReceiveMemoryWarning to call didreceivemorywarning of super will release the view of controller. Therefore, we cannot release the controller view again.
Solution:

-(Void) didReceiveMemoryWarning {[super didreceivemorywarning]; // if not displayed on the window, the self. view is automatically released. // Before ios6.0, you do not need to process it here. After self. view is released, the following viewDidUnload function will be called to process it in the viewDidUnload function .} -(Void) viewDidUnload {// Release any retained subviews of the main view. does not contain self. view [super viewDidUnload]; // handles some memory and resource issues .}

However, after IOS 6.0, there were some changes. The viewDidUnload with the IOS 6.0 memory warning was blocked, and the memory management method was back in IOS 6.0 and earlier versions.

Received memory warning: Calling didReceiveMemoryWarning to call didreceivemorywarning of super only releases the resouse of the controller and does not release the view.
Solution:

-(Void) didReceiveMemoryWarning {[super didreceivemorywarning]; // The self. view is not automatically released even if it is not displayed on the window. // Add code to clean up any of your own resources that are no longer necessary. // The ios6.0 macro switch must be added for compatibility processing to ensure that it is used under 6.0. The following code is blocked before 6.0. Otherwise, self will be used below. automatically load viewDidLoad if ([self. view window] = nil) // whether the view is in use {// Add code to preserve data stored in the views that might be // needed later. // Add code to clean up other strong references to the view in // the view hierarchy. self. view = nil; // The object is re-entered You can call the viewDidLoad function again. }}

 

4. Message scheduling @ selector

The @ selector (...) statement may be unfamiliar, which is used to specify a specific method in Objective-C. The key is that you must never forget the colon following the function! Colon tells Objective-C: "Find a party named XXX.
This method has only one parameter ". If you forget to write the colon, the compiler can still pass, but the program will crash once it is run. In the Debugger Console window, you will see the following error log: "unrecoginized
Selector sent to instance ...".

@ Selector (...) the number of colons must be the same as the number of specified method parameters. For example:

- (void) example:(ccTime)delta sender:(id)sender flag:(bool)aBool

Then, the corresponding @ selector statement should be:

@selector(example:sender:flag:);

Whether it is to use @ selector (...) in message scheduling or other situations (...), note a very important issue: by default, if the method name does not exist, the compiler will not report an error. However, once the program runs, the @ selector statement pointing to a non-existent method is called, the application will crash immediately. Because this call is completed internally, it is difficult to find the problem. Fortunately, xcode can be set to force the compiler to report an error.

 

5. # differences between import and @ class

1. import will contain all information about this class, including entity variables and methods, while @ class only tells the compiler that the name declared after it is the name of the class. As for how these classes are defined, don't worry about it for the moment. I will tell you later.

2. In the header file, you only need to know the name of the referenced class. You do not need to know its internal entity variables and methods. Therefore, in header files, @ class is generally used to declare this name as the class name. In the implementation class, because the internal object variables and methods of the referenced class are used, # import must be used to include the header file of the referenced class.

3. in terms of compilation efficiency, if you have 100 header files # imported the same header file, or these files are referenced in sequence, such as A-> B, B-> C, c-> D. When the header file at the beginning changes, all the classes that reference it later need to be re-compiled. If there are many classes, this will take a lot of time. Instead, @ class is not used.

4. if there is A circular dependency such as A-> B, B-> A, if # import is used to contain each other, A compilation error occurs, if @ class is used to declare each other in the header files of the two classes, no compilation error occurs.

Therefore, in general, @ class is placed in the interface, just to reference this class in the interface and use this class as a type. In the implementation class that implements this interface, if you need to reference the object variables or methods of this class, you still need to import the classes declared in @ class.