Introduction to the general project directory structure and process for iOS application development in Xcode

Platform path required for the project
1. Development platform path:

/Developer/Platforms

There are generally three directories under this path, namely, mac computer, emulator, and iphone real machine

Each directory has a /Developer/usr/bin directory to place the programs required during development

The total directory is for example: /Developer/Platforms/*/Developer/usr/bin/

Note: * represents one of the previous directory above. Which one depends on the needs of the target platform

2. Emulator path:

/Developer/Platforms//Developer/Applications

There is an executable file with the emulator inside iPhone

path:

Real machine:

/Developer/Platforms//Developer/SDKs/iPhoneOS5.

Emulator:

/Developer/Platforms//Developer/SDKs/iPhoneSimulator5.

4. App path

Real machine:

/var/mobile/Applications/4434-4453A-B453-4ADF4535345ADAF344

The following directory 4434-4453A-B453-4ADF4535345ADAF344 is automatically generated by iPhone, and the files or directories inside include:

(1) App Directory

(2) Document Directory Documents

(3) Library Directory Library

(4) Temporary directory tmp

Documents directory, which can place user-save data and can be synchronized to iotic

Library directory, including: cache directory Caches, user preference directory Preferences (store .plist saved by NSUserDefaults)

Project directory structure and development process

Directory structure

AppDelegate
Models
Macro
General
Helpers
Vendors
Sections
Resources

A reasonable directory structure should first be clear, so that people can roughly understand the responsibilities of the directory at a glance and easily deal with new changes.

AppDelegate
The (.m) file placed in this directory is the entry file of the entire application, so it is taken out separately.

Models
This directory places some data-related Model files, which are roughly like this:

Models
  |- 
  |- 
  |- 
  |- 
  ...

Macro
This directory places the macro definitions that will be used in the entire application, which is roughly like this:

Macro
  |- 
  |- 
  |- 
  |- 
  ...

Put the macro definitions related to the app, such as:

Copy the codeThe code is as follows:

// Expression related

#define EMOTION_CACHE_PATH @"cachedemotions"

#define EMOTION_RECENT_USED @"recentusedemotions"

#define EMOTION_CATEGORIES @"categoryemotions"

#define EMOTION_TOPICS @"emotiontopics"

// Favorite related

#define COLLECT_CACHE_PATH @"collected"

// Picture related

#define WATERFALL_ITEM_HEIGHT_MAX 300

#define WATERFALL_ITEM_WIDTH 146

What is placed is the macro definition related to notifications.

There are some convenient macro definitions, such as:

Copy the codeThe code is as follows:

#define UIColorFromRGB(r,g,b) [UIColor \

colorWithRed:r/255.0 \

green:g/255.0 \

blue:b/255.0 alpha:1]

#define NSStringFromInt(intValue) [NSString stringWithFormat:@"%d",intValue]

Put some third-party constants in it, such as:

Copy the codeThe code is as follows:

#define UMENG_KEY @"xxxxx"

#define UMENG_CHANNEL_ID @"xxx"

If there is a new type of macro definition, you can create a new related one.

General
This directory will be reused Views/Classes and Categories. It's probably like this:

General
  |- Views
    |- TPKScollView
    |- TPKPullToRefresh
    ...
  |- Classes
    |- TPKBaseViewController
    |- TPKHorizontalView
    ...
  | - Categories
    |- UIViewController+Sizzle
    |- UIImageView+Downloader
    ...

Here TPK is the acronym for the project.

Helpers
This directory places some assistant classes, and the file name is linked to the function. It's probably like this:

Helpers
  |- TPKShareHelper
  |- TPDBHelper
  |- TPKEmotionHelper
  ...

The main function of the assistant class is to help the Controller lose weight, and can also provide a certain degree of reuse.

Vendors
This directory places third-party class libraries/SDKs, such as UMeng, WeiboSDK, WeixinSDK, etc.

Sections
The files under this directory correspond to the specific units of the app, such as navigation, waterfall flow, etc. It's probably like this:

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

Resources
This directory contains some resources that the app will use, mainly pictures.

Cocoapods
Business-independent class libraries can be easily managed through Cocoapods, such as SDWebImage, Reachability, etc. There are also some basic modules that multiple applications will use, such as HBAPI, HBSNS, HBFoundation (HB is the first letter of the company), etc. You can create a private git repo and add it to the podfile. In this way, if the HBAPI is updated, you only need to pod update.

By the way, HBFoundation can be used in this git repository. For example, many apps will have a alertView that asks for praise every once in a while, and you can write an HBRating class. In this way, apps that need to use this function only need to add a sentence: [HBRating checkIfShouldPopupWithAppID:(NSInteger)appID]. For example, apps all need to accept push notification, you can write an HBAPNS class, etc.

Development Process
After obtaining the design drawing, you can extract reusable Classes/Views/Helpers for the design drawing, consider the specific implementation of a certain effect, use appropriate design patterns to avoid a large number of if/else nesting, etc. Don't just drill into Sections to achieve page effects and functions. It may seem faster at first, but as long as projects with a little complexity, this approach will only suffer in the end, and the code will become increasingly difficult to maintain. Therefore, you must make sufficient preparations in the early stage.