Atlas: un approccio unificato al ciclo di sviluppo mobile in IQUII

Pubblicato da IQUII il 29/11/2017 in Thinking

Come sviluppatori passiamo una buona parte del nostro tempo scrivendo, riscrivendo o facendo refactoring di codice già esistente; per qualcuno di noi si tratta di un lungo percorso di crescita professionale che ha come obiettivo un po’ utopico quello di ottenere il vero clean code.

Altri invece non hanno ancora colto uno dei principi cardine dell’ingegneria del software: evitare quanto più possibile di reinventare la ruota, promuovendo il riutilizzo del codice, sopratutto quando si ha a che fare con più prodotti.

Far crescere i propri prodotti su solide basi non solo è un buon modo per evitare rework in corsa, ma consente un ciclo di sviluppo per gli aggiornamenti più agile e meno complesso.

Con un ciclo più snello gli aggiornamenti sono più veloci, possono comprendere più funzioni e hanno un impatto sui tempi di sviluppo più limitato (un bel vantaggio sia per chi sviluppa sia per chi ha a che fare con i tempi).

Cos’è Atlas

La stragrande maggioranza delle applicazioni odierne comunicano in qualche modo con dei server ricevendo o inviando dati per poi presentarli all’utente.
Pur trattandosi solo di un tassello all’interno di ogni progetto è chiaro come esso sia però di fondamentale importanza; è proprio per questo motivo che il nostro progetto di standardizzazione dei processi di sviluppo mobile in IQUII è iniziato da questa componente.

Il progetto Atlas nasce con l’ambizioso obiettivo di creare un layer intermedio tra quello che è il codice applicativo, il sistema operativo e le varie SDK sottostanti; questo include un layer di rete, uno di persistenza, una metodologia comune per l’architettura, una gestione semplificata per le push, le impostazioni e tutto quello che solitamente è parte di una app mobile.

I benefit dietro un progetto del genere sono molteplici:

• Concentrarsi sul prodotto. Con delle solide basi su cui basare i progetti possiamo concentrarsi su quello che davvero conta: l’esperienza utente e le funzionalità, in una parola il prodotto;
• Stabilità. Con una codebase unificata tra i progetti (e cicli di Unit Testing) il codice risulta più testato, gli aggiornamenti e fix risolvono bug e aggiungono funzionalità che vengono riportate automaticamente su tutti i programmi che ne fanno uso.
• Standardizzare il ciclo di sviluppo. Con un team allineato su una metodologia comune, lo sviluppo risulta più snello e la capacità di switch tra progetti – tipica in ambienti di consulenza – non è più motivo di frustrazione per i membri del team.

Abbiamo chiamato questo progetto Atlas come il titano che fu costretto da Zeus a tenere sulle spalle l’intera volta celeste: nella stessa maniera anche il nostro framework vuole essere lo strumento sul quale poggiare i prodotti presenti e futuri realizzati in IQUII.

In questa prima parte vedremo nel dettaglio come è stata realizzata la parte networking di Atlas; successivamente avremo modo di raccontare nel dettaglio le altre parti.

Come NON realizzare un layer di rete

Alzi la mano chi, per realizzare un layer di rete, non si è mai affidato ad un singleton dove aggiungere tutte le chiamate di rete utilizzate nella propria applicazione.

Purtroppo si tratta di uno scenario abbastanza comune, anche tra gli sviluppatori più senior: in effetti si tratta della maniera più veloce con cui approcciare questo genere di problemi.

Non fraintendetemi: non sono tra chi crede che i singleton siano il male: il fatto è che questo genere di approccio va volontariamente contro uno dei principi cardine del buon software: il Single Responsibility Principle.

A prescindere dalla definizione che possiamo quando parliamo di buon codice, una caratteristica risulta però imprescindibile: il buon codice deve essere mantenibile nel tempo, adattandosi a cambiamenti che, si vogliano o no, fanno parte di un normale ciclo di vita.

Codice che risulta scarsamente adattabile, dove ogni modifica è motivo di frustrazione per il team, richiede un tempo largamente superiore alle stime e rischia di generare regressioni è un codice che diventa velocemente ingestibile e quindi obsoleto (richiedendo di conseguenza continui rework non previsti).

In qualunque codice di scarsa qualità si può sempre trovare una class con più di una responsabilità.

In un layer di rete di questo tipo il singleton è a conoscenza di ogni cosa; dalla connessione, ai path di ogni richiesta, all’utente attivo e ad altri elementi dell’app fintanto – nei casi peggiori – perfino view controller dell’interfaccia.
In pratica tutto vive all’interno di una grossa grassa classe che rende impossibile un sano testing e meno che mai operazioni dependency injection o unit testing.

let service: Service = ...
let rq = Request(.post, "save/article/{art_cat}/id/{art_id}", ["art_id" : 55, "art_cat": "scifi"])
rq.timeout = 5 // if not specified Service's global timeout is used
rq.body = RequestBody.json(["text" : "bla bla bla", "author": "Me"])
 
service.execute(rq, retry: 3).then( { response in
 // response ok, read inside
}).catch({ err in 
 // request fail with error
})

public class LoginOp<T: UserModelProtocol>: AtlasOperation<T> {

  public init(email: String, password: String) {
    super.init()
    self.request = Request(method: .post, endpoint: type.endpoint)
    self.tokenRefreshAllowed = false
    self.request?.headers = [Constants.Headers.Authorization.rawValue : nil] // remove auth header
    self.request?.body = RequestBody.json(["email": email, "pwd": password])
    self.request?.cachePolicy = URLRequest.CachePolicy.reloadIgnoringCacheData
    self.onGenerateOutputModel = { json in
      let newUser = T(json["data"])
      return newUser
    }
  }
}

public extension AtlasService {

  public func login<T: UserModelProtocol>(email: String, pwd: String) -> Promise<T> {
    return Promise<T>({ r, rj, st in
      LoginOp<T>(email: email, password: pwd).in(self.app).exec().then({ loggedUser in
        self.app.setLoggedUser(loggedUser)
        r(loggedUser)
      }).catch({ err in
        rj(err)
      })
    })
  }

}

App.network.login(email: "...", pwd:: "...").then { user in
 // asynchronously return logged user
}.catch({ err in
 // something went wrong
})

public let App: Application = Application.main

public class Application {
  /// Main singleton reference.
  public static var main: Application = Application()

  /// Configuration
  internal var configuration: AppConfiguration!

  /// Main Networking service
  public lazy var network: AtlasService

  /// Currently logged user
  public private(set) var loggedUser: UserModelProtocol? = nil

  ... // and much more...
}