Nella scorso puntata ho esposto sommariamente cosa vuole dire svikuooare con MAUI: qui ora parleremo dell’evoluzione del framework nonché delle novità introdotte dalla versione 8.

Ma prima di tutto tenterò di dare il mio piccolo contributo su un’argomento che mi sta molto a cuore: ma MAUI è pronto per realizzare software da mettere in produzione ?

Is MAUI production-ready ?

Disclaimer: quanto Vi scriverò in questo capitolo è frutto di mie valutazioni prettamente personali.

Ecco il sunto estremo di cosa penso delle scorse revisioni di MAUI.

DotNet6: Un azzardo !
DotNet7: Usabile… ma solo per le demo… semplici
DotNet8: La vera 1.0

Sviluppo un pò ragionato sulla mia affermazione precedente (sempre se Vi interessa….)

MAUI è stato rilasciato in pompa magna con DotNet6. E’ stato dipinto da subito come la vera “promessa” per lo sviluppo mobile nonché l’evoluzione di Xamarin.

Purtroppo secondo me rilasciare MAUI in quel momento è stato un azzardo bello e buono, poiché era un prodotto ancora immaturo: chi si è avventurato ad usare per la produzione questa “promessa” si è ritrovato con la classica radio con il mattone dentro.

Da subito si sono riscontrati troppi bug e lentezze, e i pochi eroi che lo hanno iniziato ad usare da quella revisione hanno provato sulla propria pelle quanto Vi ho detto.

Secondo me (e non solo) sarebbe stato necessario ancora minimo un anno ancora per fixare almeno i tanti bug più rognosi, se non più, e quindi proporre una revisione più matura.

Con il tempo le cose sono, comunque, migliorate: dopo varie fix e sopratutto con la reversione 7 le cose hanno iniziato ad andare per il verso giusto.

Attenzione: non ho detto che tutto era perfetto, bensì che si è iniziato a vedere un sistema abbastanza affidabile, non dico pronto per la produzione ma almeno che si poteva iniziare a studiare seriamente.

Il vero difetto però della versione 7 era il “memory pressure”, oltre che una serie interminabile di altre piccolezze che obbligavano ad estenuanti ricerche e test per convincere per esempio la soft-key a stare doveva stare, ed altre piacevolezze simili.

Ma lavorare a questi bug queste cose mi ha permesso di toccare con mano il numero spaventoso di sviluppatori che lavorano con MAUI: allora come ora anche a fronte di problemi particolare si scova sempre qualcuno che ha avuto la stessa rogna ha rilasciato la fix con un nuget o un progetto su GitHub dove mostra il workaroud.

Questo, con onestà, mi dà parecchia fiducia sulla strumento e sui possibili sviluppi futuri.

Sempre riguardo ai tanti piccoli bug presenti versione 7 osservo che, in modo molto originale, non sono stati fixati in questa revisione, bensì sono stati corretti direttamente nella versione 8 in preview.

Questo ha reso obbligatorio per molti (compreso il sottoscritto) a usare in produzione la versione 8 in preview già da settembre dello scorso anno o anche prima (la versione 8 è uscita a Novembre).

Per quanto detto sopra posso affermare tranquillamente il seguente: la versione 8 di MAUI è in realtà la sua versione 1.0.

Le nuove novità di MAUI 8

• Desktop
• Perfomance + utilizzo di memoria
• BlazorView

Da quello che ho visto le novità più importanti della versione 8 di MAUI ricadono tutte in una delle tre tipologie sopra.

Per il desktop mancavano alcune cose che non permettevano l’utilizzo efficace in ambito desktop (vedi shortkey).

Doveroso il secondo punto: perfomance e utilizzo della memoria. Ora si inizia a ragionare !

Con la versione 8 è possibile finalmente mostrare una lista con qualche centinaio di foto e molte informazioni di riga usando CollectionView, senza il rischio di vedere l’applicativo andare in crash miseramente.

Quindi per completare la rosa delle modifiche della versione 8 diverse implementazioni per BlazorView, di cui parleremo a breve.

Quindi è possibile affermare che la versione 8 di MAUI è una versione di “consolidamento”, e che ha uno sguardo verso le BlazorView.

MAUI & iOS: amici o nemici ??

A questo punto della storia occorre fare il punto dei rapporti tra MAUI e iOS.

Inizio con il dire che questo rapporto è sempre stato molto conflittuale: la mia impressione è che Apple non sia mai stata troppo contenta di permettere ad applicativi scritti con strumenti origine M$ (vedi Xamarin prima e MAUI ora) di girare su iOS.

Chi ha usato Xamarin nel passato sa che in realtà sviluppare per iOS non è mai stata una passeggiata di salute.

C’è sempre stato una grossa difficoltà a far coesistere le versioni di macOS, con XCode e Visual Studio for MAC (la versione di Visual Studio pensato per il Mac): molte combinazioni, infatti, erano incompatibili, e quindi ad ogni aggiornamento di uno qualsiasi di questi elementi occorreva sempre andare a leggere la documentazione con attenzione.

Ora con MAUI le cose sono migliorate ?? Mi pare di sì.

Come è sviluppare per iOS usando MAUI ?

Iniziamo con il dire che è indispensabile nella pratica possedere una macchina MAC per produrre la versione dell’applicativo per iOS da sottoporre allo store.

Proseguo dicendo che, come detto prima, esiste una versione per Visual Studio che gira su MAC, Visual Studio for MAC, molto più semplice e minimale rispetto alla versione per Windows… ma il suo sporco lavoro lo fa…. o per meglio dire lo faceva…..

Purtroppo le cose sembrebbero facili, ma non lo sono nella pratica: Visual Studio for MAC è in end-of-support nei prossimi mesi.

A peggiorare tutto devo anche dirVi che usando questo editor NON è possibile usare la versione 8 di MAUI: al massimo si arriva alla versione 7.

E allora ????

Semplice (sulla carta): si può usare VSCode che gira meravigliosamente anche su Mac.

Questo nella teoria….

Infatti per sviluppare in MAUI con VSCode occorre installare una serie di plugin, e molti di questi sono ancora oggi in versione preview.

Quindi usare Maui su Mac usando VSCode è certo possibile, ma consiglio i più deboli di cuore di usare altre soluzioni.

E queste sono, ovviamente, IDE a pagamento che funzionano perfettamente su Mac, con MAUI anche in versione 8.

Quindi sul fronte editor utilizzabili direttamente su Mac direi che la situazione è abbastanza confusa, a meno che non si apra il portafoglio (e sapete come genovese come la penso su questo punto…).

Spero di aver fatto un pò di chiarezza….

Per completezza devo dirVi che è possibile usare da Windows il PairMac: cioè connettere l’istanza di Visual Studio in esecuzione su Windows alla sua controparte in esecuzione sul Mac via ssh.

Nella pratica, però, questa soluzione l’ho sempre trovata di una lentezza estenuante, e pertanto l’ho sempre scartata a priori e consiglio anche a Voi di non perderci del tempo.

Ultima cosa da segnalare come punto di contatto tra Apple e MAUI è iOS Hot Restart: con questo strumento è possibile connettere via usb un dispositivo iOS a un pc Windows per mandare in esecuzione (in debug) l’applicativo MAUI.

Utile, funziona bene, ma alla fine dovremo sempre sottoporre il pacchetto allo store Apple, e per fare questo è sempre necessario avere una Mac.

Fisico o virtuale…..

Spero di averVi dato qualche informazione utile, anche se infarcite di mie speculazioni personali.

Nel prossimo step parleremo del punto che mi sta più a cuore: le BlazorView, cioè il punto di contatto tra Blazor e Maui.