TableViews are everywhere; for years before the introduction of Collection Views they were one of the fundamental block of every application’s.
Even if now we are able to replace the entire functionality with the combo of
UICollectionViewFlowLayout (take a look at “The case for deprecating UITableView“) they still play a key role during the everyday work life of any iOS developers.
Frankly I always hated the way in which we prepare and manage contents inside table for several different reasons:
- tons of boilerplate code to declare data source & delegates. I loved the datasource/delegate pattern, but we can do better and we can do it in Swift, of course.
- it’s weak: declare cell via identifiers (literals!), cast and finally use them; in our new strong-typed world this is a nightmare we need to avoid.
- complex tables are a nightmare to prepare and manage; usually you will end up in a world full of if/switch conditions to allocate one cell instead of another, do an action if the you tapped this or another cell and so on. I just want to declare content and do actions.
- Your view controllers are easy to become full of apparently-non-sense-conditions used to manage the content of your tables.
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…