Is there a “best practice” for Organization in Xco

问题:

I'm coming from the java world, where files/classes should be layed out well structured within packages/folders in my understanding.

What is the best practice in Xcode4? I couldn't find an Apple guideline for this yet. If anyone can push me to the right document, I'd be happy.

In case there is no document: what is the best to do so? I find it a bit odd to have all of the Classes in one project folder - either inside the Xcode-view or the file structure (strangely filestructure doesn't seem to equal the visual structure in Xcode). Of course the project will be on version-control (on GitHub).

Many thanks in advance!

回答1:

First of all, I like to have categories of fire controllers and related classes grouped. But not just in groups created in XCode, in real folders too. So, when creating a group instead of creating it in XCode created it in Finder first, then drag that folder into XCode and have it formed into a group. Now when you add new files in that group they will also go into that folder on disk.

Some other random thoughts:

Naming: since you don't have namespaces, you must prefix your classes with a two or three-letter prefix (Apple recommends three). Do this even if it seems odd at first.

Resources: The default projects like to separate xib files from view controllers. In an app of any size, I greatly prefer to keep view controllers and xib files grouped in one location. You could even do images this way though generally there are few enough it's easier just to group those in one place.

Application stuff: I like to group all of the miscellaneous application specific files (app delegate, info.plist, pch file, main.m, etc) in one Application group at the top of the list to make those bits easy to find.

回答2:

First of all, take a look at the default project structure. While it's not perfect, there are some default "Groups" in Xcode. Use those as a general guideline. (As you mentioned, Groups are not file system folders, although when you import resources you are prompted with the option to make groups for folders.)

While there's not much official convention regarding the structuring of files, there are some things you can do, like I do, to scratch that organizational itch. I make a few subfolders in my project directory on my disk. Here are some of them:

• Audio: Audio files also might get their own group.

• External Libraries: If I'm importing other people's code, I'll make a group called "libraries" and then a subgroup for each one.

• Images: In there, you can make subfolders/subgroups if you like. (One for icons, one for the main menu, etc.)

• Managed Objects: When I use Core Data in my projects, I'll often generate subclasses through Xcode's modeling tools. I like to keep those in a separate group and a seperate folder as well.

• View Controllers: Depending on the project, I might group my view controllers differently. For example, I might keep all of my "editors" and "viewers" in distinct groups.

Ultimately, Groups are for making your project management easier and Folders are for making file management easier. It's totally up to you how to do this. As Bill Brasky points out, at compile time, none of the organization really makes a difference. (If you want to go crazy, take a look at the "Build Phases" screen in Xcode 4. The copy phase is a jumble of all your relevant files.)

回答3:

I haven't come across any specific do's/don't's when it comes to how you organize your project in XCode. I could be wrong, but I believe any folders and layouts you create on your own are completely stripped away at compile time anyway.

For instance, if you have an image nested into Resources/Images/Background/image.png, you still just reference the .png filename and not the folder structure.

I would have to say you could still organize your project as you see fit. Borrow some from java and lay it out whatever works best.

回答4:

It's really to your liking. The Organizer does not reflect the actual file structure. In the end, the source files just get compiled into a binary and the resources are all just dumped into a "Resources" folder within the bundle for your application. I just extend the default setup—I put Resources into the resources folder, grouped as necessary. In a game, I might have groups for Icons, Backgrounds, Sprites, Audio, and Others. For a productivity app, I might only have Textures and Icons. External libraries and Frameworks all go into the Frameworks group (I rarely bother organizing these, except if some library such as the Dropbox SDK or GData already comes in a neat group. Usually it's just one file anyway). In the Sources group, I might group by functional views, such as Document Library, Editing View, or Utilities (for a document-editing program) or Main Menu and Gameplay for a game. For a smaller project, I might group by Controllers (split into View Controllers and Model Controllers if necessary), Models, and Views. If you're coming from a Java project, there's nothing wrong with keeping your existing organization; in fact, by default when you add to Xcode it will make new groups according to folders on disk.

Everything gets flattened out in the final bundle anyway, and your organization has no impact on the file system. Use whatever is necessary for the project—don't use the same structure for a Tetris clone as you would for a...professional medical app or something.