Head First Mobile Application Architecture

If we try to measure the time spent by software engineers discussing current application architectures and inventing new ones. We would have to come up with a new measurement unit with scary monster view controllers which is always trying to become MVC and start growing as a View Controller that forces you to use code generators to create those 5-6 classes needed to add a single label architecture that will leave you wondering.

Mobile application architecture

Main features

⦁ Less extra classes means less “where do I put it” thoughts.
⦁ Making the most of Xcode features and UIKit capabilities.
⦁ Simplified testing.
⦁ Overall simple approach.

Outline the basic concepts

⦁ We use Resift to glue the different layers of our application. It also helps us to solve asynchronous tasks
⦁ We try to move everything from our View Controller, but without fanaticism
⦁ We use dependency injection to separate our classes
⦁ We use logs to represent dependencies to simplify mocking and testability

Warm up

First we need to add dependencies. I’m using Cocoapods and you can explore the Podfile in our repository to get an idea of ​​what we’ll need. Put in all the required constraints and create outputs for these two objects so we can use them in our view controller.

Network layer

To get the data from the network, we’ll need a concrete class that accepts parameters, gets the data, and wraps it into our value types using their Decodable conformance. Perhaps one day Swift will allow us to have stored properties in protocol extensions, and we’ll finally be able to use the full power of partially implemented abstractions, but even now this approach is a powerful way to duplicate code.

⦁ Set the activity state to true.
⦁ Request source.
⦁ Confirm answer.
⦁ Set activity state to false.
⦁ Parse and wrap into a value object.
⦁ Handle the error.

View model

Finally we got to the final assembly. We will start the pre-flight checks by defining the variables.

Unit testing

Now we will add some tests that will serve as the icing on the cake. First, let’s implement a mock NetworkManager that simply returns the necessary JSON.

Conclusion

Our view controller still handles the necessary presentation logic, but anything beyond that is moved to other classes. We can easily extend this scheme by introducing other classes with acting as glue.