Best practices for iOS Application Design

• Always remember the life cycle of views

Do not access self. View in the init Method

Use Data Source protocols (Data Source Protocol) to clearly distinguish data from the View

• Uiviewcontroller

Use an existing navigationitem object

• Nsobject

Expose only public attributes and methods in the header file

• Debugging

Use lldb for testing

Use nszombieenabled to detect memory leakage

Bytes -----------------------------------------------------------------------------------------------------------------------

Always remember the life cycle of views

Keep reminding yourself that your view may be destroyed at any time

(1) do not access self. View in the init Method

You should never access self. View in your controller's init method. This will always lead to many bugs that are difficult to debug, because after receiving a memory warning, the init logic cannot be executed again.

Consider the following simple example:

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {  if ((self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil])) {    self.view.backgroundColor = [UIColor underPageBackgroundColor];  }  return self;}

Imagine that the controller is the root object of a navigation stack (Note: The stack structure is used in IOS to manage view objects related to navigationcontroller, at the same time, a memory warning occurs (if the memory warning is not properly handled, the IOS system will destroy some views to release the memory space ). When we return to the Controller, the view no longer uses underpagebackgroundcolor as its background color. This can cause debugging troubles, even for experienced IOS engineers.

(2) Use Data Source protocols (Data Source Protocol) to clearly distinguish data from views

When you are designing a view to interact with a dataset, you should always use a data source protocol to obtain data, rather than exposing the accessors (setter. Views are not containers of data, so they should not be put under such "Guilt ". The correct approach is that the view should be regarded as an extensible component with no sense of presence at any time.

As a general rule, any information beyond the static display in the view should be obtained through data source or delegate.

Uilabel is a view without datasource. It is a good example. All its attributes are usually set once, and they are not expected to be changed during the life cycle of the view.

On the other hand, uitableview is a good example that requires data source to extract data. Let's imagine what it will look like when we use uitableview instead of using a datasource but just providing a setter.

If such a design is true, developers attempt to use table view objects to store their data, which will inevitably lead to misuse. When a memory warning is received and table view is inevitably released, the data also disappears (because it is stored inside the tableview object through setter ). This means that the data we need to store can be accessed by multiple instances of North table view in any situation within its lifecycle.

Uiviewcontroller

View controller is used to bind a model to a view.

(1) use an existing navigation item object

Each instance of uiviewcontroller has a navigationitem attribute, which should be used to specify the left/right navigation buttons and the title view. You should not create a uinavigationitem object, because when you access self. navigationitem, the basic class implementation of uiviewcontroller will automatically create one for you. Use self. navigationitem to access and Set Properties for it:

// UIViewController will automatically create the navigationItem object.self.navigationItem.rightBarButtonItem = doneButton;

Nsobject

(1) only public attributes and methods are exposed in the header file.

OBJ-C allows you to define private attributes in a category interface (. M file. Use this feature to provide better access restrictions.

This is equivalent to defining through @ provate and brings some additional benefits-modifications to the Code do not need to be re-compiled and do not affect the internal structure of other objects. This is of great benefit in a large project.

Example:

Viewcontroller. h

@interface ViewController : UIViewController@property (nonatomic, readonly, assign) NSInteger objectId;@end

Viewcontroller. m

#import "ViewController.h"@interface ViewController()@property (nonatomic, readwrite, assign) NSInteger objectId;// Notice that this property doesn't need to be in the .h. Objective-C will create this// property on the fly!@property (nonatomic, readwrite, retain) UILabel* objectLabel;@end@implementation ViewController@synthesize objectId;@synthesize objectLabel;...@end

Debugging

(1) Use lldb for testing

Lldb allows you to check the attributes of a class and does not need to be explicitly defined on the instance of the object.

(2) Use nszombieenabled to detect memory leakage

When nszombieenabled is used, all objects released from the memory will be saved as "Zombies ". If you attempt to access these released objects again at a certain time in the future. This will help you determine where memory leakage occurs.

(Note: please google the configurations of the two debugs on your own)