iOS Project management: directory structure and development process
Recently doing a large version of the update, now in the refactoring .... Found that many people at the beginning of a project do not know what the development process is, nor is it very clear that a project should have a directory structure. If the project is small or in the first version of the time can be able to cope with, but once more difficult than the update. The reason is that at the beginning of your project a reasonable directory structure, without a system management. After a long time, many kinds of confused.
directory StructureAppdelegatemodelsmacrogeneralhelpersUtilsSectionsresources 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.
appdelegateThis directory is a AppDelegate.h (. m) file, which is the entry file for the entire application, so take it out separately.
ModelsThis directory has a number of data-related model files, presumably: Models |-BaseModel.h |-basemodel.m |-CollectionModel.h |-COLLECTIONMODEL.M ...
MacroThis directory gives the macro definition used by the entire application, which is probably: macro |-AppMacro.h |-NotificationMacro.h |-VendorMacro.h |
AppMacro.h App-related macro definitions, such as:Expression-related # define Emotion_cache_path @ "cachedemotions" #define emotion_recent_used @ "recentusedemotions" #define Emotion_ CATEGORIES @ "categoryemotions" #define Emotion_topics @ "Emotiontopics"//Favorites Related # define Collect_cache_path @ "collected"/ /Map 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:#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 Some third-party constants, such as:#define Umeng_key @ "xxxxx" #define UMENG_CHANNEL_ID @ "XXX" If there is a new type of macro definition, you can create a new related Macro.h.
GeneralThis 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.
HelpersThis 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. Utils This directory puts third-party class libraries/sdk, such as Umeng, WEIBOSDK, WEIXINSDK, and so on.
SectionsThe 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 ...
ResourcesThis directory is a list of resources that the app will use, mostly pictures.
CocoapodsBusiness-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 ProcessAfter 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 to achieve the page effect and function. It may seem like a little faster at first, but as long as it's a bit of a complex project, it's only going to suffer later, and the code becomes harder to maintain. So we must do a good job in the preparatory work. Experience is limited, if you have a better idea, welcome to exchange:)Read (515)| Comments (0)
iOS project management: directory structure and development process
