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.

La storia è semplice e ha anche risvolti tristi: Ve la racconto perchè scommetto che anche a Voi sarà capitato una cosa simile.

Il committente ci propone la realizzazione di un software molto complesso, dotato di una robusta logica di funzionamento, ma che riusciamo a creare nei tempi e modi previsti.

Questo ovviamente applicando i pattern di programmazione corretti nonchè tutte le ultime tecnologie del caso.

Insomma: tutti contenti, soprattutto noi che siamo riusciti anche a rispettare i tempi di realizzazione !

Sin qui sembra una storia a lieto fine ma….. c’è sempre un ma sopratutto nella vita di chi fa software per mobile….

Dopo aver iniziato il deploy del nostro fantastico software su centinaia di dispositivi, tra i più disparati, l’iniziale soddisfazione diffusa si trasforma in poche ore in momenti di panico e notti insonne.

In altri termini in un baleno avviene la trasformazione: da sultano del codice (come simpaticamente mi chiamano i miei colleghi) a ultimo-dei-miei-cani.

Infatti su alcuni di questi dispositivi il “fantastico” inizia a fare stravaganze e comportamenti anomali.

Nemmeno a dirlo uno di questi dispositivi in cui il nostro software fa le bizze è quello dell’executive dell’azienda: ovviamente lo stramaledetto device incriminato non è tra quelli in nostro possesso e che usiamo per il testing su dispositivi reali.

Anche i simulatori non ci aiutano a identificare il problema il quale, a peggiorare le cose, si presenta pure in modo sporadico.

Per quello che mi riguarda tutte le volte che mi capita una cosa simile inizio a a pensare che forse ho sbagliato a fare questo lavoro, che forse mi dovevo occupare di qualche attività più manuale che, una volta terminata, difficilmente propone recrudescenze e/o comportamenti aleatori e sporadici da risolvere a tempo zero.

Ma a nulla vale ripensare al passato, e a quell’amico che ha aperto una piccola azienda nel campo edilizio e si è recentemente comprato una macchina spaventosamente bella, nemmeno a dirlo molto più bella della mia che, per inciso, dentro inizia  ad avere il muschio ma “ora non è il momento di cambiarla perchè non posso spendere”. E che (sempre il suddetto amico) sono certo non ha tutte le rotture di scatole che possiamo avere noi faticatori del codice nell’affrontare problemi così aleatori che non si riescono nemmeno a riprodurre.

Un mattone un volta posato difficilmente inizia a muoversi ma solo in alcune ore della giornata, e solo con alcune persone vicino…

L’invidia è una brutta bestia… lo so….

Come potete immaginare dalla moltitude di articoli dedicati a questo argomento è da tempo che uso con soddisfazione nelle mobile-app Xamarin l’SDK Microsoft.Azure.Mobile.Client.

Nota importante prima di proseguire.

Vi posso assicurare che non ci guadagno nulla a fare pubblicità a questo strumento: parola di giovane marmotta.

Ma onestamente quello di cui sto parlando è un SDK che mi ha levato dall’impiccio svariate volte, e quindi nutro per esso un affetto da “fratello minore” (…forse anche un pò minorato ?!).

Infatti il Microsoft.Azure.Mobile.Client mi ha permesso, con poco sforzo, di introdurre nelle mie “meravigliose” app la connessione con database in hosting su Azure, nonchè anche di introdurre il famigerato offline-sync: tutto questa senza cimentarmi in codice autoprodotto, sicuramente stimolante da creare, ma molto difficile da ottimizzare e manuntenere.

Finita la premessa, devo dire che è da tanto tempo che non riscontravo alcun problema nell’utilizzo di questo stumento: in generale il codice che usa questo framework abbisogna di ben poca manutenzione.

Giusto uno sguardo ogni tanto per non far sentire le solution sole (secondo me i progetti hanno sentimenti anche umani…), e un bell’update dopo aver letto “religiosamente” i release note relativi, e infine una bella esecuzione di tutti gli unit-test per vedere che tutto funzioni come previsto.

Però qualche giorno fa dopo qualche aggiornamento mi accorgo che non funziona più una beneamata.

L’SDK propone tutta una serie di errori lì negli stessi punti dove una volta dava molte soddisfazioni.

Infatti il comando PullAsync semplicemente sputava fuori un maledetto errore !

The server did not provide a response with the expected content

Dopo gli accidenti di rito, ho inziato a ricercarne le cause.

Questo e(o)rrore, come noto agli sfortunati che se lo sono trovati tra i piedi, ha mille origini e trovarne la cause è spesso un pò rognoso: anche il log lato Azure non mi ha dato alcun risultato valido (non si vedeva alcun errore: per lui tutto era perfetto).

Il problema è andato avanti per alcuni giorni, e francamente non sono riuscito dapprima a trovare alcuna causa scatenante: ho anche aperto un ticket in M$ e, come spesso capita, quando è arrivato il momento di mostrare la rogna non sono più riuscito a riprodurre il problema ! Misteri dell’informatica……..

Xamarin vers. 3.5 ha portato un’interessante novità: il Bindable Layout.

Devo ammettere che la prima volta che ne ho letto non mi ha convinto per nulla: mi sembrava la classica “soluzione in cerca di un problema”.

Però poi mi sono sforzato di “trafficarci” per vedere se mi poteva essere utile e mi sono reso conto che, come spesso capita, non ne avevo capito una cippa: in effetti questa nuova feature è in grado di fornire un valido strumento per poter risolvere velocemente un bel po’ di rogne.

Per questo motivo mi sono deciso a scriverne qualcosa, in modo tale da fissare le mie idee sull’argomento.

Che cappero è il Bindable Layout ?

Penso che tutti Voi conosciate la classi Layout e i suoi derivati: questi rappresentano le classi container delegate a contenere e posizionare in modo automatico e nel modo corretto i controlli figlio.

Alcuni esempi notevoli: Absolute Layout, Stack Layout, Grid.