In this article I would like to present a way I am mostly creating constant and a way I am using them.

Most of the time I’m creating constant in the extension of a type of given constant. For example when I would like to create UIImage constant I am doing something like this:

I would like to point two important things here. First one is the fact that this constant will be create at the first use. Documentation says:

Stored type properties are lazily initialized on their first access. They are guaranteed to be initialized only once, even when accessed by multiple threads simultaneously, and they do not need to be marked with the lazy modifier

The second thing is the fact that this constant will be stored in the memory since first access until the termination of the application. Keep in mind that storing big object this way is not the best idea.

Now we can use this image in following way:

One other potential use for this pattern is for localizing strings.

In similar way we can set button’s title:

I am using this pattern mostly for Strings, UIColors, and really small images from application’s Assets. I really like the way I can use them.

Global variables are also lazy so the only significant advantage of using static let pattern is nice organization of this constants in the type extension.

My github: https://github.com/adiki/

Previous article: A way to handle NSNotification’s observation token

Situation complicates when we have to store more than one token.
We can solve it by keeping references in the array:

If we wouldn’t like to create temporary constants willEnterForegroundToken didBecomeActiveToken, there are at least two ways to solve it.

Let’s start with more obvious one:

I leave it to you to judge this implementation.
I would like to share with you another way to handle it. First step is to introduce ReferencesBag:

It’s a class inspired by Disposables concept which I got know when I was working with RxSwift.

Next step is to extend NSObjectProtocol protocol:

Having those two pieces we can write something like this:

Which one is the best? It depends on your taste. I just wanted to present you an alternative approach.

My github: https://github.com/adiki/

Next article: Static let pattern
Previous article: Wrapper design pattern by example using SFAuthenticationSession and ASWebAuthenticationSession

Recently I heard a lot of comments that some people after reading that book start using most of those pattern in any place they think they could use it. This is of course wrong. When you are young developer it’s really nice to know that that book exists and after some time of developing software you realising that you are using those pattern naturally and quite often you are giving them names different then you can find in any book of design patterns.

Today I would like to talk about one of design patterns called Wrapper. Wikipedia says something like this about it: “Wrapper pattern is a software design pattern that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.”

The problem we are facing working with SFAuthenticationSession and ASWebAuthenticationSession is as follows:

SFAuthenticationSession was introduces in iOS 11 and deprecated in iOS 12.
ASWebAuthenticationSession was introduced in iOS 12.

If you are lucky as an iOS application developers and you have to support at most one previous version of iOS there is some nice way how to hide usage of those classes under one simple class.

The really nice property of those two implementations is the fact that they have the same methods with the same signatures. We can use that fact and create a protocol with them:

Having that protocol we can extend SFAuthenticationSession and ASWebAuthenticationSession and add conformance to AuthenticationSessionProtocol and because the fact that those classes have those methods implemented already we don’t have to do anything else.

Now we cen create our wrapper class which will also conform to AuthenticationSessionProtocol:

To be honest that’s it. We have simple wrapper which nicely hides usage of SFAuthenticationSession and ASWebAuthenticationSession and nicely adapts to the system version which is installed on a device which is running our application.

My github: https://github.com/adiki/

Next article: A way to handle NSNotification’s observation token
Previous article: How to pollute your code with external dependency (and how to not do that)?

At the beginning I would like to mention that this topic is the most important one from my list of things I would like to share and write about. This concept is not exclusive to iOS developers and I think all of us who write more code than just “hello world” should be familiar with it.

Let’s dive in.

How to pollute your code with external dependency? There is a simple answer for that: just use it everywhere! Answering that we can do something more interesting.

Firstly I would like to present short theoretical concept I will use in this post. When I’m developing any application I don’t want to have a situation in my code that my application logic depends on external dependency. What I want to have in my codebase is the state where external frameworks (and my extensions of them) are implementing protocols provided by the application. To achieve this I have to use Dependency inversion principle (one of the five SOLID rules).

Above diagram exactly presents what I want to achieve. I want to have a state where all arrows are pointing towards the application component (any external component depends on the application). This is also one of the core concept of all app architectures with layers (these layers point towards to the center: example).

To explain it deeply I want to present the code which is implementing this concept. I want to show you implementation of the objects provider which is responsible for delivering collection of objects (e.g. for feed purposes). This implementation will use CoreData (external dependency) which will be responsible for accessing objects from the storage and delivering them to the app. The usage of CoreData will be implemented in a way where application itself won’t be even aware that it’s using CoreData for this purpose.

Let’s start with protocol which will be used by the app:

There are two responsibilities for the objects implementing ObjectsProvider protocol the first one is to return number of objects in the collection and the second one is to return the object at given index.

When we have this protocol we can implement CoreData component which will implement this protocol, but before that I would like to introduce new protocol called Convertible which will help us to prevent returning NSFetchRequestResult instances to the rest of the app (it’s wrong because it’s CoreData type).

Example implementation of this protocol is presented below:

Returning to our CoreData implementation of ObjectsProvider protocol. The implementation of that is really simple:

It looks really nice. Let’s try to use it in our code:

