iOS Development – Organizing Code for iOS App Development

code-organizationiosobjective cproject-structurexcode

I've been developing an app for the iOS platform, and as I've been going along, I've noticed that I've done a terrible job of keeping my files (.h, .m, .mm) organized. Is there any industry standards or best practices when it comes to organizing files for an iOS project?

My files include custom classes (beside the view controllers), customized View Controllers, third-party content, code that works only on iOS 5.0+ and code that works on previous versions. What I'm looking for is a solution to keep things organized in a manner that others (or myself in years to come) can look at this and understand the basic structure of the application and not get lost in the multiple files found therein.

Best Answer

There is no industry standard as such. You could look into sample Apple Source Projects to see how they do it..

You could however, try organizing your files into Groups & associate each group to a folder..

Organize all Controllers in One Group with Subgroup for each usecase.
Put all views in One Group and subgroup for each usecase.
Organize All Models in one Group
Put Third Party Libraries in Another Group with Subgroup for each Lib.

So on and So Forth.. Also, associate each group to a folder inside your project.

Related Solutions

IOS Variable vs Property

First of all, there is no need to declare the instance variables for properties as the statement

@synthesize var = _iVar;

is actually generating an implicit variable named _iVar for you.

You would create properties when you want them to be accessible outside the class like

YourClass *obj = [[YourClass alloc] init];
obj.yourProperty = somevalue;

Properties also relieve you of writing your own getters & setters and take care of much of memory management themselves. Here is something you might wanna read plus other articles linked within the post.

http://cocoawithlove.com/2008/08/in-defense-of-objective-c-20-properties.html

iOS – Implementing Themes for View Controllers

You're right to want to change technique. You can imagine all the work you'd have to do everytime you need to add a new theme.

Subclassing View/Controller

Some programmers may choose to subclass the base view controller in order to take into consideration multiple themes. If the adaptations you have to apply between theme to theme is radically different, then this approach is fine. However, most times themes share a lot of common features, and you may end up having to change very little between them.

Subclassing Theme

The second approach eliminates this problem by having a shared "theme" class which does a lot of the work common among themes. It also keeps your view class single-purposed (and therefore easier to read) and doesn't have to worry about little nuances like theme changes. Since this approach eliminates all the disadvantages of the 1st approach with no added disadvantages of its own (unless "excess classes" is something you consider a disadvantage), this approach is the best practice in general.

Do the best you can to use inversion-control principle and have your view/controller call the theme class in order to do theme-specific tasks like draw a control, passing all the necessary information about said control into the method. In this way, your theme is stateless and you retain control in your controller without having to know how it works. Plus, you can have a base theme behavior in your basic theme class so you even if you do not override method, you're sure to always see something, even if it may not be themed properly.

I hope that helps.