Every mature and modern programming languages come with an official solution for code distribution to share and reuse code that has been already written. The mechanism to share, distribute and re-use the code is usually handled by the package manager. The examples of popular package managers are RubyGems for Ruby, Composer for PHP, NPM for NodeJS, Gradle for Java etc, which not only provides official solutions but also has centralised repositories to host packages created by developers. However, Apple is an exception to this, the languages like Objective-C and Swift has been released to the public without having officially supported package management solution or having centralised repositories to host packages. This gives an opportunity for the third-party companies or developers to build an unofficial tooling to manage the packages for the Objective-C or Swift. That’s the reason the tools like Cocoapods and Carthage hits the market and gains popularity.
Mobile applications are usually multi-threaded. We perform UI operations on the main thread and dispatch heavy tasks (e.g. network requests, JSON parsing, writing to a file on a disk) on background threads. The iOS allows us to use backgrounds threads for example by using Grand Central Dispatch API (GCD), i.e. by performing operations on DispatchQueue objects. Work dispatched to a background DispatchQueue is usually done asynchronously with queue.async{} call.
If we wanted to test an object that uses a queue to perform work in background, we would use an XCTestExpectation and wait for an async operation to finish. We can fulfil the expectation in a callback.
In the first part of this series we covered dependency injection, a crucial part of testable code and a great principle for any codebase — even if you’re not writing tests. Today, let’s talk about how we can continue coding confidently with interfaces.