Of Stack

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

  • 2020-05-15 02:10:59
  • OfStack

The platform path required by the project
1. Development platform path: 


/Developer/Platforms

There are three directories under this path: mac computer, emulator, iphone real machine

MacOSX.platform iPhoneSimulator.platform iPhoneOS.platform Each directory has a /Developer/usr/bin directory to place the programs you need for development

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

Note: * represents one of the previous directories above, depending on the target platform's requirements

2. Simulator path: 


/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications

Inside is the simulator's executable file iPhone Simulator.app

3. sdk path:

True machine: 


/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk

The simulator: 


/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk

4. app path

True machine: 


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

The following directory 4434-4453es533-B4535345ADAF344 is automatically generated by iphone. The files or directories in it include:

(1) app directory test.app

(2) document directory Documents

(3) library directory Library

(4) temporary directory tmp

The Documents directory, which can hold user-saved data, can be synchronized to icould

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

Project directory structure and development process

The directory structure

AppDelegate Models Macro General Helpers Vendors Sections Resources

A reasonable directory structure should first be clear, giving a visual overview of the directory's responsibilities and making it easy to cope with new changes.

AppDelegate
Below this directory is the AppDelegate.h (.m) file, which is the entry file for the entire application, so pull it out separately.

Models
This directory contains a set of data related Model files, which look something like this: 


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


Macro
This directory contains the macro definitions that will be used throughout the application, and it looks something like this: 


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


AppMacro.h contains macro definitions for app, such as: 



//  Expressions related to 

#define EMOTION_CACHE_PATH @"cachedemotions"

#define EMOTION_RECENT_USED @"recentusedemotions"

#define EMOTION_CATEGORIES @"categoryemotions"

#define EMOTION_TOPICS @"emotiontopics"

 

//  Collect related 

#define COLLECT_CACHE_PATH @"collected"

 

//  Illustrated related 

#define WATERFALL_ITEM_HEIGHT_MAX 300

#define WATERFALL_ITEM_WIDTH 146

 

NotificationMacro.h contains macro definitions for notifications.

UtilsMacro.h contains some handy macro definitions, such as: 


#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]

VendorMacro.h contains some third square constants, such as: 


#define UMENG_KEY @"xxxxx"

#define UMENG_CHANNEL_ID @"xxx"

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

General
This directory holds Views/Classes and Categories that will be reused. It looks something like this: 


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

TPK here is an acronym for the project.

Helpers
This directory puts a number of helper classes, file names and functions. It looks something like this: 


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


The primary role of the helper class is to help slim down Controller, but it can also provide a degree of reuse.

Vendors
This directory houses the third side of the class library /SDK, such as UMeng, WeiboSDK, WeixinSDK, and so on.

Sections
The files under this directory correspond to specific units of app, such as navigation, waterfall flow, and so on. It looks something like this: 


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


Resources
Below this directory are the resources that app will use, mainly images.

Cocoapods
Business-neutral class libraries can be easily managed through Cocoapods, such as SDWebImage, Reachability, and so on. There are also some basic modules that can be used by multiple applications, such as HBAPI, HBSNS, HBFoundation (HB is the initial letter of the company), etc. You can build a private git repo, and then add it to podfile. In this way, if there is an update to HBAPI, only pod update1 is needed.

By the way, HBFoundation, the git repository, is a place where you can put small modules that you can use for almost any application you write. For example, many app will jump out of alertView every once in a while, so you can write a class HBRating, and then you can add a sentence to app that needs to use this function: [HBRating checkIfShouldPopupWithAppID:(NSInteger)appID]. For example, app needs to accept push notification, so you can write one HBAPNS class, and so on.

The development process
Once you have the blueprint, you can pull out the reusable Classes/Views/Helpers for the blueprint, consider the specific implementation of an effect in 1, use the appropriate design pattern to avoid a large number of if/else nesting, and so on. Don't just drill down to Sections to implement page effects and functionality. At first glance, it might seem like a little faster than that, but on projects with a bit of complexity, it can end up costing you a lot of money and making your code more and more difficult to maintain. So the early stage 1 must do the sufficient preparation work.

Related articles: