Passare da Silverlight per Windows Phone a UWP

  • Articolo

Se si è uno sviluppatore con un'app di Silverlight per Windows Phone, è possibile sfruttare al meglio il set di competenze e il codice sorgente nel passaggio a Windows 10. Con Windows 10 puoi creare un'app UWP (Universal Windows Platform), ovvero un singolo pacchetto di app che i clienti possono installare in ogni tipo di dispositivo. Per altre informazioni su Windows 10, le app UWP e i concetti relativi al codice adattivo e all'interfaccia utente adattiva che verranno menzionati in questa guida alla conversione, vedere la Guida alle app Universal Windows Platform (UWP).

Quando si converte l'app di Windows Phone Silverlight in un'app di Windows 10, si potranno recuperare le funzionalità per dispositivi mobili introdotte in Windows Phone 8.1 e andare molto oltre esse per usare la piattaforma UWP (Universal Windows Platform) il cui modello di app e il framework dell'interfaccia utente sono universali in tutti i dispositivi Windows 10. Ciò consente di supportare PC, tablet, telefoni e un gran numero di altri tipi di dispositivi, da una codebase e con un pacchetto di app. E questo moltiplica il potenziale pubblico dell'app e creerà nuove possibilità con dati condivisi, prodotti di consumo acquistati e così via. Per altre info sulle nuove funzionalità, vedere Novità per gli sviluppatori in Windows 10.

Se si sceglie questo, la versione di Windows Phone Silverlight dell'app e la versione di Windows 10 possono essere entrambi disponibili per i clienti contemporaneamente.

Nota Questa guida è progettata per aiutare a convertire manualmente l'app di Windows Phone Silverlight in Windows 10. Oltre a usare le informazioni contenute in questa guida per convertire l'app, è possibile provare l'anteprima per sviluppatori di Silverlight Bridge di Mobilize.NET per automatizzare il processo di conversione. Questo strumento analizza il codice sorgente dell'app e converte i riferimenti in controlli Windows Phone e API Silverlight nelle controparti UWP. Poiché questo strumento è ancora in anteprima per sviluppatori, non gestisce ancora tutti gli scenari di conversione. Tuttavia, la maggior parte degli sviluppatori dovrebbe essere in grado di risparmiare tempo e fatica iniziando con questo strumento. Per provare l'anteprima per sviluppatori, visitare il sito Web di Mobilize.NET.

XAML e .NET o HTML?

Windows Phone Silverlight ha un framework dell'interfaccia utente XAML basato su Silverlight 4.0 e si programma con una versione di .NET Framework e un piccolo subset di API di Windows Runtime. Poiché si è usato Extensible Application Markup Language (XAML) nell'app di Windows Phone Silverlight, è probabile che XAML sia la scelta per la versione di Windows 10 perché la maggior parte delle conoscenze ed esperienze verrà trasferita, come gran parte del codice sorgente e dei modelli software usati. Anche il markup e la progettazione dell'interfaccia utente possono essere trasferiti facilmente. Si trovano le API gestite, il markup XAML, il framework dell'interfaccia utente e gli strumenti con tutta tranquillità e si può usare C++, C# o Visual Basic insieme a XAML in un'app UWP. Si potrebbe essere sorpresi di quanto sia relativamente facile il processo, anche se c'è una sfida o due lungo la strada.

Vedere Roadmap per le app piattaforma UWP (Universal Windows Platform) con C# o Visual Basic.

Nota Windows 10 supporta molto più di .NET Framework rispetto a un'app di Windows Phone Store. Ad esempio, Windows 10 include diversi spazi dei nomi System.ServiceModel.* come di System.Net, System.Net.NetworkInformation e System.Net.Sockets. Quindi, ora è un ottimo momento per convertire Windows Phone Silverlight e avere il codice .NET appena compilato e funzionante sulla nuova piattaforma. Vedere Mapping di spazi dei nomi e classi. Un altro ottimo motivo per ricompilare il codice sorgente .NET esistente in un'app di Windows 10 è il vantaggio di .NET Native, che una tecnologia di compilazione in anticipo che converte MSIL in codice computer eseguibile in modo nativo. Le app .NET Native vengono avviate più velocemente, usano meno memoria e meno batteria rispetto alle controparti MSIL.

Questa guida alla conversione si concentrerà su XAML, ma in alternativa si può creare un'app equivalente a livello funzionale, chiamando molte delle stesse API di Windows Runtime, usando JavaScript, Css (Cascading Style Sheets) e HTML5 insieme alla libreria Windows per JavaScript. Anche se i framework dell'interfaccia utente di Windows Runtime di XAML e HTML sono diversi l'uno dall'altro, a seconda che uno scelto funzioni universalmente nell'intera gamma di dispositivi Windows.

Destinazione della famiglia di dispositivi mobili o universale

