Linee guida per la conversione delle app desktop

  • Articolo

La maggior parte del codice dell'applicazione può essere suddivisa in una delle aree seguenti:

  • Codice dell'interfaccia utente (ad esempio finestre e pulsanti)
  • Controlli di terze parti (ad esempio grafici)
  • Logica di business (ad esempio, regole di convalida)
  • Archiviazione e accesso ai dati locali
  • Servizi Web e accesso remoto ai dati

Per Windows Form e applicazioni WPF scritte con C# (o Visual Basic.NET) una quantità sorprendente di logica di business, accesso ai dati locali e codice dei servizi Web può essere condivisa tra piattaforme.

.NET Portability Analyzer

Visual Studio 2017 e versioni successive supportano .NET Portability Analyzer (download per Windows) che può esaminare le applicazioni esistenti e indicare quanto codice può essere convertito "così com'è" in altre piattaforme.

È anche possibile scaricare uno strumento da riga di comando da Portability Analyzer in GitHub e usare per fornire gli stessi report.

"x% del mio codice è portabile. Cosa succederà?"

Speriamo che l'analizzatore mostri una grande parte del codice è portabile, ma sicuramente ci saranno alcune parti di ogni app che non possono essere spostate in altre piattaforme.

Diversi blocchi di codice probabilmente rientrano in uno di questi bucket, come illustrato più dettagliatamente di seguito:

  • Codice portabile riabilitabile
  • Codice che richiede modifiche
  • Codice non portabile e richiede una riscrizione

Codice portabile riabilitabile

Il codice .NET scritto sulle API disponibili in tutte le piattaforme può essere modificato in più piattaforme. Idealmente, sarà possibile spostare tutto questo codice in una libreria di classi portabile, una libreria condivisa o una libreria .NET Standard e quindi testarla all'interno dell'app esistente.

Tale libreria condivisa può quindi essere aggiunta ai progetti dell'applicazione per altre piattaforme (ad esempio Android, iOS, macOS).

Codice che richiede modifiche

Alcune API .NET potrebbero non essere disponibili in tutte le piattaforme. Se queste API sono presenti nel codice, sarà necessario riscrivire tali sezioni per usare le API multipiattaforma.

Ad esempio, l'uso delle API Reflection disponibili in .NET 4.6, ma non disponibili in tutte le piattaforme.

Dopo aver riscritto il codice usando LE API portabili, dovrebbe essere possibile creare un pacchetto del codice in una libreria condivisa e testarlo all'interno dell'app esistente.

Codice non portabile e richiede una riscrizione

Esempi di codice che probabilmente non sono multipiattaforma includono:

  • Interfaccia utente: Windows Form o le schermate WPF non possono essere usate nei progetti in Android o iOS, ad esempio. L'interfaccia utente dovrà essere riscritta, usando questo confronto dei controlli come riferimento.

  • Archiviazione specifica della piattaforma: codice che si basa su una tecnologia specifica della piattaforma, ad esempio un database SQL Server Express locale. Sarà necessario riscrivirlo usando un'alternativa multipiattaforma, ad esempio SQLite per il motore di database. Alcune operazioni del file system possono anche essere modificate, perché UWP ha API leggermente diverse per Android e iOS (ad esempio, alcuni file system fanno distinzione tra maiuscole e minuscole e altri no).

  • Componenti di terze parti : controllare se i componenti di terze parti nelle applicazioni sono disponibili in altre piattaforme. Alcuni, ad esempio i pacchetti NuGet non visivi, potrebbero essere disponibili, ma altri (in particolare controlli visivi come grafici o lettori multimediali)

Suggerimenti per rendere portabile il codice

  • Inserimento delle dipendenze : fornire implementazioni diverse per ogni piattaforma e

  • Approccio a più livelli: sia MVVM, MVC, MVP o un altro modello che consente di separare il codice portabile dal codice specifico della piattaforma.

  • Messaggistica : è possibile usare il passaggio di messaggi nel codice per rimuovere le interazioni tra diverse parti dell'applicazione.