Monthly Archives: April 2014

Override back button in navigation stack


UINavigationController pushViewController pauses/freezes midway through


With out more detail I can think of 2 possible problem with that.

Is there Shadow added in code to the view that will be covered by the new ViewController. If it is the case, use ShadowPath or an translucent view instead (the property Shadow is expensive while animating, been there done that)

Is the backgroundColor of new ViewController “clearColor” ? I’ve seen strange rendering problem with that kind of thing.


That is the 2 possible problems I can think of the top of my head with so few detail.

Never rely on the default background color, it has change with iOS version and is not consistant across controls and can even be different if the view is created in code or from a Xib (in the same iOS version).

CvVideoCamera usage

When using CvVideoCamera in a UINavigation setting, you must start the camera when the camera’s uiviewcontroller gets pushed. Right before the uiviewcontroller gets popped, make sure you stop the camera:

Also, its a good idea to take care of the camera when you are existing and enter the app:

Navigating to a new UIViewController from a UIViewController

First we put a button there and correspond it to a method called nextPage.

Then in that method, you use pushViewController to animate a new controller coming in.

…where MTBookCoverViewController is just a standard, empty UIViewController.

iCarousel using non-ARC

As of version 1.8, iCarousel requires ARC. If you wish to use iCarousel in a non-ARC project, just add the -fobjc-arc compiler flag to the iCarousel.m class. To do this, go to the Build Phases tab in your target settings, open the Compile Sources group, double-click iCarousel.m in the list and type -fobjc-arc into the popover.

Apply gradient to UIView

Using gradient from one color ro another

Using a sliver of gradient as background

UIViewControllers talk to each other through delegates

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:


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)

You have your business logic in Recipes:



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


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:

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.