Recently I have been implementing a lot of analytics events in a client’s app. Tagging this application (which has a great deal of UI) was always going to a laborious task, so I was looking to architect an ergonomic API to interact with.
Whilst deciding on the interface I remembered the Swift 5.3 feature that allows enum cases to be used as protocol witnesses. This became a great teaching opportunity for the junior I was pairing with. In short, a
protocol that requires a
static function that returns
Self can be satisfied by an
case with an associated value…
For many years now, the go-to way of encoding and decoding Swift types to
JSON has been the
This gave a more type safe way of handling json than its predecessor
JSONSerialization, which spat out
[String: Any] dictionaries. Conversely
Codable handles conversion upfront, dealing with all the type conversion, and failing if the object cannot be converted successfully.
An additional advantage of
Codable is that conformance can be synthesised for many objects if they only contain other
Codable or simple types.
One place common place where
Codable conformance cannot be synthesised is when using enums…
Recently I discovered that tuples can be used to easily and simply compare and equate multiple variables.
Take for example the implementation of
Comparable taken from the Swift documentation:
This compares the year, month and day in that order to determine which is greater (later). A simpler (and perhaps more readable) way of writing this same code is this:
The tuple is compared in order of its variables so we achieve the same result.
As an added bonus, the same is true for Equatable conformance:
This last one is a bit of a contrived example as
Equatable conformance would be synthesised for
Date anyway, but suppose we wanted to omit the year, to compare birthdays, it would be very easy to simply remove
year from the tuples
One of the biggest downsides to
UIGestureRecognizer is the inability to attach simple closures in-line. To use them, a target object must be specified alongside a
Selector pointing to a function to call.
One major disadvantage to this paradigm is that
UIGestureRecognizer only passes the calling object to the called function. This means that if multiple objects call the same function, they need to be differentiable in some way.
Out of curiosity I looked for a solution online. Many suggest using the Objective C runtime to add an Associated Object to manage a closure, but this gets into the realm…
The Coordinator pattern has become increasingly popular recently in handling navigation through an iOS apps without tightly coupling different view controllers.
There are a number of great articles that explain the various flavours of the pattern fantastically, so I’ll not rehash the same detail again.
There is, however, one area which causes problems for many of these implementations and problem is the
UINavigationController’s back button.
Ideally we would have the Coordinator handle all navigation interactions directly, however the back button does not allow for its action to be modified as it is directly tied to the navigation controller.
Many swift developers will know that any function without an explicit return type specified will return
Usually, ignoring the return type produces the following warning:
However, this is not the case for functions returning
Void (or we’d have warnings everywhere!) This becomes clear when using the