Organizing Objective-C source files - objective-c

In Java we organize files in packages, Clojure has namespaces and Ruby has modules.
How to organize Objective-C files? any convention/best practice exists?
In Xcode everything is going under "classes" directory.

What I usually do is enforce physical folders (and groups within Xcode) for the files and have them added to the project from where they are. From there you can group files logically however you want them.
By default, it will create the file within the same Classes folder, and I find it difficult to navigate when dealing with an external source control client.
Leverage Categories to have separate files for separate logic for a particular class. For example I will have private method interface in the implementation file with a separate category name so that it is somewhat "private" to other implementations.
For uniqueness, you could try to prefix folders or groups of classes.

We use MVC on all but the smallest projects. So in the "Classes" folder we start by adding three folders, Model, View, and Controller. Under those directories we might create subfolders grouped by functionality with the app (controllers for various subsections, etc.). You can add files directly to Xcode or the folders themselves. Similarly we have a Resources directory, usually in the same directory as the .xcodeproj file and under that folders for Images, Nibs, Audio, etc.
Of course the above just describes a disk-based organization strategy. Since Objective-C is still C, you can build libraries and header files for APIs that you want to export. You can also use categories. Many of our projects reference a /Common directory that is outside of the project folder (and under Common we have Model, View, Controller, etc.). Sometimes we copy files from Common into the project if we expect to make significant changes to them that we don't want other projects to inherit.

I just organize things in XCode. Group files as appropriate. Yes, everything ends up in the Classes directory.

Related

IntelliJ IDEA: how to restrict project tree view to a couple of folders

I'm working with IntelliJ IDEA in a rather large tree of projects almost exclusively on about 5 folders nested deeply in the hierarchy. Ideally I just want to see those 5 folders most of the time - the other projects and the other folders in their projects are usually just visual clutter. How can I get a view as close as possible to this with IDEA?
I do want all projects accessible in my workspace, so I can't just throw away the others. And even that would not help too much, because those folders are deeply nested in their projects. The favorites view almost does what I want, since you can unfold the folders there - but if there are some new files they are often not visible there (not sure whether this is a bug or a feature). Do you have other ideas? Thank you very much!
It depends on what you are trying to do. You can create scopes by criteria.
Go to preferences (mac) -> appearance & behavior -> scopes
There you can create local and shared scopes. You can manually edit these or use a regex pattern. The current reference documentation is located here.
Here are some examples from the jetbrains website of using regex.
file[MyMod]:src/main/java/com/example/my_package//* - include in a project all the files from module "MyMod", located in the specified directory and all subdirectories.
src[MyMod]:com.example.my_package..* - recursively include all classes in a package in the source directories of the module.
lib:com.company..*||com.company..* - recursively include all classes in a package from both project and libraries.
test:com.company.* - include all test classes in a package, but not in subpackages.
[MyMod]:com.company.util.* - include all classes and test classes in the package of the specified module.
file:*.js||file:*.coffee - include all JavaScript and CoffeeScript files.
file:*js&&!file:*.min.* - include all JavaScript files except those that were generated through minification, which is indicated by the min extension.

How to add to project additional files not intended to be compiled?

I would like to add into project some files that shouldn't be compiled. I mean mainly text files with for example notes, concepts, comments etc.
I realized that it is possible only at module level. But it is not very convenient. I'd rather prefer to keep them on project level. Is it possible in any way?
And if not:
I have another idea: to create special module, name it for example "other_stuff", do not create src directory and put files there. Is it ok? I'm afraid of potential compilation problems when one of modules is artificial, with no sources but still has sdk assigned (it is probably impossible to leave module without sdk assigned).
While generating artifacts you can add any file into your artifact. Also, in modules you can have folders not declared as source, and they will not be compiled.

Xcode groups hierarchy isn't mimic'd in the file structure

using Cocos2d project template (for objective c)
I've got a nice little hierarchy setup in Xcode, e.g categorization with folders, multiple levels, however in the file structure, its just one big directory of files, should I leave it like that? Should I replicate the hierarchy in file structure manually? Should it be automated did I do something wrong?
As Protheus says, the group structure in XCode is for organizational purposes only and not synced with the file system. For some projects though, it might be worth to keep XCode's group structure and the file system in sync. For example, I like to edit my files with VIM from the command line sometimes. On big projects with several hundreds of files, it is much easier to find specific files if you have a logical structure in the file system.
I discuss this in more detail in this blog article.
As far as I know neither structure in xcode, nor structure in project folder affect the program.
You structure it all for your convinience only.

Project organisation - File path and folder default naming

I'ld like to organize my coding and projects better. Are there any folder-name and file-name defaults I should use or are there any preffered ones within the industry?
Thanks for any tips.
Coding C++ most of the time, I organize my folders according to the namespaces my classes reside in, under a global src/ folder. I mix header and source files, although I know a lot of people that keep headers and sources separate in src/ and include/ folders. I think this is rather a thing of preference - I see the advantages of both approaches.
My filenames are typically the same as the classes the source file belongs to - (at least) one source file per class. For non-class code, I try to organize the functions/data according to logical units with "speaking" names.

Best practices when importing class files in xcode

I'm working with xcode and I have classes associated with other projects that I want to be included in new projects. I realize that the #import will do the job technically (although what should i do if it's out of the project root folder). But what do I do if I want to include the class "properly" --basically so i can double click and edit out of the main project window where you can see all your files and such.
I guess I'm just looking for the best and/or proper way to include/import (into the project) .h and .m files that I've already created outside of the current project I'm working on. Taking into consideration that I may want to modify the class from the original without subclassing. Hopefully this makes sense.
Thanks,
Nick
Xcode project file organization doesn't reflect the data files on disk. Files can be added to a project from anywhere in the file system. When you add the files, choosing not to copy the files to the current project's directory means that the original files are used. Selecting one of these files in Xcode for editing will alter the original file in that other project. When returning to that other project, Xcode will use the edited files in any further work.
This type of use can be quite handy while working on multiple projects with some shared code. Yet, it can also cause headaches for a versioning system.
Might be worth thinking about how to make the classes into a private framework - then you can import that as another dependency each time. Alternatively you could use a separate version control system location to store the shared classes and just check that out into the project folder.