dotSwift 2016 Highlights, part 2

In the first part, we started with a couple of helpful talks providing important analysis and insights (make sure you read it before moving on).

I wanted this second part to be more on the practical side, in terms of useful and quickly applicable tips for the daily job. And of course, as you may have guessed already; it’s all about successfully mixing generics and protocols here.

Going Swift and Beyond

In between the “What, How and Why” visions from the talk, a naive approach for a fairly common scenario was also given.

Write Swift not just for the sake of writing Swift; but to write better code.

Picture this: a normal class with constant stored properties and the common way to initialize it

It is likely to happen that, after some time, we now need this class to also be able to get initialized in some other manner. This could also mean that our stored properties would probably have to wait to get initialized later on (e.g for this second way we need to fetch some resources in a background thread).

And we can easily make this happen: by relying on optionals and the assumption that our objects don’t need to get constructed at the early beginning, we can just add another initializer in order to fit our needs.

But of course, this comes at a price: our objects are not immutable anymore. We have to deal with optional unwrapping everywhere and the chance that those objects may be nil now. Also, and probably more important, our code is not as easy to maintain as before.

This is when generics and protocols come really handy. First, Ayaka pointed out how we could easily think about outsourcing this new behaviour somewhere else. Probably, creating a different struct or class to handle this new scenario and deciding how to load our class would be much better.

But we could also create generic structures on some type which conforms to a protocol. This conforming type, then, will be the one responsible for deciding how to load the respective classes.

What is more interesting here is that we no longer need to change our initial class. All we have to do is model our new logic to be used by some class which at the same time will be initialized by this new generic object type which promises a function. Let’s translate this new idea with some code:

Now, with this in mind, just try to replace it with a real word example: UIViewControllers which, after some time, need to also handle deep linking. Then, UIViewController Containers which get initialized with something that implements a function, and use it in order to load some resource from a deep link and add the desired child view controllers.

Got it? Then, check it out for yourself!

Summing up:

- Careful with optionals: having lots of them might be a code smell
- Try to think in generic terms when outsourcing new components

Tiny networking in Swift

An early table football game preceded a hint for what was going to be shown here. Chris was really enjoying the Tiki-Taka style and the ambience so there was also room for some good chatting:

“I’m glad you liked the section regarding Generics in the Advanced Swift book. Indeed, my live coding session is all about it”

I must admit: I don’t always write my tests; but I always make sure I write testable code.

In a really cool live coding session with no slides at all, we were introduced how easy is to design our code thinking in generic terms. Step by step, the speaker identified which parts of an existing codebase could be refactored to be more generic and reused.

Building from scratch a simple tiny network client loading a couple of resources can be the perfect scenario to demonstrate this, as well as an enjoyable experience.

In this case, as the quote denotes, we want to isolate the testable part of our network layer. Eventually, we will have Resource structs which are generic on some type and know how to parse this type. How did we get there?

Starting from a simple loadSomeResource() method which loads and parses the already mentioned SomeResource.

The first step to refactor it would be to be given the url and the parsing method to be used.

The final step would then be to move this two parameters into a generic struct to be used anywhere else when needed.

Later on, we can use this resource to make our view controller agnostic on which content is being loaded. If we want to go one step further, we could even make our view controllers agnostic on its own table view behaviour, by providing generic closures that will be in charge of configuring the cell as well as performing some action when the cell is selected.

Finally, the speaker pointed out an attractive fact: the app specific code of the application was about 10 lines of code. All the rest of the code that he just built straight away was part of a potential and reusable framework to be used somewhere else in that or any other application, without having to change much of it.

Bottom line:

- Start simple, refactor with generics when possible
- Building your own framework is not as daunting as it seems

Others

- Async code with Futures

Interesting talk on how we could improve Swift adding APIs to deal with asynchronous programming. To illustrate this, Thomas introduces Futures, a Promises like framework to build better asynchronous code.

I see this as a suggestive idea for future Swift versions, since I believe this small subset of Signals and Streams from Reactive programming frameworks is by far its strongest point.

- Views as lego blocks

This reminded me a lot about Facebook’s ComponentKit or React: a functional declarative way of building UI code.

The difference and what really amazed me about the one introduced here is that they also aim to support Auto Layout, so definitely this lightning talk is worth a watch.

- A fairytale on POP

Because programming paradigms and video game stories are not that far away from each other 😂

Conclusion

Attending dotSwift was an unforgettable experience. Beyond all the new stuff we could learn from in a tech conference and the networking opportunities, there’s a really amazing fact: even though Swift community is huge and full of both experienced and young talent, there is still a great room for improvement; and we just have to take advantage of it.

p.s: don’t miss the rest of the conference videos at The dot Post.

Joan Romano, mobile software engineer from Barcelona currently based in Austria. You can reach me on Twitter.