Memory management key:
viewDidUnload is only called if there is a low memory situation and your view is not the active view.
otherwise just calls dealloc.
For all view controllers simulate memory warning to test their handling
viewDidLoad v viewWillAppear: viewWillAppear is called multiple times, everytime the view comes back into view. For example
when a modal view is quit revealing the original view again.
These dynamic linking technologies have been superceeded in XCode3.0 and greater.
Dynamic linking provides a mechanism to share libraries. The standard C library may be used by most applications so statically linking, essentially compiling those functions into each individual application, is very inefficient.
To allow dynamic loading (often seen as .dyld) the compiler leaves library method calls as stubs. During application launch the dynamic loader parses the stubs and either replaces the stubs with libraries already in memory or loads the library as required. This extra overhead during launch takes time, so prebinding and zero link were devised to keep the benefits of dynamic linking but reduce launch time.
Prebinding involved pre-allocating memory addresses for libraries where each library author would define a memory address unique for that library. A prebound application using prebound libraries during link time would assume those addresses so at launch time all linking is done, resulting in a faster launch time. Since OS 10.3.4 the dynamic loader was optimised to the extent of being at least as fast as prebinding.
Zerolink approached the issue from a different angle. An application built with zerolink would only link enough to get the application off the ground. Only during runtime as unresolved symbols were found would linking occur, as required. Again the time saving involved is no longer beneficial due to the optimised dynamic loader.
In XCode3.0 and above there are still build options for Prebinding and Zerolink but they are ingnored. They are only present to allow sharing of projects with XCode 2.5.
For methods that return objects, the caller may or may not have responsibility to release the returned object.
Method names prefixed with ‘alloc’ ‘copy’ or ‘new’ must be released by the caller.
Objects returned by other method names return autoreleased objects.
Good idea to follow this convention!
Sending messages to a null object is safe in Objective-C; nice to know as I currently nearly always test for null before calling messages on objects. Could save complex testing for nested calls.
NSButton *button = nil;
[button setEnabled:YES]; // will do nothing rather than crash/cause exception