Condividi tramite

Passare da Windows Runtime 8.x a UWP

  • Articolo

Se si dispone di un'app Universal 8.1, se è destinato a Windows 8.1, Windows Phone 8.1 o entrambi,; quindi si scopre che il codice sorgente e le competenze verranno convertiti senza problemi su 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 Guida alle app UWP.

Durante la conversione, si troverà che Windows 10 condivide la maggior parte delle API con le piattaforme precedenti, oltre al markup XAML, al framework dell'interfaccia utente e agli strumenti e troverai tutto familiare. Come in precedenza, si può comunque scegliere tra C++, C# e Visual Basic per il linguaggio di programmazione da usare insieme al framework dell'interfaccia utente XAML. I primi passaggi per pianificare esattamente cosa fare con l'app o le app correnti dipenderanno dai tipi di app e progetti disponibili. Ciò è spiegato nelle sezioni seguenti.

Se si dispone di un'app Universal 8.1

Un'app Universal 8.1 viene compilata da un progetto di app Universal 8.1. Si supponga che il nome del progetto sia AppName_81. Contiene questi sottoprogetti.

  • AppName_81.Windows. Questo è il progetto che compila il pacchetto dell'app per Windows 8.1.
  • AppName_81.WindowsPhone. Questo è il progetto che compila il pacchetto dell'app per Windows Phone 8.1.
  • AppName_81.Shared. Si tratta del progetto che contiene codice sorgente, file di markup e altre risorse e asset usati da entrambi gli altri due progetti.

Spesso, un'app di Universal Windows 8.1 offre le stesse funzionalità, e lo fa usando lo stesso codice e markup, sia nei moduli Windows 8.1 che in Windows Phone 8.1. Un'app di questo tipo è un candidato ideale per la conversione in una singola app di Windows 10 destinata alla famiglia di dispositivi universali (e che è possibile installare nella gamma più ampia di dispositivi). Si convertirà essenzialmente il contenuto del progetto condiviso e sarà necessario usare poco o nulla dagli altri due progetti perché non ci saranno pochi o niente in essi contenuti.

Altre volte, il formato Windows 8.1 e/o Windows Phone 8.1 dell'app contiene funzionalità univoche. Oppure contengono le stesse funzionalità, ma implementano tali funzionalità usando tecniche diverse o tecnologie diverse. Con un'app come questa, si può scegliere di convertirla in una singola app destinata alla famiglia di dispositivi universali (nel qual caso vuoi che l'app si adatti a dispositivi diversi) oppure puoi scegliere di convertirla come più app, ad esempio una destinata alla famiglia di dispositivi desktop e un'altra alla famiglia di dispositivi Mobili. La natura dell'app Universal 8.1 determinerà quale di queste opzioni è migliore per il caso specifico.

  1. Convertire il contenuto del progetto condiviso in un'app destinata alla famiglia di dispositivi universali. Se applicabile, salvare qualsiasi altro contenuto dai progetti Windows e WindowsPhone e usare tale contenuto in modo incondizionato nell'app o condizionale nel dispositivo in cui l'app viene eseguita al momento (quest'ultimo comportamento è noto come adattivo).
  2. Convertire il contenuto del progetto WindowsPhone in un'app destinata alla famiglia di dispositivi universali. Se applicabile, salvare qualsiasi altro contenuto dal progetto Windows, usandolo in modo incondizionato o adattivo.
  3. Convertire il contenuto del progetto Windows in un'app destinata alla famiglia di dispositivi universali. Se applicabile, salvare qualsiasi altro contenuto dal progetto WindowsPhone, usandolo in modo incondizionato o adattivo.
  4. Convertire il contenuto del progetto di Windows in un'app destinata alla famiglia di dispositivi Universal o Desktop e convertire anche il contenuto del progetto WindowsPhone in un'app destinata alla famiglia di dispositivi universali o mobili. È possibile creare una soluzione con un progetto condiviso e continuare a condividere il codice sorgente, i file di markup e altre risorse tra i due progetti. In alternativa, è possibile creare soluzioni diverse e condividere gli stessi elementi usando i collegamenti.

Se si ha un'app Windows 8.1

Convertire il progetto in un'app destinata alla famiglia di dispositivi universali o desktop. Se si sceglie la famiglia di dispositivi Universal e l'app chiama le API implementate solo nella famiglia di dispositivi desktop, si possono proteggere tali chiamate con codice adattivo.

Se si ha un'app Windows Phone 8.1

Convertire il progetto in un'app destinata alla famiglia di dispositivi universali o Mobili. Se si sceglie la famiglia di dispositivi Universal e l'app chiama le API implementate solo nella famiglia di dispositivi Mobili, si possono proteggere tali chiamate con codice adattivo.

Adattamento dell'app a più fattori di forma

L'opzione scelta tra le sezioni precedenti 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, se 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 una conversione stretch-goal, e ci sono alcuni esempi in pratica nei case study Bookstore2 e QuizGame.

Approccio alla conversione livello per livello

Quando si trasferisce un'app universale 8.1 nel modello per le app UWP, praticamente tutte le conoscenze e l'esperienza verranno trasferite, come la maggior parte del codice sorgente e del markup e dei modelli software usati.

  • 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, il markup e la 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 Framework (incluse le API per l'accesso ai dati). E queste API sono disponibili anche per le app UWP, quindi la maggior parte se non tutto questo codice verrà convertito senza modifiche.
  • 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 l'app può 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 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 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.

Argomento Descrizione
Conversione del progetto Sono disponibili due opzioni quando si inizia il processo di conversione. Uno consiste nel modificare una copia dei file di progetto esistenti, incluso il manifesto del pacchetto dell'app (per tale opzione, vedi le informazioni sull'aggiornamento dei file di progetto in Eseguire la migrazione delle app alla piattaforma UWP (Universal Windows Platform)). L'altra opzione consiste nel creare un nuovo progetto Windows 10/11 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 molto bene dalle app Universal 8.1 alle app UWP. La maggior parte del markup è compatibile, anche se potrebbe essere necessario apportare alcune modifiche alle chiavi delle risorse di sistema o ai modelli personalizzati in uso.
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.
Caso di studio: Bookstore1 Questo argomento presenta un case study sulla conversione di un'app Universal 8.1 molto semplice in un'app UWP di Windows 10 e Windows 11. Un'app Universal 8.1 è una che compila un pacchetto di app per Windows 8.1 e un pacchetto di app diverso per Windows Phone 8.1. Con Windows 10 e Windows 11, 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. Vedere Guida alle app UWP.
Caso di studio: Bookstore2 Questo case study, basato sulle informazioni fornite nel controllo SemanticZoom. Nel modello di visualizzazione, ogni istanza della classe Author rappresenta il gruppo dei libri scritti da tale autore e in SemanticZoom è possibile visualizzare l'elenco di libri raggruppati per autore oppure eseguire lo zoom indietro per visualizzare un jump list di autori.
Caso di studio: QuizGame Questo argomento presenta un case study sulla conversione di un'app di esempio WinRT 8.1 funzionante per un gioco di quiz peer-to-peer in un'app UWP di Windows 10 e Windows 11.

Documentazione