Model object design for iOS apps

This document will help you design useful model objects for your iOS app. It is intended for the entry-level iOS app developer.

.

This document was most recently updated in January 2015.

.

Model object assumptions

The following are the assumptions about the design and functionality of a model object:

There may be one or more model objects in an app.

A model object’s role is to provide a single access point to the app’s data for the other parts of the app (which are mostly controllers).

A model object may use any of the available persistence schemes, including property lists, archiving, Core Data, iCloud, and web services.

The model object (and not a controller) is responsible for communicating on the network. Async (non-blocking) communication must be used.

Model objects use key-value observing (KVO) and notifications to communicate their state (to the rest of the app).

.

How to create a model object

Create a Swift class, named “Model”. It can be located in the project’s root.

Next, think about your app’s data, and how it should be made available to the app’s controllers. Typically, you will need:

  • Properties; one for each entity collection
  • Functions that accept arguments to filter or sort an entity collection as a return type
  • Functions that perform tasks, such as ‘get one by its identifier’, or ‘add new item’, etc.

Then, add these class members, and their code.

And, it’s likely that the model object will also need an initializer. You will learn about this soon (or you can read about it The Swift Programming Language book).

.

Model object design

Among other features, a model object provides the user/consumer with access to a “collection” of “items”. Typically, at least one of the model object’s properties will deliver an array of results, so that it can be directly used in a table view (UITableView).

The “item” can be simple, and one of Swift’s types (e.g. String, Int, Dictionary). Or, it can be a type of your own design.

The following code elements are typically part of a model object’s design:

Variables and constants

Properties

Initializer(s)

Functions (which are public/visible)

These methods will be designed to help with the model object’s maintenance; examples…

Get all items (returns a collection)

Get one item (by query)

New item

Modify an item (by query)

Delete an item (by query)

( etc. )

Persistence code (e.g. save, load)

Communication code (e.g. notification, delegation)

.

Using a model object in your app

Initialize your model object in the app delegate.

Pass on a reference to the model object, to the root view controller.

Note: This is the pattern that you will use every time you want to get access to the app’s data (i.e. the model object) in a controller. Make sure that the controller has a declared property to hold a reference to the model object. When the controller is initialized, set (pass on) the model object to the new controller.

The philosophy is that an object should be configured with all it needs to function correctly.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: