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……..
Ovviamente “il nostro” si è ripresentato dopo qualche giorno.
L’unico modo che ho trovato per risolvere è stato quello di riportare “indietro” i progetti alla versione precedente eseguendo l’undo di qualsiasi aggiornamento applicato.
Finalmente dopo aver “pregato” per svariati giorni sono riuscito a trovare il bandolo della matassa: il tutto è causato da qualche “incomprensione” tra i vari moduli del framework e Android su come decomprimere i paccheti ricevuti dalla trama Http.
Quindi la causa scatenante è da ricercarsi in un mix velenoso di versioni di Xamarin.Forms, Microsoft.Azure.Mobile.Client e target version/compile version del progetto Android.
Tutti queste parti una volta andavano d’amore e daccordo… ma si sa: se non c’è un pò di baruffa l’amora fa la muffa…..
La soluzione, come spesso capito, è molto semplice, e posso riassumerla con il pezzo di codice nel seguito, che varia il modo con cui si instanzia la classe mobileserviceclient.
var client = new MobileServiceClient(applicationURL, new HttpClientHandler());
Vi riporto in linkografia il link che spiega meglio tutto, e propone anche altre soluzioni.
Infatti nel mio caso reale l’handler è una subclasse autoprodotta: questo al fine di poter gestire in modo sensato retry in caso di connessioni farlocche.
Pertanto la soluzione che ho adottato è stata leggermente più rognosa, ma il concetto espresso dalla riga sopra ritengo sia esplicativa.
Per tutti gli altri casi il link indicato direi che tratta ampiamente tutti gli casi.
Linkografia
Follow