"iOS Application Architecture" discussion on the organization and invocation scheme of view layer notes collation

At the end of the busy period of time, the recent work has no task. Take the time to learn something while you work.

After reading Casa Taloyum's "iOS Application Architecture" on the view layer of the Organization and invocation scheme, written very carefully, very detailed, harvest quite abundant. Begin to sort out some of the knowledge that you can understand now.

First share: http://casatwy.com/iosying-yong-jia-gou-tan-viewceng-de-zu-zhi-he-diao-yong-fang-an.html

Code structure

First of all, we pay attention to the code structure and format, for the readability of the code and later maintainability, of course, only by this article, is not enough. We should also learn about the naming rules for variables and methods, etc., and recommend a book: Effctive objective-c 2.0. In addition, for a yard, every day face "a lump" like code and structure clear, well-formed code, which do you want? All right, no more wordy.

Directly on the code:

@interfaceViewcontroller ()#pragmaMark-propertys@property (nonatomic, strong) UIButton*custombtn;@end@implementationViewcontroller#pragmaMark-life cycle-(void) Viewdidload;- (void) Viewdidappear: (BOOL) animated;- (void) Viewwillappear: (BOOL) Animated, ... ..#pragmaMark-uitableviewdelegate.........#pragmaMark-customdelegate Or Otherdelegate.........#pragmaMark-event response.........#pragmaMark-private methods.........#pragmaMark-getters and Setters.........@end

Under detailed instructions:

1. All attributes use getter and setter

Do not initialize your view in Viewdidload and add again, so the code is hard to read. In viewdidload inside only do addsubview thing, then in viewwillappear inside do layout of things, finally in viewdidappear inside do notification monitoring things. As for the initialization of the property, it is given to the getter to do.

such as this:

#pragmaMark-life cycle-(void) viewdidload{[Super Viewdidload]; Self.view.backgroundColor=[Uicolor Whitecolor];    [Self.view AddSubview:self.firstTableView];    [Self.view AddSubview:self.secondTableView];    [Self.view AddSubview:self.firstFilterLabel];    [Self.view AddSubview:self.secondFilterLabel];    [Self.view AddSubview:self.cleanButton];    [Self.view AddSubview:self.originImageView];    [Self.view AddSubview:self.processedImageView];    [Self.view AddSubview:self.activityIndicator]; [Self.view AddSubview:self.takeImageButton];}- (void) Viewwillappear: (BOOL) animated{[Super viewwillappear:animated]; CGFloat width= (Self.view.width- -) /2.0f; Self.originImageView.size=cgsizemake (width, width); [Self.originimageview Topincontainer: -Shouldresize:no]; [Self.originimageview Leftincontainer:TenShouldresize:no]; Self.processedImageView.size=cgsizemake (width, width); [Self.processedimageview Right:TenFromView:self.originImageView];    [Self.processedimageview TopEqualToView:self.originImageView]; CGFloat labelwidth= Self.view.width- -; Self.firstFilterLabel.size= Cgsizemake (Labelwidth, -); [Self.firstfilterlabel Leftincontainer:TenShouldresize:no]; [Self.firstfilterlabel Top:TenFromView:self.originImageView]; ... ...}

This allows you to keep the code neat even when there are so many properties, and the initialization of the view is given to the getter. In short, try not to appear as follows:

-(void) viewdidload{    [Super Viewdidload];     = [[UILabel alloc] init];     = [Uicolor blackcolor];    Self.textlabel ...    Self.textlabel ...    Self.textlabel ... [Self.view AddSubview:self.textLabel];}

This practice is not clean enough, all thrown into the getter inside to be good.

2.getter and setter are all on the last

Because a viewcontroller is likely to have a lot of view, just like the code example given above, if the getter and setter are written in front, the main logic will be pulled back, while others will see a long string of getter and setter, That's not good. Then ask the business engineer to write the code in order to allocate the location of the code block, first, then then, then life cycle Delegate方法实现 , then event response getters and setters . This makes it much less effort to read the code later.

3. Each delegate the corresponding protocol name, delegate method do not write everywhere, write into an area inside

such as the Uitableviewdelegate method set on the honest writing #pragma mark - UITableViewDelegate . The advantage is that when someone reads a delegate implementation method that he is not familiar with, he just has to hold command and go to the protocol name, and Xcode can jump immediately to that part of the code that corresponds to the delegate protocol definition. It saves him from looking everywhere.

4.event response specifically open a code area

All button, Gesturerecognizer response events are placed in this area, not everywhere.

5. About private methods, under normal circumstances viewcontroller should not be written

Not the delegate method, not the event response method, not the life cycle method, is the private method. Right, under normal circumstances viewcontroller inside generally will not exist private methods, this private methods is generally used for date conversion, picture cut what this small function. This small feature either writes it as a category or makes it into a module, even if the module has only one function. Viewcontroller is basically the carrier of most of the business, its own code is quite complex, so the business associated with a small thing can not put in viewcontroller inside. Another point, this private method of the function is only for you to use, but in the future may also be used in other places, the first independent, for future code reuse

6. Why is this required?

Viewcontroller, code layout messy mess, here a delegate there a getter, and then Viewcontroller code generally die long, see let people headache. By defining this specification, you can make viewcontroller clear, and business programmers can distinguish between what is appropriate and what is inappropriate in Viewcontroller. In addition, it can improve the maintainability and readability of the code.

　　

"iOS Application Architecture" discussion on the organization and invocation scheme of view layer notes collation