Re: Headers in folder references
Re: Headers in folder references
- Subject: Re: Headers in folder references
- From: Andreas Grosam <email@hidden>
- Date: Tue, 31 Jul 2012 10:02:44 +0200
On 30.07.2012, at 22:25, Rick Mann wrote:
>
> On Jul 30, 2012, at 3:18 , Andreas Grosam <email@hidden> wrote:
>
>> You better should not dislike it :) In fact, this is the method to get your header path issues solved. Otherwise, your headers seem to appear in a flat namespace - calls for trouble in a more complex project.
>
> I don't like having to set header search paths for files already IN the project. This means there are two independent parts of the UI that can get out of sync. If I move a file in the project, I have to remember what impact that might have on the header paths I've set in the build settings.
Setting a header search path manually is not that cumbersome as you might think. The search paths settings are NOT independent, instead *your* build settings will have *precedence* to the paths set by Xcode. What you gain is "structure", better readability of your code and conflict free import of headers (example below).
In a more complex (iOS) application, you should give your code a meaningful structure anyway, that is you should logically divide your sources into folders and subfolders. My personal preference is to group "features", that is, I put (almost) everything into one subfolder that constitutes for example the feature "User". This includes views, controllers, resources, and possibly models (CoreData managed object classes) - instead of putting controllers to a "Controllers" folder, resources into a "Resources" folder and so on - or even putting everything into the "Classes" folder as it is the default.
There are many ways to structure your code, for several reasons: helper classes, base classes, libraries, etc.
You should just utilize the structure and reflect that in your code - *and* in your import directives as well! The reason is obvious once you compare a big project with say more than 300 files where almost all sources are put into one folder and one that logically subdivided it into a reasonable folder hierarchy.
A contrived example:
File hierarchy on disk. Your project's group hierarchy should have similar structure - possibly even more "fine grained":
MyApp
|-Libraries
|- json
...
|- Sources
| OriginAPI
JsonRequest.h/m
JsonRequestFuture.h/m
OriginModel.m/h
...
|- Utility
ASArray+MyCategory.h/m
base64.c/h
...
|- ControllerCommon
BaseTableViewController.h/m
BaseUpdateViewController.h/m
BaseCreateViewController.h/m
...
|- User
User.h/m
UsersViewController.h/m
UserTableViewCell.h/m
CreateUserViewController.h/m
UpdateUserViewController.h/m
time.h/time.c
...
|- Message
Message.h/m
MessagesViewController.h/m
MessageTableViewCell.h/m
CreateMessageViewController.h/m
UpdateMessageViewController.h/m
...
|- OtherObject
OtherObject.h/m
OtherObjectsViewController.h/m
...
|- Resources
|- Supporting Files
Now, suppose you just defined ONE header search path manually:
$(SRCROOT)/MyApp/Sources
Now, again a contrived example, you can import several headers with a *qualified* import directive as shown below:
// File: UserTableViewController.m"
#import "UserTableViewController.h"
#import "ControllerCommon/BaseTableViewController."
#import "Models/User.h"
#import "Utility/base64.h
#import "UserTableViewCell.h"
#import "OriginAPI/JsonRequest.h"
#import "OriginAPI/JsonRequestFuture.h"
#include "time.h" // includes file "time.h" from the same folder!
Andreas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden