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. 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.
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…
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). Continue reading…