iOS App design

One of my hobbies is writing iOS (mostly iPhone) applications: it’s fun, distractive and is a precious skill nowadays : thanks to iOS, Objective-C has never been so popular (according to Tiobe).

Once you got familiar with Objective-C, Cocoa and Apple tools (XCode, Interface Builder), it is not that hard to make your own applications. Apple has good documentation, and it is quite easy to find support in forums on the web.

However, after you wrote your first App (“Hello World” maybe?), and want to get more seriously into iOS development, you will be probably asking yourself one question (that what I did at the time) : how can I design my App to make it maintainable?

As I have been working on web applications for sometime now, I decided to design an iOS application architecture based on the infamous n-tiers architecture used in web applications.

The purpose of such an architecture is to separate data access, business services and user interface from each other.

Using Objective-C and Cocoa, I ended up with this:

Services

Services are responsible of managing the buisness logic of the application: they can be used to call remote web services, or to perform local processings.

A Service is always composed of a class and it’s delegate protocol.

The delegate protocol is used to get results / errors from services as they usually run asynchronously (specially when using remote calls).

It is recommended to manage application services with a factory class (that I call ServiceFactory): this factory is a singleton object in charge of creating and caching services (only one instance of each service is handled by the application).

Model objects

Model objects are simple objects used as input or ouput to services.

Some model objects may implement the NSCoding protocol in order to support serialization for reading / writing object from / to files.

User context

A ‘user context’ is used to store user data (usually to cache service results or to store parameters) but also to call services from the user point of view.

The user context is handled as a singleton object (I name it UserContext).

It is registered as delegate for all services in order to receive service results or errors.

When the user context receives a service response it processes it and notify the event using NSNotificationCenter and NSNotification classes. The notified event can then be handled by GUI classes.

Business to GUI communication

When a view controller needs to retrieve data or perform a business operation, it calls a user context method.

In order to keep the separation of services and GUI classes, GUI classes never call services directly, but only through the user context.

When the method is asynchronous it must register a notification observer on the result notification to know when the operation is finished (or failed) and handle it.

As view controllers usually don’t know each other, they use notifications to communicate.

GUI Navigation

Navigation (add/remove/push/pop views) takes place in the AppDelegate class which observes every navigation event (triggered by view controllers).

DAOs

DAOs (or Data Access Objects) are well known by web developers: those classes are used to perform CRUD operations (Create Retrieve Update Delete) on datasources (usually a database, but can also be a text file or anything else…).

This kind of objects should be used only when the application needs to store and query data (do not take in account user preferences, that can ben handled directly in the user context).

Only services can use DAO objects.

They must always run synchronously, in order to let the synchronous / asynchronous call decision to the service using it.

Like services, it is recommended to manage DAOs with a factory class (DAOFactory).

Originally published at https://blog.grousset.fr on January 27, 2011.