It would be nice to get away with declaring a constant for every reuse identifier of cells in our app: with this common approach is very easy to make mistakes (and clearly it does not fits in a Swift world).
We can just use the name of the custom cell class as a default reuse identifier.
First of all we can create a
ReusableViewProtocol which is responsible to provide the identifier of cell. Continue reading…
Not so long ago I had published an article about Network Layers and how Swift may help us avoiding big fat singletons by isolating responsibility and simplifying the codebase (it’s on Medium).
Just wanted to say how much I appreciate the time many people took to read it sending lots of comments via mail and twitter.
During the past five months I had the chance to test it on different production projects, discuss it with co-workers and colleagues: the following article aims to propose a more robust and stable iteration of the initial idea: some stuff are changed while others still here, stronger than ever.
In order to keep it readable from anyone I’ll describe it from the scratch and I’ll provide a real implementation you can download and use in your next application.
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. Continue reading…
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. Continue reading…