iOS Development tips (GO)

subclassing Inheritance/Sub-classMost languages allow the developer to subclass the classes provided by the framework, but not entirely in objective-c. Most commonly used classes, such as Nsarray, Nsset, and Nsdictionary, are basically collection types. Inheriting these classes is not recommended unless you are ready to forward the call or implement all the necessary original methods. In traditional development languages, it is common to add methods by inheriting the underlying types (classes like Nsarray), overloading existing methods, or customizing the appearance of UI components. In Objective-c, the new method is generally extended by Category. The implementation provided by the SDK is overloaded with a hybrid approach (swizzling the method). and the appearance-related agent Protocol (PROTOCOL) to customize the appearance of the UI component. Nevertheless, there are some classes that often inherit them, such as Uiviewcontroller, Uitableviewcontroller, Uicontrol, and so on. Inheriting Uiviewcontroller is probably the best thing to do in the development process, because it makes adding common functionality incredibly simple. In every App I've developed, there's a subclass that inherits from Uiviewcontroller, which implements a common set of methods. All other View Controllers are inherited from this base class. (Translator Note: In WEB development there is often a basecontroller to be inherited to provide public methods, it seems that development is comprehend by analogy, to think more) so, the following inheritance methods:

1. @ Interface Myappfeaturedyoutubevideosviewcontroller:uiviewcontroller

Should be replaced by:

1. @ Interface Myappfeaturedyoutubevideosfeaturedviewcontroller:myappviewcontroller
2. @Interface Myappviewcontroller:uiviewcontroller

This common base class can be used to add common methods during the subsequent development process. In this base parent class, I usually declare the following methods:

1. -(uiview*) Errorview;
2. -(uiview*) Loadingview;
3. -(void) showloadinganimated: (BOOL) animated;
4. -(void) hideloadingviewanimated: (BOOL) animated;
5. -(void) showerrorviewanimated: (BOOL) animated;
6. -(void) hideerrorviewanimated: (BOOL) animated;

The implementation is as follows:

-(uiview*) Errorview {returnNil;} -(uiview*) Loadingview {returnNil;} -(void) showloadinganimated: (BOOL) animated {UIView*loadingview =[self loadingview]; Loadingview.alpha=0.0f;   [Self.view Addsubview:loadingview];     [Self.view Bringsubviewtofront:loadingview]; DoubleDuration = animated?0.4f:0.0f; [UIView animatewithduration:duration animations:^{Loadingview.alpha=1.0f; }]; }   -(void) hideloadingviewanimated: (BOOL) animated {UIView*loadingview =[self loadingview]; DoubleDuration = animated?0.4f:0.0f; [UIView animatewithduration:duration animations:^{Loadingview.alpha=0.0f; } Completion:^(BOOL finished) {[Loadingview Removefromsuperview]; }]; }   -(void) showerrorviewanimated: (BOOL) animated {UIView*errorview =[self errorview]; Errorview.alpha=0.0f;   [Self.view Addsubview:errorview];     [Self.view Bringsubviewtofront:errorview]; DoubleDuration = animated?0.4f:0.0f; [UIView animatewithduration:duration animations:^{Errorview.alpha=1.0f; }]; }   -(void) hideerrorviewanimated: (BOOL) animated {UIView*errorview =[self errorview]; DoubleDuration = animated?0.4f:0.0f; [UIView animatewithduration:duration animations:^{Errorview.alpha=0.0f; } Completion:^(BOOL finished) {[Errorview Removefromsuperview]; }]; } 

Now, in every view Controller in the APP, it's easy to change the state of the current view to Loading or Error by calling the above method. Also, View controllers can provide custom error interfaces and Loading interfaces by overloading the-errorview and-loadingview methods. You can also uniformly modify the performance of all View by overloading the-viewdidload in this base class. For example, add the same background image or color for all views:

-(void) viewdidload {   [super Viewdidload];    // }  

UI Customization Custom UICustom UI can be broadly divided into two categories, one custom control and the other skin/theme. The former can make apps better, and the latter is what most apps need. I recommend writing Category extensions for Uifont and Uicolor to provide custom fonts and custom colors. For example, add the following method to Uifont:

1. + (uifont*) Appfontofsize: (cgfloat) pointsize {     return [uifont fontwithname:@ "  Myriadpro-regular"size:pointsize"  ;}    + (uifont*) Boldappfontofsize: (cgfloat) pointsize {     return [uifont fontwithname:@ "  myriadpro-black"

You can easily use [Uifont appfontofsize:13] to get myriadpro-regular fonts. This way, when your design needs change, you can quickly change the font in your entire App. The same design pattern can be applied to custom colors as well. Add the following methods to Uicolor:

1.   #define  GREY (color) [Uicolor colorwithred:color/255.0 Green:color /255.0 blue:color/255.0 Alpha:1] + (Uicolor*) appbackgroundcolor { @ " Span style= "Color:rgb (128, 0, 0); >bgpattern   " ]];}  + (Uicolor*    return  GREY (38  );  + (Uicolor* return   GREY (234  ); 

so don't use Interface Builder to choose colors. subclassing Uilabels Inheritance UILabel also has a little trick when developers inherit UILabel, Uitextfield, and Uitextview, usually in-initwithframe: and-initwithcoder: Method To set the font and color, see the following code:

1. @implementationAppprefixlabel-(void) Setup {Self.font= [Uifont fontwithname:@"Sourcesanspro-semibold"Size:self.font.pointSize]; Self.textcolor=[Uicolor Redcolor];} -(ID) initWithFrame: (CGRect) Frame {if(self =[Super Initwithframe:frame]))   {[Self setup]; }     returnSelf ;} -(ID) Initwithcoder: (Nscoder *) Adecoder {if(self =[Super Initwithcoder:adecoder]))   {[Self setup]; }     returnSelf ;} @end 

This technique allows developers to customize the appearance of these elements in Interface Builder. Drag a UILabel into IB, and modify its class to be your own custom class, instantly complete the Label font and color customization without any extra code. This technique works well in most cases, but when your App supports custom themes and users can change the theme by setting the interface, it's a bit of a hassle. -initwithframe: And Initwithcoder: will be called when the UI component is created, so if you want to change the font and color after that, you'll need a lot of extra code. So if your App supports themes, write a global singleton of the theme manager to provide global themes, fonts, colors. If you use the first method I said, your Uifont Category can now be implemented as follows:

1. + (uifont*) Appfontofsize: (cgfloat) pointsize {     *currentfontname = [[ThemeProvider sharedinstance] Currentfontname];    return

Uicolor. In fact there is no correct or wrong method, the above method is feasible. By following the design patterns mentioned here, you can make your code clean as well as a beautifully written js/css. Try using these methods in your next project. Allen PostScriptBefore thinking about whether iOS development needs a so-called framework like WEB development, but gradually found that the iOS SDK is a highly encapsulated framework, perhaps we need not a more high-level framework, but a good design patterns, development habits and code structure. So is it possible to write a clean framework from a Project level and define some specifications as a good "framework"? Instead of having to provide Router and the like to lean toward the WEB development framework.