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

Nota importante.

Vi posso assicurare che non ci guadagno nulla a fare pubblicità a questo strumento: parola di giovane marmotta. Detta in termini più semplici non non me ne viene in tasca assolutamente nulla se decidete o meno di adottarlo.

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 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........

In questo post esporrò i passi necessari per trasformare un progetto Blazor in una progressive web-app (per gli amanti degli acronimi PWA).

E’ possibile pensare alle PWA come a una evoluzione delle web-app, però dedicate alla piattaforma mobile

Le caratteristiche distintive di una PWA sono le seguenti.

  • Sono dotate di una user interface il cui aspetto è molto vicino a quella di una app mobile nativa.
  • Sono installabili in modo simile a una app native in modo tale da poterle aggiungere, per esempio, alla schermata home senza necessità di ricordare l’URL del sito o salvarlo nei preferiti del browser. In questo modo l’icona appare nel dispositivo proprio come fosse una normale app).
  • Possono funzionare offline senza alcuna connettività.
  • Sono in grado di utilizzare le push-notification.

Non lasciate traviare dal fatto che sinora si è parlato di mobile: infatti oramai le PWA sono andare ben oltre e ora tali applicazioni sono disponibili e utilizzate per mondo desktop.

Da Visual Studio 2019 Preview approntate tutto per creare un nuovo progetto: scegliendo la voce Blazor sarà possibile al set di template dedicati.

Template tipo 1 - Blazor Server App (anche chiamata al bar amichevolmente Blazor server-side)

Template tipo 2 - Blazor WebAssembly App (al bar viene chiamato Blazor client-side)

Template tipo 3 - Blazor WebAssembly App hosted in Asp.Net Core (anche chiamata amichevolmente Blazor client-side hosted in Asp.Net core server)

Oss.: Giustamente potete osservare che le voci proposte dal nostra amato Visual Studio sono solo due, ma prima di pensare che possa aver detto una fesseria date un’occhiata al flag in basso a destra nominato Asp.Net Core hosted: questo permette di creare i template 2 e 3. Lo stesso flag è indisponibile se si sceglie il template 1.

I template esposti propongono in sostanza due “hosting-model” di Blazor: il primo template permette un hosting di tipo server-side, gli altri due client-side.

Ora parlare del modello di hosting model Blazor così, a freddo, mi rendo conto che è un po' da sciagurati: ma ci provo lo stesso e, siccome il blog è mio e decido io cosa metterci, ho deciso di proporre in questo momento questi concetti, in modo tale che nel prossimo li possiate raffinare e comprendere appieno.

Torniamo bomba: i template 2 e 3 predispongono dei progetti nei quali il codice in esecuzione sul browser sarà scritto in C# e mandato in esecuzione nel browser con l’ausilio di webassembly.

Ma quale è la differenza tra questi due template ? Il template 2 è una pura web-app Blazor: in pratica crea solo i file necessari a essere mandati in esecuzione sul browser, e quindi è una pura web-app client-side.

In questo ultimo periodo anche io ho subito il fascino di Blazor, il nuovo sistema framework per scrivere web-app in salsa M$.

Sin dal primo momento che mi sono approcciato all’argomento mi sono reso conto che questo l’argomento è veramente una gran figata: so di non essere molto professionale ad usare un termine del genere, ma direi che rende l’idea di quello che umilmente ne penso.

Di questo nuovo framework mi è da subito piaciuto da subito l’approccio alla programmazione proposto, non certo elegante, ma efficace e comprensibile.

Eppoi questo stile di programmazione, che miscela HTML con C#, mi ricorda i tempi gloriosi di asp/vbscript: boh, non so, forse è una mia idea balorda, ma alcuni punti di incontro tra questi due mondi così lontani nel tempo francamente li vedo.

In modo meno prosaico posso continuare dicendo che la cosa che più mi ha convinto di Blazor è la possibilità di scrivere web-app dotate di una robusta logica di funzionamento lato client (Angular-style per capirsi) senza dover utilizzare nulla che ha a che fare con javascript o typescript.

Per inciso: contro javascript non ho nulla, semplicemente è un linguaggio che non mi è mai piaciuto molto. ….tra di noi non c’è mai stata la scintilla, ecco…... Anche il suo cugino typescript non mi ha mai convinto eccessivamente.

Inoltre un’altro motivo a supporto di questa "mancata simpatia è il seguente". Sino all’arrivo di Blazor per implementare una moderna web-app occorreva scrivere il codice costitutivo utilizzando C# (o similari) per implementare la logica lato server, e quindi utilizzare forzatamente javascript o typescript per implementare la logica lato client.

Questo continuo switch “della testa” tra due linguaggi mi ha sempre messo in difficoltà: sarà anche l’età ?!?!?!

Comunque sia con Blazor possiamo dimenticarci (..o quasi) di usare javascript/typescript per scrivere codice che implementa logica lato client, e usare sempre e comunque C#, il che secondo me non è cosa da poco.