Or how to build scrolling stack container and keep an healthy usage of the memory.

In these days mobile UIs became a complex job; lists (tables or, more often, collections) may contains heterogeneous groups of items, showing in a single scroll interaction a great amount of data.

Take for example the IMDB application; the home page contains:

  • an horizontal list with the highlighted movies
  • highlighted news
  • an horizontal list with photo gallery
  • an horizontal list with nearby movies
  • another horizontal list with coming soon movies
  • vertical list of news
  • … and yeah, much more stuff

everything inside a single vertical scroll view!

Usually, if you still lack attention while writing this kind of code, your view controllers are likely to become a massive piece of spaghetti code, assembling several responsibilities and making your app more fragile and much less testable.
That’s the world of Massive View Controllers and the main reason behind alternative architectures like Viper, MMVM and several others.

Separation of concerns (along with Single Responsibility Principle) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.

View the article

Asynchronous programming in Objective-C was never been a truly exciting experience.
We have used delegates for years (I can still remember the first time I’ve seen it, it was around 2001 and I was having fun with Cocoa on my Mac OS X) and not so long ago we have also joined the party of completion handlers.
However both of these processes does not scale well and does not provide a solid error handling mechanism, especially due to some limitations of the language itself (yeah you can do practically anything in C but this is out of the scope of this article).

It’s damn easy to lost yourself in a callback pyramid of doom (also known as callback hell) and generally your code ends up being not so elegant and not so straightforward to read and maintain.

Promises can help us to write better code and, with the help of constructs like await/async it’s really a joy to deal with asynchronous programming.

View the article

How we can make Cocoa a little less verbose and a little more type safe.

When I’ve started working with Cocoa in later in 2001 I was coming from some experience in Java and a little less of pure C. Cocoa was simply amazing (check out this cool old article from Ars Technica) and the difference with the old Mac Toolbox was huge.
A brave new world was coming and I was pretty exciting of all opportunities which a complete full-featured framework like that could offer to me.
Lots of years are passed since these days, the old NeXT heritage was taken from iOS with UIKit and we lived the mobile revolution also and especially thanks to a complete solution which really helped to create an fertile environment for what we call The App Economy (which, of course, was started on macOS).

View the article