Sometimes during the lifecycle of an application you may need to change the rootViewController  of your main UIWindow ; a typical case maybe the transition between the initial on-boarding and the home of the app (ie. a UITabBarController ).

In order to handle this edge case you may want to create a top controller (typically an UINavigationController  with invisible navigation bar) which enable you to push your new container using a standard push animation.While basically it works fine, the addition of a container used only to handle this single operation is a bit awful to see.

A way better solution is to apply an animated transition (push/pop or slide) to the rootViewController  set so you will get an animate switch from the current view controller to the new one.

View the article

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

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).

NOTE
I’ve used this approach to simplify my everyday work both with UITableView  and UICollectionView ; from this work I’ve created Flow, a new approach to manage UITableView.
▶︎ Check it now! it will save you tons of code!

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.

View the article
@