Tag Archives: MVC

MVC for iOS

iOS

MVC for iOS

Data Models – objects that you use to maintain, manipulate and retrieve retrieve.

The data model represents the core information that your application is being used to access and manipulate.

For example, User is a piece of data. Then you would want to have a class UserDB, where you specifically have methods to pass in user data and retrieve user data from the database. All of that combined is a very basic data model. As you add more objects to represent all the information that will interact with each other, you will have a more complex data model.

The Data Model works strictly between the controller and the database storage.
They’re kinda like the warehouse guys at retail stores. A Manager would tell them what stuff they need to bring out from the warehouse and where to stock it. The bringing out of the stuff from warehouse is like data retrieving from the database. When the warehouse guys stock it, they are giving the needed data back to the controller, or managers.

Controller – A controller can send commands to the model to update the model’s state. It can also send commands to its associated view to change the view’s presentation of the model.

Essentially, its like a manager on a sales floor. Sales people let the manager know whats going on and what items has been sold out, or too much, or whatever the customers need. The manager then communicates with the warehouse guys to let them know what kind of items to bring out, take back, restock, overstock, etc.

Similarly, the controller see what the views want or request, then communicates with the data model to do it. Then gives any response back to the views.

View – These are the like the sales guys. They communicate with the customers and take care of all customer input.

The View takes in all user inputs. Then gives it to the controller to be processed.

From an iOS perspective:

mvc

UIViewControllers talk to each other through delegates

C/C++/Objective-C, iOS,

The controller manages the communication between the view and the model. It takes the data from the model and communicates it to the view for display.

In the same vein, the controller also takes the changed data (due to user interaction or something else) and communicates it back to the model.

Say SmoothiesViewController and EditRecipeViewController need to communicate with each other.

Declare Protocol and use delegate variable

First declare protocol like this:

EditRecipeViewController.h

Once your protocol is set. You declare a delegate:

Whoever conforms to that delegate MUST implement the methods in that protocol. Because this class with the delegate, will be calling these methods, and the classes that conform to this protocol, must execute these methods.

In EditRecipeViewController.m it is used like this:

First, we check to see if our delegate responds to such method. If it does, then call it. This means that ALLLLL the UIViewControllers that conforms to our EditRecipeDelegate protocol must execute their method of editRecipeDidCancel.

UIViewController conforms to protocol

Say SmoothiesViewController conforms to our EditRecipeDelegate

This means in our SmoothiesViewController.m file, we must implement the required protocol methods:

Data Model (mvc)

C/C++/Objective-C, iOS

You have your business logic in Recipes:

Recipe.h:

Recipe.m

We put our business logic into a data structure. Implement some methods that manipulate this business logic. This is called our data model.

DataModel.h:

DataModel.m – this is where we manipulate our business logic into a data structure and implement wrapper methods such as add, delete, search, indexOf…etc.

Firing events through Notifications

Model — fire events –> Controller

Our Data Model communicates with other UIViewController by firing Notifications like this in our DataModel.m:

Thus, from our DataModel, we fire a notification called FavoritesChangedNotification or RecipesChangedNotification, which are NSStrings defined in our DataModel.h like this:

Whoever is listening for these notifications will execute their @selector method code.

UIViewControllers listening for Notifications

In our UIViewController we set it up like this:

You can see we have a strong reference to the shared Data Model.

In short: the owner of an object will retain that object and is ultimately responsible for releasing it when it no longer uses that object. When an object is retained, this is called a strong reference. SmoothieViewController has a strong reference to DataModel, because it created that object. SmoothieViewController owns the DataModel for as long as it is alive (which is until this app exits) and will release it in its dealloc.

Whenever we have other UIViewControllers that updates our Data Model like RecipeDetailsViewController, we make it a so-called weak reference like this:

note:
RecipeDetailsViewController does not own the object and therefore does not retain it. Because RecipeDetailsViewController is guaranteed that the DataModel instance will be around for at least as long as it is (i.e. until the user exits the app), it has no need to retain it.

In general, if you pass along pointers to objects you should make them weak references (using the “assign” property semantics), to signify that the object you are giving it to does not assume ownership. You only use “retain” or “copy” when you are not guaranteed that the object may stick around, in which case you become responsible for releasing it when the time comes.
end note.

We then have a UITableViewController displaying the data in our dataModel variable.
What happens if our dataModel changes data? Then in our DataModel.m, these methods will fire Notification like this:

So Data Models post or fire these notifications. We have our UIViewController’s listen for them.

Our UIViewControllers listen up for notifications through [NSNotificationCenter defaultCenter]’s addObserver:

First, make sure the notification strings are set from whichever data models are firing them. In our case its in DataModel.h:

then in your UIViewController’s m file, we set up NSNotificationCenter’s addObservewr:

Once we set up the observer, we implement the method that will execute whenever we receive such a notification in our UIViewController:

What this means is that our UIViewController basically are listening for notifications from our data models. Once there is a notification, we update our view (in our case UITableViewControlelr) accordingly.

Also, remember to remove those observers in your dealloc:

Controller updates Model

Controller — updates –> Model

Now in your ViewControllers we also update our DataModel through using the self.dataModel removeRecipeAtIndex method. Our users manipulate our UITableView, and the interaction calls our commitEditingStyle:forRowAtIndexPath, which then manipulates our weak reference dataModel variable. That is how Controllers update our Models.