Conversione da Windows Runtime 8.x a UWP per modello di app, dispositivo e I/O

L'argomento precedente era Conversione di XAML e interfaccia utente.

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.

Ciclo di vita dell'applicazione (gestione della durata dei processi)

Per un'app universale 8.1, è presente una "finestra di debounce" di due secondi tra l'inattività dell'app e il sistema che genera l'evento di sospensione. L'uso di questa finestra di debounce come tempo aggiuntivo per sospendere lo stato non è sicuro e per un'app piattaforma UWP (Universal Windows Platform), non è presente alcuna finestra di debounce. L'evento di sospensione viene generato non appena un'app diventa inattiva.

Per altre informazioni, vedere ciclo di vita dell'app.

Audio in background

Per la proprietà MediaElement.AudioCategory, ForegroundOnlyMedia e BackgroundCapableMedia sono deprecati per le app di Windows 10. Usare invece il modello di app Windows Phone Store. Per maggiori informazioni, vedere Audio in background.

Rilevamento della piattaforma in cui è in esecuzione l'app

Il modo di concepire la destinazione delle app è diverso in Windows 10. Il nuovo modello concettuale è che un'app è destinata alla piattaforma UWP (Universal Windows Platform) ed eseguita in tutti i dispositivi Windows. Si può quindi scegliere di accendere le funzionalità esclusive di specifiche famiglie di dispositivi. Se necessario, l'app ha anche la possibilità di limitarsi alla destinazione di una o più famiglie di dispositivi in modo specifico. Per altre info sulle famiglie di dispositivi e su come decidere quale famiglia di dispositivi usare come destinazione, vedere Guida alle app UWP.

Se si dispone di codice nell'app Universal 8.1 che rileva il sistema operativo in cui è in esecuzione, potrebbe essere necessario modificare tale codice a seconda del motivo della logica. Se l'app passa il valore e non agisce su di essa, si potrebbe voler continuare a raccogliere le informazioni del sistema operativo.

Nota È consigliabile non usare il sistema operativo o la famiglia di dispositivi per rilevare la presenza di funzionalità. L'identificazione del sistema operativo o della famiglia di dispositivi corrente non è in genere il modo migliore per determinare se è presente una particolare funzionalità del sistema operativo o della famiglia di dispositivi. Invece di rilevare il sistema operativo o la famiglia di dispositivi (e il numero di versione), verificare la presenza della funzionalità stessa (vedere Compilazione condizionale e codice adattivo). Se è necessario richiedere un particolare sistema operativo o famiglia di dispositivi, assicurarsi di usarlo come versione minima supportata, invece di progettare il test per tale versione.

 

Per personalizzare l'interfaccia utente dell'app in dispositivi diversi, sono disponibili diverse tecniche consigliate. Continuare a usare gli elementi di ridimensionamento automatico e i pannelli di layout dinamico man mano che li si ha sempre. Nel markup XAML continuare a usare dimensioni in pixel effettive (in precedenza pixel di visualizzazione) in modo che l'interfaccia utente si adatti a risoluzioni e fattori di scala diversi (vedere Pixel effettivi, distanza di visualizzazione e fattori di scala). Usare i trigger adattivi e i setter di Visual State Manager per adattare l'interfaccia utente alle dimensioni della finestra (vedere Guida alle app UWP).

Tuttavia, se si ha uno scenario in cui è inevitabile rilevare la famiglia di dispositivi, è possibile farlo. In questo esempio viene usata la classe AnalyticsVersionInfo per passare a una pagina personalizzata per la famiglia di dispositivi mobili, se appropriato, e assicurarsi di eseguire il fallback a una pagina predefinita in caso contrario.

   if (Windows.System.Profile.AnalyticsInfo.VersionInfo.DeviceFamily == "Windows.Mobile")
        rootFrame.Navigate(typeof(MainPageMobile), e.Arguments);
    else
        rootFrame.Navigate(typeof(MainPage), e.Arguments);

L'app può anche determinare la famiglia di dispositivi su cui è in esecuzione dai fattori di selezione delle risorse che sono in vigore. L'esempio seguente illustra come eseguire questa operazione in modo imperativo e l'argomento ResourceContext.QualifierValues descrive il caso d'uso più tipico per la classe nel caricamento di risorse specifiche della famiglia di dispositivi in base al fattore della famiglia di dispositivi.

var qualifiers = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues;
string deviceFamilyName;
bool isDeviceFamilyNameKnown = qualifiers.TryGetValue("DeviceFamily", out deviceFamilyName);

Vedere anche Compilazione condizionale e codice adattivo.

Ufficio

Quando un'app che dichiara la funzionalità Location nel manifesto del pacchetto dell'app viene eseguita in Windows 10, il sistema richiederà all'utente finale il consenso. Questo vale se l'app è un'app di Windows Phone Store o un'app di Windows 10. Pertanto, se l'app visualizza una richiesta di consenso personalizzata o se fornisce un interruttore attivato, è necessario rimuoverlo in modo che all'utente finale venga richiesto una sola volta.