Una delle opzioni disponibili consiste nel convertire l'app in un'app destinata alla famiglia di dispositivi universali. In questo caso, l'app può essere installata nella gamma più ampia di dispositivi. Se l'app chiama le API implementate solo nella famiglia di dispositivi mobili, è possibile proteggere tali chiamate con codice adattivo. In alternativa, è possibile scegliere di convertire l'app in un'app destinata alla famiglia di dispositivi mobili, nel qual caso non è necessario scrivere codice adattivo.

Adattamento dell'app a più fattori di forma

L'opzione scelta tra la sezione precedente determinerà la gamma di dispositivi in cui verrà eseguita l'app o le app e che potrebbe essere una vasta gamma di dispositivi. Anche limitando l'app alla famiglia di dispositivi mobili lascia comunque una vasta gamma di dimensioni dello schermo da supportare. Quindi, poiché l'app verrà eseguita su fattori di forma che non supportavano in precedenza, testare l'interfaccia utente su questi fattori di forma e apportare eventuali modifiche necessarie in modo che l'interfaccia utente si adatti in modo appropriato a ogni elemento. Si può pensare a questo è un'attività post-conversione, o un obiettivo di trasferimento di estensione, ed è un esempio pratico nel case study Bookstore2.

Approccio alla conversione livello per livello

  • Visualizzazione. La visualizzazione (insieme al modello di visualizzazione) costituisce l'interfaccia utente dell'app. Idealmente, la vista è costituita da markup associato a proprietà osservabili di un modello di visualizzazione. Un altro modello (comune e pratico, ma solo a breve termine) è per il codice imperativo in un file code-behind per modificare direttamente gli elementi dell'interfaccia utente. In entrambi i casi, la maggior parte di markup e progettazione dell'interfaccia utente, nonché il codice imperativo che modifica gli elementi dell'interfaccia utente, saranno semplici da convertire.
  • Visualizzare modelli e modelli di dati. Anche se non si abbracciano formalmente modelli di separazione dei problemi (ad esempio MVVM), nell'app è inevitabilmente presente codice che esegue la funzione del modello di visualizzazione e del modello di dati. Il codice del modello di visualizzazione usa i tipi negli spazi dei nomi del framework dell'interfaccia utente. Sia il modello di visualizzazione che il codice del modello di dati usano anche api non visive e .NET (incluse le API per l'accesso ai dati). E la maggior parte di queste funzionalità è disponibile per un'app UWP, in modo da poter convertire gran parte di questo codice senza modifiche. Tenere presente, tuttavia, che un modello di visualizzazione è un modello o un'astrazione di una vista. Un modello di visualizzazione fornisce lo stato e il comportamento dell'interfaccia utente, mentre la visualizzazione stessa fornisce gli oggetti visivi. Per questo motivo, qualsiasi interfaccia utente adattata ai diversi fattori di forma in cui la piattaforma UWP consente di essere eseguita probabilmente richiederà modifiche del modello di visualizzazione corrispondenti. Per le reti e le chiamate ai servizi cloud, in genere è possibile usare le API .NET o Windows Runtime. Per i fattori coinvolti nel prendere tale decisione, vedere Servizi cloud, rete e database.
  • Servizi cloud. È probabile che alcune delle app (forse molte di queste) vengano eseguite nel cloud sotto forma di servizi. La parte dell'app in esecuzione nel dispositivo client si connette a tali app. Questa è la parte di un'app distribuita che probabilmente rimane invariata durante la conversione della parte client. Se non se ne ha già uno, una buona opzione per i servizi cloud per l'app UWP è Servizi mobili di Microsoft Azure, che offre potenti componenti back-end che le app Universal Windows possono chiamare per servizi che vanno da semplici notifiche per gli aggiornamenti dei riquadri animati fino al tipo di scalabilità pesante che può offrire una server farm.

Prima o durante la conversione, valutare se l'app potrebbe essere migliorata eseguendo il refactoring in modo che il codice con uno scopo simile venga raccolto insieme in livelli e non sparsi in modo arbitrario. Il factoring dell'app UWP in livelli come quelli descritti in precedenza semplifica la corretta esecuzione dell'app, il test e successivamente la lettura e la gestione. È possibile rendere le funzionalità più riutilizzabili ed evitare alcuni problemi di differenze dell'API dell'interfaccia utente tra le piattaforme, seguendo il modello Model-View-ViewModel (MVVM). Questo modello mantiene i dati, le attività aziendali e le parti dell'interfaccia utente dell'app separate l'una dall'altra. Anche all'interno dell'interfaccia utente può mantenere lo stato e il comportamento separati e testabili separatamente dagli oggetti visivi. Con MVVM è possibile scrivere i dati e la logica di business una sola volta e usarli in tutti i dispositivi, indipendentemente dall'interfaccia utente. È probabile che sia possibile riutilizzare la maggior parte del modello di visualizzazione e visualizzare anche le parti tra i dispositivi.

Una o due eccezioni alla regola

Durante la lettura di questa guida alla conversione, è possibile fare riferimento ai mapping di spazi dei nomi e classi. Il mapping piuttosto semplice è la regola generale e la tabella dei mapping di spazi dei nomi e classi descrive tutte le eccezioni.

A livello di funzionalità, la buona notizia è che c'è molto poco che non è supportato nella piattaforma UWP. La maggior parte del set di competenze e del codice sorgente si traduce molto bene nelle app UWP, come si leggerà nel resto di questa guida alla conversione. Tuttavia, ecco le poche funzionalità di Silverlight di Windows Phone che si potrebbe aver usato per cui non esiste un equivalente UWP.

Funzionalità per cui non esiste un equivalente UWP Documentazione di Windows Phone Silverlight per la funzionalità
Microsoft XNA. In generale, Microsoft DirectX che usa C++ è la sostituzione. Vedere Sviluppo di giochi e interoperabilità DirectX e XAML. Libreria di classi Framework XNA
App lens Lenti per Windows Phone 8

 

Argomento Descrizione
Mapping di spazi dei nomi e classi Questo argomento fornisce un mapping completo delle API di Silverlight di Windows Phone agli equivalenti UWP.
Conversione del progetto Per iniziare il processo di conversione, creare un nuovo progetto Windows 10 in Visual Studio e copiarvi i file.
Risoluzione dei problemi È consigliabile leggere la fine di questa guida alla conversione, ma si è anche consapevoli che si è ansiosi di proseguire e passare alla fase in cui il progetto viene compilato ed eseguito. A tal fine, è possibile fare progressi temporanei commentando o stubando qualsiasi codice non essenziale e quindi restituendo per pagare il debito in un secondo momento. La tabella dei sintomi e dei rimedi per la risoluzione dei problemi in questo argomento può essere utile in questa fase, anche se non è un sostituto per la lettura dei prossimi argomenti. È sempre possibile fare riferimento alla tabella mentre si procede con gli argomenti successivi.
Conversione di XAML e dell'interfaccia utente La pratica di definire l'interfaccia utente sotto forma di markup XAML dichiarativo traduce estremamente bene da Windows Phone Silverlight alle app UWP. Si scoprirà che le sezioni di grandi dimensioni del markup sono compatibili dopo aver aggiornato i riferimenti alla chiave di risorsa di sistema, modificato alcuni nomi dei tipi di elemento e modificato "clr-namespace" in "using".
Conversione per I/O, dispositivo e modello di app Il codice che si integra con il dispositivo stesso e i relativi sensori implica l'input da e l'output all'utente. Può anche comportare l'elaborazione dei dati. Tuttavia, questo codice non è generalmente considerato come il livello dell'interfaccia utente o il livello dati. Questo codice include l'integrazione con il controller di vibrazione, l'accelerometro, il giroscopio, il microfono e l'altoparlante (che si intersecano con il riconoscimento vocale e la sintesi vocale), la posizione geografica e le modalità di input, ad esempio tocco, mouse, tastiera e penna.
Conversione dei livelli aziendali e di dati Dietro l'interfaccia utente ci sono i livelli aziendali e di dati. Il codice in questi livelli chiama le API del sistema operativo e .NET Framework (ad esempio, elaborazione in background, posizione, fotocamera, file system, rete e altro accesso ai dati). La maggior parte di queste funzionalità è disponibile per un'app UWP, in modo da poter convertire gran parte di questo codice senza modifiche.
Porting per il fattore di forma e l'esperienza utente Le app di Windows condividono un aspetto comune tra PC, dispositivi mobili e molti altri tipi di dispositivi. L'interfaccia utente, l'input e i modelli di interazione sono molto simili e un utente che si sposta tra i dispositivi accoglierà l'esperienza familiare.
Caso di studio: Bookstore1 Questo argomento presenta un case study sulla conversione di un'app Windows Telefono Silverlight in un'app UWP di Windows 10. Con Windows 10, si può creare un singolo pacchetto di app che i clienti possono installare in un'ampia gamma di dispositivi ed è ciò che faremo in questo case study.
Caso di studio: Bookstore2 Questo case study, basato sulle informazioni fornite in Bookstore1, inizia con un'app di Windows Phone Silverlight che visualizza i dati raggruppati in un LongListSelector. Nel modello di visualizzazione, ogni istanza della classe Author rappresenta il gruppo dei libri scritti da tale autore e in LongListSelector è possibile visualizzare l'elenco di libri raggruppati per autore oppure eseguire lo zoom indietro per visualizzare un jump list di autori.

Documentazione

Articoli di riviste

Presentazioni

  • La storia di portare Nokia Music da Windows Phone a Windows 8