Hello Queens and Kings, Leo here. The topic today is Point of Synchronization in Swift. But what does it mean?

Today I’ll start one series about everything related to the iOS interview process. The history started here: the Babylon health iOS github . There you can see that shared all their interviewing process and I could think of some insights to share, this post is dedicated to one of the requirements for the Babylon iOS interview demo project.

The demo project consists of a list of photos. Upon tapping any photo, the user is taken to the photo detail screen. When a photo is tapped, you should go to the Photo detail screen. Also, a photo that is marked favorite shows up first in the list followed by other photos.

The project requirements are: should be Swift 5, stutter and crash-free UI, the information should be available offline ( so you will have to use some persistence structure), and goes on. But one of those requirements pop into my eyes was  “Have a point of synchronization (e.g. making two concurrent requests and waiting for both of them to finish).”. Well, that’s interesting but how can we do that?

 

Interview Advice

I recommend for everyone go check that GitHub project specifically the Interview questions part. There you can prepare for other iOS interview processes and be more confident in your next interviewing process.

If you're a mid/senior iOS developer looking to improve your skills and salary level, join this 100% free online crash course. It's available only until April 28th, so click to get it now!

My 5 cents about the interview process that I always keep in mind is that is a 2-way process. The company is assessing you as a possible future employee but you too are getting information about it to make an informed decision if it’s a great company to work for or if it’s not fit for your purposes.

The painting I choose is The 1821 Derby at Epsom an 1821 painting by Théodore Géricault, representing all the threads running asynchronously but all the bets will only be paid when all the horses completed their track, the final point of synchronization.

No more talk, let’s code.

 

Problem – Point of Synchronization in Swift

You have an interview demo project and are asked to have a point of synchronization in it.

The first sight might be overwhelming to see these requirements.

A lot of questions come to your mind immediately. For example, should I handle multiple generic calls? Should I synchronize the persistence part? Should I make the sync process in the background doing the screen diff outside the main thread and after that set the UI? Well, all that questions are valid but I came to a very simple solution to this.

Remember this post about DispatchGroup ? Apple already solved this requirement for us with the Dispatch Framework, aka GCD. The dispatch group can synchronize anything you want, including asynchronous network calls.

Imagine that you have to asynchronously call the FAANG sites ( Facebook, Amazon, Apple, Netflix, Google) and you also want to do some action only after all the network calls have returned :

let dispatchGroup = DispatchGroup() // 1
let endpoints = [URL(string: "https://www.facebook.com")!,
URL(string: "https://www.amazon.com")!,
URL(string: "https://www.apple.com")!,
URL(string: "https://www.netflix.com")!,
URL(string: "https://www.google.com")!]

First (mark 1) we have to create a dispatchGroup to handle the point of synchronization.

This will be the point of synchronization of our example:

endpoints.forEach {
    let request = URLRequest(url: $0)
    dispatchGroup.enter() // 1
    URLSession.shared.dataTask(with: request) { (_, response, _) in
        print(" endpoit completed = \(response?.url?.absoluteString ?? "")" )
        dispatchGroup.leave() // 2
    }.resume()
}

dispatchGroup.notify(queue: .main) {
    print("All requests ended") // 3
}

print("All request started") // 4

Mark 4 is executed first because the requests didn’t have the time to complete and as our code is asynchronous, it would continue until the end of the func.

On mark 1 you will enter in an async context managed by a dispatchGroup. DispatchGroups allow you to aggregate a set of tasks and synchronize behaviors in the group. You attach multiple work items to a group and schedule them for asynchronous execution on the same queue or different queues.

Finally, when all work items finish executing, the group executes its completion handler. You can also wait synchronously for all tasks in the group to finish executing. And on mark 2 you leave that context managed by the DispatchGroup.

Mark 3 is the real point of synchronization. When the dispatch group enters that closure is guaranteed that all the group enters already have left, this way in your code you can just take an action after all the calls are completed.

The result of the code above is:

This image is the result of Result of example of an examplePoint of Synchronisation in Swift

And that’s it!

If you're a mid/senior iOS developer looking to improve your skills and salary level, join this 100% free online crash course. It's available only until April 28th, so click to get it now!

 

Exploring DispatchGroups

The order of execution can be controlled using DispatchWorkItem, so the work you want to perform is encapsulated in a way that lets you attach a completion handle or execution dependencies.

 

Learn More

SOLID is a legendary acronym that probably all developers in the world at one time or another found during their learning years. The Liskov substitution Principle is one of the main techniques to achieve reliable OO code to your code base. Learn how to use it in Swift in this article.

Every time you use a String in Swift you are using implicitly a Hashable type. But what that means? Check that and much more information about Hashes and Swift in this article.

 

Summary – Point of Synchronization in Swift an Interview Problem

To answer the requirement you don’t need to use complex structures or go too far just to impress. It’s always important that readability and easy-to-maintain code are far more important than clever code. When we write code, we never write for ourselves, we write a letter to someone in the future ( sometimes that person in the future is you, but who knows?).

That’s all my people, I hope you liked reading this article as much as I enjoyed writing it. If you want to support this blog you can Buy Me a Coffee or leave a comment saying hello. You can also sponsor posts and I’m open to freelance writing! You can reach me on LinkedIn or Twitter and send me an e-mail through the contact page.

Thanks for reading and… That’s all folks.

Credits: image