iOS project directory structure and development process

Source: http://mobile.51cto.com/hot-431205.htm

There are few resources on the Internet for iOS projects, and the open source and good quality of iOS projects are few and far between, and recently I've been working with colleagues on an iOS project to say some of their ideas. A reasonable directory structure should first be clear, giving people a glimpse of the responsibilities of the catalog and the ability to respond to new changes.

AD:WOT2014 Course Recommendation: Actual combat MSA: using open source software to build micro-service system

There are few resources on the Internet for iOS projects, and the open source and good quality of iOS projects are few and far between, and recently I've been working with colleagues on an iOS project to say some of their ideas.

Directory structure

Appdelegatemodelsmacrogeneralhelpersvendorssectionsresources

A reasonable directory structure should first be clear, giving people a glimpse of the responsibilities of the catalog and the ability to respond to new changes.

Appdelegate

This directory is a AppDelegate.h (. m) file, which is the entry file for the entire application, so take it out separately.

Models

This directory has a number of data-related model files, presumably:

Models    |-BaseModel.h    |-basemodel.m    |-CollectionModel.h |-    collectionmodel.m    ...

Macro

This directory gives the macro definition used by the entire application, presumably:

Macro    |-AppMacro.h    |-NotificationMacro.h    |-VendorMacro.h |-    UtilsMacro.h    ...

AppMacro.h app-related macro definitions, such as:

Expression-related

1. #define Emotion_cache_path @ "Cachedemotions"  
2. #define Emotion_recent_used @ "Recentusedemotions"  
3. #define Emotion_categories @ "Categoryemotions"  
4. #define Emotion_topics @ "Emotiontopics"  

Collection related

#define Collect_cache_path @ "collected"

Mapping related

#define WATERFALL_ITEM_HEIGHT_MAX 300#define Waterfall_item_width 146

The NotificationMacro.h is a notification-related macro definition.

In UtilsMacro.h, there are some handy macro definitions, such as:

1. #define UICOLORFROMRGB (r,g,b) [Uicolor \
2. colorwithred:r/255.0 \
3. green:g/255.0 \
4. blue:b/255.0 Alpha:1]
6. #define NSSTRINGFROMINT (intvalue) [NSString stringwithformat:@ "%d", Intvalue]  

VendorMacro.h Some third-party constants, such as:

1. #define Umeng_key @ "xxxxx"  
2. #define UMENG_CHANNEL_ID @ "XXX"  

If you have a new type of macro definition, you can create a new related Macro.h.

General

This directory will be reused by views/classes and categories. It's probably like this:

General |-Views |-        tpkscollview        |-Tpkpulltorefresh    | -Classes    |-Tpkbaseviewcontroller-Tpkhorizontalview ... |-Categories |-        uiviewcontroller+ Sizzle        |-Uiimageview+downloader ...        

The TPK here is the acronym for the project.

Helpers

This directory puts in some helper classes, with filenames linked to functionality. It's probably like this:

Helpers    |-Tpksharehelper    |-Tpdbhelper    |-Tpkemotionhelper    ...

The main role of helper classes is to help controllers to slim down, but also to provide some degree of reuse.

Vendors

This directory puts third-party class libraries/sdk, such as Umeng, WEIBOSDK, WEIXINSDK, and so on.

Sections

The following files in this directory correspond to the specific elements of the app, such as navigation, waterfall flow, and so on. It's probably like this:

Sections    |-Menu    |-Setting    |-Collection    ...

Resources

This directory is a list of resources that the app will use, mostly pictures.

Cocoapods

Business-agnostic class libraries can be conveniently managed through Cocoapods, such as Sdwebimage, reachability, and more. There are also a number of applications will use the basic module, such as Hbapi, Hbsns, Hbfoundation (HB for the company first letter) and so on, you can build a private git repo, and then add to Podfile, so if the Hbapi is updated, only need pod Just update it, please.

By the way, hbfoundation, this git repository can put in some of the small modules that all the apps you write are basically going to use. If a lot of apps will jump out of a alertview for a while, you can write a hbrating class, so the app that needs to use this feature simply adds: [Hbrating checkifshouldpopupwithappid: ( Nsinteger) AppID] on the line. Another example is that the app has the need to accept push notification, can write a Hbapns class, and so on.

Development process

After getting the design diagram, you can draw out the reusable classes/views/helpers for the design diagram, consider the specific implementation of an effect, use the appropriate design pattern to avoid a large number of if/else nesting, and so on. Do not drill into the sections in a flash to achieve the page effect and function, it may seem faster at first, but as long as the complexity of the project, this approach will only eat the pain later, the code will become more and more difficult to maintain. So we must do a good job in the preparatory work.