A simple, elegant caption looks good between image rows, after each row, or doesn't have to be there at all.

Images can be made zoomable. Simply add data-zoomable to <img> tags that you want to make zoomable.

Model-view-controller concept

In object-oriented programming, design patterns show a general view of how classes and objects interact, describe their relationships. They are like a sign on a crossroads, pointing to the possible solution for a given problem.

With design patterns you can develop fast and effectively. However, using a particular design pattern is not a mandatory, the only right way of achieving desired functionality. A developer has to keep in mind all the limitation and drawbacks of using the design pattern that seems to fit well as a good solution for a given task.

Quality, not quantity

Someone has recently asked me if a code that uses more design patterns is better then the code that utilizes only a few of them. Of course, it is not about the quantity. A developer may use only one design pattern (or doesn’t use any at all) and the app may work perfectly, the code can be clean and professional. It all depends on the particular application or a feature the developer is dealing with. Quality, this is what counts.

Classification

I will not reinvent the wheel here, there is a nice presentation of the classification of the design patterns in the article about the design patterns on wikipedia.

So how it looks in iOS development?

Here I present some examples of classes and approaches that fulfill the rules of several design patterns. Firstly, I present the Model View Controller (MVC) pattern that you must have encountered during the development of a view (or window) based application.

Model-View Controller pattern

In MVC, every controller owns a view and a model (with data presented by the view). In fact, the MVC pattern consists of a set of more primitive patterns. I will introduce them here:

  • Composite – Views form a hierarchy. Each view has a strictly specified position in the view hierarchy. Each view can be drawn on screen or respond to touch events. What is more, every view can be a parent node for another set of views. This pattern is very common. When we add UIButton, UITextField, UITableView or any other UIView to the parent UIView of UIViewController we utilize this patterns. Command – The mighty target-action approach. Views can defer and forward execution to other objects (in most cases they forward it to our UIViewController subclass). The execution is forwarded to other objects when certain events occur (for instance user taps a button – UIControlEventTouchUpInside).

  • Mediator – Our view controller mediates between our presentation layer (the views) and model layer. The interaction is bi-directional. So, if the model changes the view objects are informed about this change not directly but via the Mediator (our UIViewController).

  • Strategy – The fact that view objects interact not directly with the Model but using the Mediator pattern with controller object gives as a good starting point to use a Strategy pattern. The controller decides which “strategy” will be the best for dealing with the particular problem (f.e. which algorithm to use with data acquired from the user by view objects).

  • Observer – This pattern is very common throughout whole Cocoa. If a model gets updated it may inform all objects that registered as the observers about the change that occurred. This can also be done in the opposite direction, when model should be updated, because user interacted with the model through the view objects. Now you probably think about Protocols, Key-Value Observing and Notification Center. That’s right, these are all perfectly working examples of the Observer design pattern.

References: Pro Objective-C Design Patterns for iOS, Carlo Chung