Latest posts

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.

Introduction

When including third party libraries into your project, you can run into a “Duplicated Symbols” error on the linking process. This annoying error is due to a name collision between one or more of your classes, usually caused by either:

You do not use a prefix as namespace and you use a generic name such as Session, User or similar. This has an easy solution, as all you need to do is rename your classes to use a prefix. For example, User could be renamed into AGUser. Using prefixes is a good practice that you should always follow in programming languages without namespaces like C or Objective-C.

One or more of your libraries are including the same third party library. This is quite common on static frameworks and libraries built with little care. Usually, the creator of the library includes generic utilities such as SBJON, Reachability and similars inside the compiled binary. Then, your project or some other library also making use of it tries to include it again, resulting in the duplicated symbols error. If you have access to the source code, it could be solved easily by leaving the duplicated one out of your target. Unfortunately, when this problem occurs, many times comes from compiled libraries or frameworks that do not give us control on the source code files but just a binary instead. Solving this issue may not seem easy or even possible, but as we are going to see in this post it is not so difficult as it may look.

Introduction

It is very common to see shadows in different apps. In many occasions shadows are just rendered by using an image with the shadow predrawn, which basically performs as any other UIImageView. However, sometimes you may need to draw the shadow from code. When this time comes you will face performance problems that in case of heavy use (especially in iPad in combination with table or collection views) it can slow down you UI.

It might seem negligible, but if your view is a composition of multiple views applying shadows then you will actually experience a very big UI performance degradation. For example, in my latest project where I had a grid view with shaded cells like this:

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!