Xamarin: Come pubblicare su play store con formato aab

Come saprete certamente recentemente Google ha cambiato il formato con cui è possibile sottoporre le app al suo store: il vecchio formato apk va in pensione in favore del nuovo e scintillante aab.

I vantaggi di questo “pensionamento” sono molteplici, e qui non mi dilungherò: lascio in particolare in linkografia alcuni documenti che ho trovato utili per comprenderne qualcosa in più.

Comunque pur avendone letto negli scorsi mesi devo ammettere che ho continuato a pubblicare le nuove versioni delle app alle quali lavoro sempre in apk, ma solo per sciatteria, lasciandomi il battesimo con aab alla prima occasione utile.

Infatti da quello che ho potuto verificare sino alla data odierna aggiornamenti di app esistenti accettano ancora il vecchio e glorioso formato apk: nuove app devono giocoforza usare aab.

Qualche giorno l’occasione di usare questo nuovo formato è arrivata, e devo dire che arrivare in fondo, e riuscire a pubblicare la mia nuova app con il nuovo formato, non è stato affatto semplice o banale: anzi è stato un vero e proprio percorso a ostacoli.

Piccola/grande nota:so perfettamente che devops nonchè anche le buone norme di programmazione intimano che il deploy dovrebbe essere automatico e quindi che il processo di cui parlo in queste righe dovrebbe essere completamente automatico.

Però io ho inziato a programmare ai tempi ai tempi in cui se eri ricco avevi ben 64 KB di memoria, altrimenti se eri poveraccio (come il sottoscritto) dovevi accontentarti di 8 KB: per questo alcune operazioni preferisco farmele ancora a mano, “alla vecchia maniera”.

Proprio per questo ho deciso di scrivere questo post per aiutare i tapini come me in questo processo, non certo complicato, ma che nasconde alcune insidie: al termine di queste note potrete vantarVi anche Voi in giro di usare aab per le Vostre app.

La prima operazione da fare è convincere Visual Studio a produrre il file di setup di Android nel formato corretto.

Continue reading

Inversion of Control e dintorni: Dependency Injection – parte 3 di 3

Nel post precente ho introdotto il pattern Dependency Injection, facente parte della famiglia di pattern IoC: qui discuterò, invece, del pattern Service Locator.

Proseguendo con l’esempio esposto nelle precedenti puntate il problema da risolvere è che la classe DirectoryController, presentata nei post precedenti, non rispetta il principio Dependency Inversion Principle. Infatti dipende pesantemente dalla classe utilizzata per il logging.

Abbiamo già dato una prima soluzione, ma in questa parte daremo una versione alternativa.

In questa caso invece di passare la classe da usare per il logging nel costruttore, o in un metodo o proprietà, (vedi Dependency Injection) ci si affida a uno “store centrale”, che memorizza tutte le associazioni interfaccia-istanza dell’oggetto da utilizzarsi.

Quindi usando questo store è possibile prelevare l’instanza della classe logger di interesse.

Più facile a vedersi con un esempio che a descrivere.

Continue reading

Inversion of Control e dintorni: Dependency Injection – parte 2 di 3

Nel post precente ho introdotto cosa si intende per SOLID e cosa ci “azzecca” IoC.

In estrema sintesi la regola D relativa a SOLID (DIP = Dependency Inversion Principle) può essere rispettata usando il pattern Ioc Inversion Of Control, in una delle sue due varianti: Dependency Inversion o Service Locator.

Il questo post verrà descritta la prima variante (Dependency Injection) che ritengo essere il metodo più semplice per implementare il pattern IoC e quindi risolvere il principio Dependency Inversion Principle (DIP).

Ricordo questo principio (esemplificando) afferma che non dovrebbero esistere due pezzi di codice che dipendono direttamente l’uno dall’altro.

Nel nostro esempio abbiamo la classe DirectoryController che dipende pesantemente dalla classe LogWriter e dalla classe LogWriterOnEventViewer.

In definitiva ecco l’implementazione.

Continue reading

Inversion of Control e dintorni: Dependency Injection – parte 1 di 3

Qualche tempo fa stavo mettendo mano al codice scritto da un altro collega programmatore e, dopo aver verificato che il tutto era scritto sicuramente in modo molto originale ed efficace, ho anche notato che il risultato non rispettava, nemmeno da lontano, alcun principio SOLID.

In particolare il principio Dependency Inversion Principle (per gli amici DIP) che permette, tra l’altro, di scrivere unit test in modo veloce, era stato “bellamente” ignorato.

Dopo aver discusso con l’autore mi sono reso conto che il problema era che lui non aveva la minima conoscenza di questo argomento, pur essendo un ottimo programmatore. Per questo motivo ho pensato di scrivere queste poche righe, nella speranza che possano essere utili anche ad altri.

Continue reading