Conversione di Windows Phone Silverlight in UWP per I/O, dispositivo e modello di app

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)

L'app Windows Phone Silverlight contiene codice per salvare e ripristinare lo stato dell'applicazione e il relativo stato di visualizzazione per supportare la rimozione definitiva e successivamente riattivata. Il ciclo di vita delle app piattaforma UWP (Universal Windows Platform) ha forti paralleli con quello delle app di Windows Phone Silverlight, poiché sono entrambe progettate con lo stesso obiettivo di massimizzare le risorse disponibili per qualsiasi app che l'utente abbia scelto di avere in primo piano in qualsiasi momento. Si vedrà che il codice si adatterà facilmente al nuovo sistema.

Nota Se si preme il pulsante hardware Indietro, viene terminata automaticamente un'app di Windows Phone Silverlight. Premendo il pulsante hardware Indietro in un dispositivo mobile non viene terminata automaticamente un'app UWP. Al contrario, viene sospesa e quindi può essere terminata. Tuttavia, questi dettagli sono trasparenti per un'app che risponde in modo appropriato agli eventi del ciclo di vita dell'applicazione.

Una "finestra di debounce" è il periodo di tempo tra l'inattività dell'app e il sistema che genera l'evento di sospensione. Per un'app UWP, 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.

Fotocamera

Il codice di acquisizione della fotocamera Windows Phone Silverlight usa Microsoft.Devices.Camera, Microsoft.Devices.PhotoCamera o classi Microsoft.Phone.Tasks.CameraCaptureTask. Per convertire il codice nella piattaforma UWP (Universal Windows Platform), si può usare la classe MediaCapture. Nell'argomento CapturePhotoToStorageFileAsync è disponibile un esempio di codice. Questo metodo consente di acquisire una foto in un file di archiviazione e richiede che le funzionalità del dispositivo microfono e webcamda impostare nel manifesto del pacchetto dell'app.

Un'altra opzione è la classe CameraCaptureUI, che richiede anche le funzionalità del dispositivomicrofono e webcam.

Le app Lens non sono supportate per le app UWP.

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.

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 Visualizzare/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.

Stato dei dispositivi

Un'app Windows Phone Silverlight può usare la classe Microsoft.Phone.Info.DeviceStatus per ottenere informazioni sul dispositivo in cui è in esecuzione l'app. Anche se non esiste un equivalente UWP diretto per lo spazio dei nomi Microsoft.Phone.Info, ecco alcune proprietà ed eventi che si possono usare in un'app UWP al posto delle chiamate ai membri della classe DeviceStatus.

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. 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.

Orientamento

L'equivalente dell'app UWP delle proprietà PhoneApplicationPage.SupportedOrientations e Orientation è l'elemento uap:InitialRotationPreference nel manifesto del pacchetto dell'app. Selezionare la scheda Applicazione se non è già selezionata e selezionare una o più caselle di controllo in Rotazioni supportate per registrare le preferenze.

È tuttavia consigliabile progettare l'interfaccia utente dell'app UWP in modo da avere un aspetto ottimale indipendentemente dall'orientamento del dispositivo e dalle dimensioni dello schermo. Maggiori informazioni sono disponibili in Conversione per fattori di forma e esperienza utente, che è l'argomento successivo.

L'argomento successivo è Conversione di livelli di dati e business.