What is the standard way to organize iPhone MVC code in XCode?

Question

I have an iPhone application that contains several views and their associated controllers. Looking at sample code, I've seen different different ways to organize these files - either have all of the views grouped, then all of the controllers grouped, or group the views and controllers by functionality.

Option 1 - Views and controllers grouped separately

-Views
  |
  - EditItemView.h
  - EditItemView.m
  - AddItemView.h
  - AddItemView.m

-Controllers
  |
  - EditItemViewController.h
  - EditItemViewController.m
  - AddItemViewController.h
  - AddItemViewController.m

Option 2 - Items grouped by functionality

-AddItem
  |
  - AddItemViewController.h
  - AddItemViewController.m
  - AddItemView.h
  - AddItemView.m

-EditItem
  |
  - EditItemViewController.h
  - EditItemViewController.m
  - EditItemView.h
  - EditItemView.m

Option 1 seems to make more sense from a MVC standpoint - the code is grouped together, but I'm wondering as the app grows to 10+ views and controllers, is that the most logical and maintainable? Is there a best practice recommendation around this? Currently, I will be the only one maintaining the app, but whether or not there will be multiple developers, I want to use best practices as much as possible. Are there published standards on this?

Answer 1

I'm working on a big xCode project right now. It isn't for the iPhone, but I don't think that matters for the sake of file structure layout :)

I started out with option #1 and later moved to something like option #2 when the number of files increased. I tend to group things by "interfaces" i.e., all of the sources associated with a particular area of functionality within the application, and then create sub-groups for larger sections if need be.

As far as naming goes, I prefer to identify Model, View and Controller using as little class name real-estate as possible, so my class names look similar to:

AM_DillPickle  // model class
AV_Sasquatch   // view class
AC_DirtBike    // controller class

This still allows for a quick visual check to see the type of a class (M, V, or C) but it leaves more room for the descriptive part of the name.

I've also found it useful to specify some classes that do not fit into the MVC pattern (gasp!):

AU_Helper     // utility class (text formatting, high-level math, etc.)
AD_Widget     // device class  (used to represent hardware drivers)

Anyway, that's already more information than you asked for, but I find the naming issue to be relevant to the layout issue, since the real question is: what is the best way to organize my code for a large xCode project?

Hope it helps. Here is how it all looks when put together:

[+] Project
    [-] Target One
    [+] Target Two
        [-] Preferences
        [-] Login
        [+] Main Window
            # MainWindow.XIB
            # AC_MainWindow.h
            # AC_MainWindow.m
            # AC_DisplayScreen.h
            # AC_DisplayScreen.m
            [-] Home Screen
                # HomeScreen.XIB
                # AC_HomeScreen.h
                # AC_HomeScreen.m
                # AV_FancyDisplay.h
                # AV_FancyDisplay.m
            [+] Widget Screen
            [+] Other Screen

Answer 2

The second option makes way more sense as your project grows.

Furthermore, the default project has xib files go into "resources" but again as a project grows it makes a lot more sense to move related files into a logical group for some screen or other piece of functionality.

One grouping arrangement by way of example would be:

3rdParty (for something like regex)
Utilities (for category additions to classes like UITableViewCell)
Tab1Classes
--Screen1
--Screen2
Tab2Classes
Tab3Classes
Data (for holding plists or other data you may want to load during an app run)
Resources (still here for random images it makes sense to keep central)

The App delegate could hang out in Utilitites, or perhaps just floating above all those groups under Classes.