Throttling calls in Swift

Throttling wraps a block of code with throttling logic, guaranteeing that an action will never be called more than once each specified interval.

Throttle is typically used inside search boxes in order to limit the number of backend requests while user is typing for a query; without throttling when an user types fast, backend server may receive tons of non useful request which are quite costly.
Moreover client will be busy updating continuously the UI with no longer relevant results: the entire behaviour causes your app to look cheap and the logic unnecessary complex.

Usually when implementing this kind of feature the first options you may consider is to use an NSTimer  fired/invalidated at your set interval. Repeating this boilerplate code in your view controller its not a good idea; usually you want to avoid any mess logic tracking state in a portion of your code that you’ve been trying to keep stateless.
Another solution involves RxSwift which has a throttle implementation out of the box; btw including an entire lib and use just a function its not a good practice after all.

View the article

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 UICollectionView  & 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.
View the article

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.

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
@