How to write services for VIPER?

I can think about that you just simply began to jot down your first VIPER module and also you would possibly surprise: the place ought to I put all my community communication, CoreLocation, CoreData or “no matter service” code, that is not associated to the user interface in any respect?

To the service layer!

I often name these the API, location, storage as a service, as a result of they serve your modules with some sort of data. Plus they’ll encapsulate the underlying layer, offering a well-defined API interface in your VIPER modules. 😅

Okay, however what about interactors? Should not I implement this sort of stuff there?

Nicely, my reply isn’t any, as a result of there’s a main distinction between companies and interactors. Whereas a service is only a “dummy” wrapper arund e.g. a RESTful API, one other one across the CoreData storage, an interactor nonetheless may use each of them to request some sort of knowledge although the API, and put it aside regionally utilizing the storage service. Interactors also can do sorting, filtering, transformation between Knowledge Switch Objects (DTOs) and entities, extra about them later.

Sufficient concept for now, let’s create a brand new service.

Service interfaces

This time because the Protocol Goal Programming paradigm says:

We begin designing our system by defining protocols.

Our first one goes to be a very easy one for all of the companies:

protocol ServiceInterface: class 
    func setup()


extension ServiceInterface 

    func setup() 
        
    

The setup might be known as for every service throughout the service initialization course of. We will lengthen the bottom service so we do not have to implement this technique, however provided that we actually need to do one thing, like organising our CoreData stack.

Subsequent we are able to give you our API service, on this case I will implement a dummy endpoint that hundreds some knowledge utilizing the new Combine framework with URLSession, however after all you possibly can go together with completion blocks or Promises as properly.

protocol ApiServiceInterface: ServiceInterface 

    func todos() -> AnyPublisher<[TodoObject], HTTP.Error>

These days I am utilizing a HTTP namespace for all my community associated stuff, like request strategies, responses, errors, and so on. Be at liberty to increase it based mostly in your wants.

enum HTTP 

    enum Methodology: String 
        case get
        
    
    enum Error: LocalizedError 
        case invalidResponse
        case statusCode(Int)
        case unknown(Swift.Error)
    

As you possibly can see it is fairly light-weight, but it surely’s extraordinarily helpful. We’ve not talked in regards to the TodoObject but. That is going to be our very first DTO. 😱

Knowledge Switch Objects

A knowledge switch object (DTO) is an object that carries knowledge between processes. – wikipedia

On this case we’re not speaking about processes, however companies & VIPER modules. They exists so we are able to decouple our service layer from our modules. The interactor can remodel the DTO right into a module entity, so all different elements of the VIPER module might be utterly impartial from the service. Price to say {that a} DTO is often actually easy, in a RESTful API service, a DTO can implement the Codable interface and nothing extra or for CoreData it may be only a NSManagedObject subclass.

struct TodoObject: Codable 
    let id: Int
    let title: String
    let accomplished: Bool

It’s also possible to use a easy DTO to wrap your request parameters. For instance you should utilize a TodoRequestObject which might comprise some filter or sorting parameters. You would possibly observed that I at all times use the Object suffix for my DTO’s, that is a private desire, but it surely helps me differentiate them from entities.

Going just a little bit additional this fashion: you possibly can publish your complete service layer as an encapsulated Swift package deal utilizing SPM, from Xcode 11 these packages are natively supported so in case you’re nonetheless utilizing CocoaPods, it’s best to think about migrating to the Swift Package Manager as quickly as doable.

Service implementations

Earlier than we begin constructing our actual service implementation, it is good to have a pretend one for demos or testing functions. I name this pretend, as a result of we’ll return a hard and fast quantity of faux knowledge, but it surely’s near our real-world implementation. If our request would come with filtering or sorting, then this pretend implementation service ought to filter or type our response like the ultimate one would do it.

remaining class FakeApiService: ApiServiceInterface 

    var delay: TimeInterval

    init(delay: TimeInterval = 1) 
        self.delay = delay
    

    non-public func fakeRequest<T>(response: T) -> AnyPublisher<T, HTTP.Error> 
        return Future<T, HTTP.Error>  promise in
            promise(.success(response))
        
        .delay(for: .init(self.delay), scheduler: RunLoop.foremost)
        .eraseToAnyPublisher()
    

    func todos() -> AnyPublisher<[TodoObject], HTTP.Error> 
        let todos = [
            TodoObject(id: 1, title: "first", completed: false),
            TodoObject(id: 2, title: "second", completed: false),
            TodoObject(id: 3, title: "third", completed: false),
        ]
        return self.fakeRequest(response: todos)
    

I like so as to add some delay to my pretend objects, as a result of it helps me testing the UI stack. I am an enormous fan of Scott’s how to fix a bad user interface article. You need to positively learn it, as a result of it is wonderful and it’ll show you how to to design higher merchandise. 👍

Transferring ahead, right here is the precise “real-world” implementation of the service:

remaining class MyApiService: ApiServiceInterface 

    let baseUrl: String

    init(baseUrl: String) 
        self.baseUrl = baseUrl
    

    func todos() -> AnyPublisher<[TodoObject], HTTP.Error> 
        let url = URL(string: self.baseUrl + "todos")!
        var request = URLRequest(url: url)
        request.httpMethod = HTTP.Methodology.get.rawValue.uppercased()

        return URLSession.shared.dataTaskPublisher(for: request)
        .tryMap  knowledge, response in
            guard let httpResponse = response as? HTTPURLResponse else 
                throw HTTP.Error.invalidResponse
            
            guard httpResponse.statusCode == 200 else 
                throw HTTP.Error.statusCode(httpResponse.statusCode)
            
            return knowledge
        
        .decode(sort: [TodoObject].self, decoder: JSONDecoder())
        .mapError  error -> HTTP.Error in
            if let httpError = error as? HTTP.Error 
                return httpError
            
            return HTTP.Error.unknown(error)
        
        .eraseToAnyPublisher()
    

