views:

2058

answers:

3

Hey guys I'm relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for example, at the moment, all of my images are at the top level directory and it makes things look messy. I rather would've liked, for example, to have an images/ folder and then sub-folders within that to store images for certain things, like tab-bar/ icons. Is this possible? Or is it convention to just keep everything in the top level directory?

Someone in the #iphonedev channel at freenode told me something about the build process rule or something, it just seemed too complicated I figured I shouldn't bother, and that most people just kept things at their root directory considering the complexity of the solution. Perhaps it isn't all that complicated though, I just felt it should be easier.

For example I would also like to have a sub-folder for my views, like views/ that stores all of my nib files; currently they are all in the top level directory. And the same goes for my property lists.

I would appreciate it if you could tell me what the convention is, I doubt it is to just store everything in the top level directory. And I'm referring to the actual file system, not simply creating 'virtual folders' in Xcode to organize things, because the top level directory of my project will still be a mess. And if it is possible to organize things better, I would appreciate any detailed help on how to accomplish it.

I think I have heard that in the final build, the entire file structure gets squashed to the root directory. I don't mind so much about that, I just want things to be organized while I am working on my project. I think this is where that 'build rule' thing comes in, but I'm not sure how or what to do.

Thanks!

+1  A: 

It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.

Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.

Graham Lee
Thanks! Will this also work with nib files and property lists? When I load these in my code, for example an image, would I do imageNamed:@"file.png" or imageNamed:@"path/to/my/file.png" ?
Jorge Israel Peña
A: 

Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.

In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.

Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).

You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.

But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.

My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.

IlDan
Thanks, but I never said Xcode sucked at this. I'm new to it and I'm just wondering how it is done, and if it should even be done. It's just that when I go to view my github repository, it looks really messy with having everything on the top level directory.
Jorge Israel Peña
Oh sorry, I didn't mean to be rude. I know you were wondering, I had your same concerns some time ago. I'll change that wording.
IlDan
No problem, thanks for the response. It cleared some stuff up.
Jorge Israel Peña
+6  A: 

Here's a little more explanation of Graham's suggestion:

  • Create an images directory
  • Create an images Group in Xcode
  • Right-click the group and Get Info
  • "Choose..." to set the group's directory to be your images directory

Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)

This will work for anything you put in that group (NIBs, etc).

For imageNamed:, you just give the base name.

My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.

Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.

Rob Napier
Thanks, this did it for me. Yeah I'm not planning on over-doing it, just at least some basic organizational structure is nice to have. So far I have images/ which contains images/tab-bar and images/player, as well as property-lists/ to store .plist files and views/ to store the nib files. I did think about physically making a 'Resources' folder, but I don't know how I would do this, by changing the path of the existing Resources group to the new Resources folder? Or creating a 'Resources' group under the existing Resources group?
Jorge Israel Peña
I ended up re-doing it by adding the folder(s) as folder references. I read somewhere that this means that the folder will be tracked, so when I add/remove files, I don't have to do anything on the Xcode side of things. Don't know if this will cause problems later on though.
Jorge Israel Peña
Sorry for the comment spam. It turns out that a folder reference meant that it created that folder structure in the resulting .app. The solution was to create Resources/ in the top level-dir with sub-dirs images/, views/, etc. and then drag those sub-dirs into the Resources group on the left, and adding them as groups. Now it looks the way I want it to look on the file system, and still looks organized in Xcode.
Jorge Israel Peña
Sounds like you've walked through exactly the correct learning process. Folder references can sometimes be useful (I've used them to include large amounts of HTML documentation), but generally the way you've done it is best.
Rob Napier