Structure of an iPhone application

The separation among the View and the Model.

In general when you read examples of source code of iPhone applications the logic of the application and the database access is usually included directly in the delegate of the view (which basically is a View element) so there is no clear separation among the View and the Model (considering the MVC paradigm).

I present here my approximation to have a real separation between the view, the data structures used by the view, and the model (including the application logic and the data management of the database); and how to communicate these two worlds.

The visual elements

Apple imposes a structure on the view governed by the UIViewControllers (see "View Controller Programming Guide for iOS")

UIViews are the graphical entities that are used by the system to display the elements on the screens.

UIViews provide the general behaviour of the View that can be customized using the callback functions of the delegate.

On the other side, UIVIewControllers provide a data structure that is well known by the system. You can combine different UIViewControllers in the way defined by the previous guide to create a coherent behavior of the application. For instance, a TabBar with different Navigation Bars each one with UiTableViews and with different buttons in the navigation bar, all these combinations of visual elements are well defined and governed by the UIViewControllers, so you as programmer only have to focus on the missing pieces of your application and not on how to control the behaviour of each UIView.

Each UIViewController has each own way to discover the visual elements (for instance, the buttons in the navigation bar for a specific view), for this reason it is so important to read the guidelines provided by apple.

The application logic

The application logic is the set of functions that make operations over the application's data: uses the database and transforms the data.

This part, the application logic, is where you should use unit testing, as one of the ways to guarantee the quality of your application.

For unit testing I'd recommend WiteBox. It provides the traditional interface with the green and red bar to see if all you tests has been executed without problems.

How to communicate the View with the Model?

My recommendation is to create few well known singleton classes that act as interface with the model... So, all communication about the application data is done through these interfaces.




For instance, a Model class to access the settings. Or a "ContactManager" for an application that manages contacts... Here it depends a lot on your Application, but the main data elements should have one of these interface classes.

One important detail is that these main classes are general abstractions of concepts in your application (tasks, projects, context, notes, accounts, contacts, people, what ever) but could be different than the tables and the schema used in your database.
At this level you use the data abstractions that best fits the application's interface and the user at the end.

In summary, all changes in the model are communicated though these classes (ContactManager in the figure) that operate over the data, changing it, storing, deleting, etc.

The data between the model and the view

Views use data structures to represent the information: a table requires a data structure with sections and rows for each section. One instance of this class used by the table, is created and managed by the Model. So, for one side the table retrieves the data instance through the model, and the model updates the information in this instance each time it receives changes from the View.

Imaging a contacts application where you can group your contacts on different groups. An you have a table that shows the list of contacts in one specific group. If you change the name of one of your contacts in that view. You should inform the Model that this contact has changed.

Once the Model has received this information it will update the database with the new contact update, for instance you can remove the link of this contact with a group, or change the name or add the contact to a new group. All these operations are done by the model.

How to communicate the changes in the Model to the Views

One basic rule is that the model doesn't know anything about the Views. So, how to communicate the changes to the Views?. My approach is to use notifications (NSNotification).

Each view knows which are the changes in the model they have to subscribe. If you are presenting the contacts, you subscribe to any change in the contacts.

The model will update also the data structures used by the view to show the information. So when a View receives the notification it manages the right information inside the data structures of the view.



Types of Notifications

Usually you only need one notification, for instance to inform that a contact has changed. But in some cases, like deletions, you need to send two notifications:
CONTACT_WILL_DESAPPEAR and CONTACT_DID_DESAPPEAR
one notification to inform that something is going to change and another one to inform that has already changed.
This allow the view to have information about the object that is going to be removed or changed and then act on the view accordingly, for instance storing the position of the row in a UITableView that is going to be removed.
One note, as part of the notification you can include the data that is going to or has changed.

Conclusions

This is the approach I use in my applications, the key concept is the use of notifications to communicate changes in the Model, this way there is a clear separation between the Model and the Views. In fact, the model doesn't know anything about the views, and only the views affected by the changes (and in memory at that time) are informed, so the view can update the content in the screen.