Tag: objective-c

Disclaimer

It has been a long time since I started with the MVC post series. It is not that I didn’t want to write about it, but by the time I was supposed to start with this post Objc.io came with a very good issue on View Controllers, which made my post almost irrelevant as most of the ideas were already mentioned there. Anyway, after receiving quite a lot of messages asking for this post, I finally decided to spend some time and try to address some new points and explain those that are important. That being said, if you haven’t read objc.io issue do not hesitate because it is worth the time and an excellent complement for this post.

The controller role

In MVC, the Controller is the part of your software that communicates your Model layer with your View layer, and it is by far the most abused role in iOS project. But lets first define how a good controller should look like:

A good controller should know how to request data to the model but not its internal details or how to fetch it; it should know what view to use but not how to draw it; it should be the one receiving events from one layer and passing messages to the other layer but not the one creating the events. In brief, a Controller should be the glue needed to connect the Model and the View, but ideally it should not do anything else than that.

However, in iOS projects we often find controllers that make lot more duties that the ones they should. This is not a coincidence: delegation patterns used in most of Apple’s components can be easily implemented on controllers, and the UIViewController API exposes methods like viewWillLayoutSubviews that should concern the View role only. Even the UIViewController name denotes this lack of real distinction between views and controllers!

Nevertheless, writing good controllers make your code lot more reusable (not only the controllers but the other layers also), easier to test, more maintainable and more flexible. So, lets review some important guidelines:

For those of you who attended the iOSX Enterprise Summit, here is my presentation about good practices for writing clean code.

What exactly is clean code? is your code clean? how can you improve your code quality? In this presentation we will answer these and other questions by exploring some of the general principles that any clean code should have. The presentation will cover very different levels of abstraction, going from the lowest ones to build up to the highest ones.

We will get started by defining "clean code" and understanding why readability is so important. We will dive into good codestyle practices by analysing naming conventions, code formatting, comments... We will then continue with good practices whenwriting functions, methods or classes; and finish up with some of the most useful software design patterns applied to mobile platforms.

All along the presentation we will show specific code examples written in Objective-C and/or Swift that expose some of the most common anti-patterns found in iOS development. By the end of the presentation you will be able to quickly detect anycode smell in your project and you will be better prepared to write a "cleaner" alternative.

Today I am going to write about a pretty uncommon but very useful pattern in iOS apps, called Chain of Responsibility, exploring how we can take advantage of some Cocoa methods to implement it easily and how/when to use it in your iOS apps to reduce dependencies in modular apps.

But before starting, I want to acknowledge Saul Mora because it was on one of his presentations (about a year ago) where I first saw this pattern in action. He applied it for the Model layer, while I do it for the Controller flow mostly, but the main idea behind the whole post is basically the same and you could apply it for either case. I suggest you spend some time checking his presentation about this pattern, very inline with this post.

In previous chapters we have exposed how the MVC pattern separate concerns in three layers and we have analyzed how to correctly implement the Model layer into your iOS project. In this post, I am going to continue with the next element in the MVC roles: the View role.

The View role is the responsible for handling all the UI layer. Ideally, this role should not know anything or very little about the associated controller and model layer (at most how to use the model, but not how to perform direct interaction/manipulation on it). In an iOS project this layer is implemented by the UIView class (and subclasses) together with the Interface Builder files.

As we saw in the Model post, there are many ways and tricks to implement this role in a project, but I will try to summarize all the best practices and tools that I have found so far, not only regarding MVC but also as general View related suggestions. As usual, you might be already using many or not agree with some of them, but hopefully you will get some fresh air out of it. So lets start with my suggestions because the list long!

Today, as part of the MVC in Objective-C series that I am writing, I am going to introduce the best practices that I have found so far when dealing with the Model role in your iOS app. But lets first give a quick introduction about the Model role:

The Model role in MVC is the one responsible for dealing with the state of the app. It encapsulates the code responsible for managing data, applying business rules, etc. This layer is usually the most decouple part of your app as it does not communicate directly with the controllers or views (only indirectly when the other layers request its information).

When implementing the Model in an iOS app you typically have to deal with different kind of problems: