As programmers we constantly use frameworks and libraries while developing new applications. Most of you will probably never deal with frameworks or library design nevertheless a certain amount of knowledge of the topic is useful even working on standalone applications.
The following article is an introduction to the differences between these entities and how they interact to produce a consistent and maintainable product.
We will look at their different roles and scopes, when we need one or the other and the best practices for our development cycle.
The last part contains several tips to write a good library I’ve collected in these past years. Continue reading…
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.
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.