Ups, it doesn’t compile. Let’s see at the error: protocol 'ObjectsProvider' can only be used as a generic constraint because it has Self ot associated type requirements. Unfortunately it’s won’t be easily fixed by adding <GIF> after ObjectsProvider. To fix it we have to implement it in this way:

It work’s but I don’t think it’s elegant solution. Let’s see what will happen when we will try to use this GIFsDataSource in some ViewController:

This is nightmare! Using GIFsViewController will only produce more of this syntactical noise! There has to be a way to fix it somehow!

Fortunately there is a technique which can help. It’s called Type Erasure. You can find more details about it here. I will show only final result of this trick:

Let’s look how can we define GIFsDataSource now:

and the usage:

I think it’s wonderful implementation. When I’m using gifsProvider in my code I’m only interested of accessing objects from some collection. If I don’t know actual implementation of ObjectsProvider I cannot tell if objects come from CoreData, Realm or even RAM memory. Because that fact you can easily change implementation of the provider without affecting your codebase significantly.

You can find real usage of this concept in one of my public projects on my github. It’s available here: https://github.com/adiki/giftainer

Next article: Wrapper design pattern by example using SFAuthenticationSession and ASWebAuthenticationSession
Previous article: Simple trick to improve handling cells in UITableView and UICollectionView

In most of projects I’m working on, I’m not using storyboards. I’m familiar with them, I know how to use them, I see and understand their strong and weak parts. Knowing these facts I still prefer to write my projects using code only.

When we are working with UICollectionView one of the first things we have to do is to register our subclass of UICollectionViewCell:

Of course it’s not the best practise to use string literal here and in the place of dequeuing cells. We can improve it by creating static identifier constant and then reuse it in those two places in the code.

I hope all of you will agree with me that this solution is much much better then the previous one when we were using string literal. The question is if we could do it even better? Let’s try!

We can take advantage of the fact that AnyClass type have description implemented by default. Let’s look at implementation which is using that fact:

We can take another step and extend UICollectionView implementation to make it more convenient.

Now registering is really easy:

I think it’s really nice extension I hope you like it too.

Summarising the current progress, we implemented really consistent method to register cells in UICollectionView. In the second part of this article I would like improve dequeuing mechanism.

Traditionally I was using something like this:

It’s not bad implementation but the problem with it, is the fact that we will be reusing this pattern all over in different parts of the app. Let’s try to wrap this pattern in UICollectionView extension.

Now dequeuing looks really nice too:

The really important point to notice here is the fact that someCell constant is of SomeCell type.

That’s the final implementation of this improvement. I think it’s wonderful and one of the most important parts of it for me, is the fact that we don’t duplicate registering and dequeuing pattern all over the place. It’s simple rule: Don’t Repeat Yourself. Swift language is really helpful here to achieve this kind of effect. I hope that after reading this article you will be able to implement similar solution for UITableView.

My github: https://github.com/adiki/

Next week: How to pollute your code with external dependency (and how to not do that)?
Previous week: Extensible extension of a Micro Auto Layout DSL

On October 27, 2017 Chris Eidhof released his post about Micro Auto Layout DSL: http://chris.eidhof.nl/post/micro-autolayout-dsl/. I was really inspired by his work and I started using it in my projects because his implementation was very simple and I could manage the code by myself. His concept was based on introducing special typealias:

In his blog post he is explaining how using this simple concept and using KeyPath‘s we can achieve something like this:

Next part of the post assumes you are at least briefly familiar with Chris’es concept and his implementation. If you would like to get to know the details of it please visit his website here: http://chris.eidhof.nl/post/micro-autolayout-dsl/.

There is a limitation with the implementation of above DSL: each equal method is returning only one Constraint:

Second limit is related with overloaded addSubview implementation:

This method is accepting [Constraint]. To explain why it is a limitation I would like to share with you what I would like to achieve with this kind of DSL. I would like to express only with one helper method that I would like to pin all subview’s edges to all edges of its superview:

To enable this concept pinAllEdges function has to return list of Constraints instead of returning only one. Let’s look at pinAllEdges implementation:

As you can notice I’m adding results of equal functions. To make it possible I was not overloading + operator. To make that trick possible I used the fact that + operator is implemented for arrays. Let’s look at my equal function signature:

This equal function is returning [Constraint]. Because of that fact I can mix results of my helper functions with results of equal function:

To make it all working overloaded addSubview method has to be modified a little:

Now addSubview accepts [[Constraint]] instead of [Constraint]. It’s creating actual NSLayoutConstraints and flattening list of lists to just a list of NSLayoutConstraint and at the end it’s activating all of constraints.

This powerful trick enables you to introduce your own helper layout methods. It’s very flexible and because of that fact I called it extensible extension. Let’s say you would like to have a helper to pin subview to the center of its parent. It’s very easy to add using extended version of Micro Auto Layout DSL:

It’s wonderful, isn’t it?

The whole implementation of my improvement can be found here: https://gist.github.com/adiki/6cc4e3b16b3f933f7181c76bc6a52a8d

That’s it! I hope you enjoyed it ;)

My github: https://github.com/adiki/

Next week: Simple trick to improve handling cells in UITableView and UICollectionView