The factor is that we may make this even higher, however for the sake of simplicity I will “hack-together” the implementation. I do not just like the implicitly unwrapped url, and plenty of extra little particulars, however for studying functions it’s very nice. 😛

So the large query is now, find out how to put issues togehter? I imply we now have a working service implementation, a pretend service implementation, however how the hell ought to we put every thing into an actual Xcode venture, with out delivery pretend code into manufacturing?

Goal environments

Often you should have a reside manufacturing surroundings, a improvement surroundings, possibly a staging surroundings and a few extra for QA, UAT, or demo functions. Issues can range for these environments corresponding to the ultimate API url or the app icon, and so on.

This time I will arrange a venture with 3 separate environments:

• Manufacturing
• Growth
• Faux

If you happen to begin with a brand new venture you may have one main (non-test) goal by default. You may duplicate a goal by right-clicking on it. Let’s do that two instances.

I often go together with a suffix for the goal and scheme names, apart from the manufacturing surroundings, the place I take advantage of the “base identify” with out the -Manufacturing postfix.

As you possibly can see on the screenshot I’ve a primary folder construction for the environments. There needs to be a separate Information.plist file for each goal, so I put them into the correct Belongings folder. The FakeApiService.swift is just a part of the pretend goal, and each different file is shared. Wait, what the heck is a ServiceBuilder?

Dependency injection

A number of surroundings implies that we now have to make use of the best service (or configuration) for each construct goal. I am utilizing the dependency injection design pattern for this goal. A service builder is only a protocol that helps to realize this purpose. It defines find out how to setup companies based mostly on the surroundings. Let me present you the way it works.

protocol ServiceBuilderInterface 

    var api: ApiServiceInterface  get 

    func setup()


extension ServiceBuilderInterface 

    func setup() 
        self.api.setup()
    

Now for every goal (surroundings) I implement the ServiceBuilderInterface in an precise ServiceBuilder.swift file, so I can setup my companies simply as I would like them.

remaining class ServiceBuilder: ServiceBuilderInterface 

    lazy var api: ApiServiceInterface = 
        
        MyApiService(baseUrl: "https://jsonplaceholder.typicode.com")
    ()

I often have a base service-interactor class that can obtain all of the companies throughout the initialization course of. So I can swap out something with no trouble.

class ServiceInteractor 

    let companies: ServiceBuilderInterface

    init(companies: ServiceBuilderInterface = App.shared.companies) 
        self.companies = companies
    

DI is nice, however I do not prefer to repeat myself an excessive amount of, that is why I am offering a default worth for this property, which is situated in my solely singleton class known as App. I do know, singletons are evil, however I have already got an anti-pattern right here so it actually does not matter if I introduce yet another, proper? #bastard #singleton 🤔

remaining class App 

    let companies = ServiceBuilder()

    

    static let shared = App()

    non-public init() 
        
    

    

    func setup() 
        self.companies.setup()
    

This setup is extraordinarily helpful if it involves testing. You may merely mock out all of the companies if you wish to take a look at an interactor. It is also good and clear, as a result of you possibly can attain your strategies within the interactors like this: self.companies.api.todos()

You may apply the identical sample in your modules, I imply you possibly can have for instance a ModuleBuilder that implements a ModuleBuilderInterface and all of the routers can have them by way of DI, so you do not have to initialize every thing from scratch all of the tim utilizing the construct operate of the module. 😉

Nonetheless I wish to make clear yet another factor…

Object, mannequin, entity, what the…?

Just a little bit about naming conventions (I additionally use these as suffixes on a regular basis):

In my dictionary an Object is at all times a DTO, it solely lives within the service layer. It is a freakin dumb one, with none extra goal than offering a pleasant Swiftish API. This implies you do not have to take care of JSON objects or something loopy like that, however you possibly can work instantly with these objects, which is often a pleasant to have characteristic.

An Entity is said to a VIPER module. Its goal is to behave as a communication object that may be handed round between the view, interactor, presenter, router or as a parameter to a different module. It may encapsulate the native stuff that is required for the module. This implies if one thing modifications within the service layer (a DTO possibly) your module will be capable to work, you solely need to align your interactor. 😬

Nonetheless, generally I am utterly skipping entities, however I do know I should not. 🙁

A Mannequin refers to a view-model, which is a part of my component based UI building approach on high of the UICollectionView class. You need to take a look at the hyperlinks if you wish to study extra about it, the syntax is similar to SwiftUI, but it surely’s clearly not as high-level. In abstract a mannequin at all times has the information that is required to render a view, nothing extra and nothing much less.

I hope this little article will show you how to to construction your apps higher. VIPER may be fairly problematic generally, due to the way in which you need to architect the apps. Utilizing these sort of companies is a pleasant method to separate all of the totally different API connections, sensors, and plenty of extra, and at last please keep in mind:

Not every thing is a VIPER module.

You may obtain the supply information for this text utilizing The.Swift.Dev tutorials repository on GitHub. Thanks for studying, if you have not achieved it but please subscribe to my publication under, or ship me concepts, feedbacks by way of twitter. 👏