martedì 6 maggio 2014

Windows Phone 8.1: Un grande passo in avanti per la convergenza

Può sembrare un semplice aggiornamento punto, ma non lo è. Esaminare più da vicino, e capirete perché l'ultima versione di Windows Phone è un grosso problema.
Coloro che hanno familiarità con la storia mobilità Microsoft sono consapevoli del fatto che la convergenza è stato un argomento molto discusso, sia da parte di Microsoft e la sua comunità di sviluppatori.Back in the Windows Mobile / NET Compact Framework (. NET CF) giorni, era uno spazio di nicchia in cui si doveva essere uno specialista di telefonia mobile al fine di costruire grandi applicazioni.
Mentre ci sono alcune somiglianze tra il CF. NET e il pieno. NET Framework, vi erano specifiche API di Windows Mobile, e grazie al sistema operativo sottostante essendo basati su Windows CE, vi erano differenze di implementazione con cui trattare. Windows Phone 7 è stato visto come un importante passo avanti nella convergenza delle piattaforme in quanto ha approvato il modello di programmazione Silverlight, ma era in realtà un passo indietro per la maggior parte degli sviluppatori mobile. Windows Phone 8 è stato il successivo grande passo avanti nella convergenza delle piattaforme, come commutato attraverso al kernel NT e ha iniziato a integrare il Windows Runtime (WinRT) API. La cosa interessante di Windows Phone 8.1 aggiornamento è che è probabilmente uno dei passi più significativi di questa storia convergenza. Non va confuso con la versione minore incremento - questo è un importante passo in avanti per gli sviluppatori, in quanto la programmazione e l'applicazione del modello del ciclo di vita è ora unificata con Windows 8.1. In questo articolo vi guardo perché questo è un grosso problema, e alcune delle altre caratteristiche che vengono con Windows Phone 8.1.
Prima di Windows Phone 8.1, se si voleva scrivere applicazioni utilizzando XAML e C #, è stato utilizzato un modello di programmazione basato su Silverlight. Come parte della nuova storia di convergenza, è ora possibile utilizzare Windows XAML, che è compatibile con il modello utilizzato per la creazione di applicazioni di Windows Store. Riconoscendo gli sviluppatori di investimento hanno già messo in applicazioni Windows Phone Silverlight, Microsoft assicurato che potevano sfruttare alcune delle nuove funzionalità della piattaforma senza dover riscrivere le applicazioni di Windows in XAML. Come tale, ora ci sono tre scelte per lo sviluppo di applicazioni per Windows Phone 8.1:
  • Creare un Windows Phone un'applicazione Silverlight 8.0
  • Creare un Windows Phone un'applicazione Silverlight 8.1
  • Costruire un'applicazione Windows Windows Phone XAML
Pubblicità

Ci sono vantaggi e le limitazioni associate a ciascuna di queste scelte, quindi vale la pena di leggere una parte della documentazione sul Windows Phone Dev Center .
[Clicca sull'immagine per ingrandirla.]Figura 1. Re-Targeting per Windows Phone 8.1
Retarget a Windows Phone 8.1 
Se si dispone di un esistente di Windows Phone 8.0 un'applicazione Silverlight e volete iniziare a utilizzare alcune delle nuove funzionalità della piattaforma, la prima cosa che dovrete fare è ri-porta l'applicazione per Windows Phone 8.1. Microsoft ha fornito un collegamento a questo flusso di lavoro all'interno di Visual Studio: fare clic destro sul file di progetto e selezionare Reindirizza a Windows Phone 8.1, come mostrato in Figura 1 .
Prima di aggiornare l'applicazione per puntare alla nuova piattaforma, e aggiungendo in beni mancanti e file manifest necessari per Windows Phone 8.1, Visual Studio vi avvertirà che è necessario eseguire il backup del progetto prima di procedere. Infatti, la raccomandazione dovrebbe essere quello di prendere un clone dell'applicazione e aggiornare tale (o se si sta utilizzando un repository di controllo del codice sorgente si potrebbe considerare un ramo separato). Il risultato è che si vorrà essere in grado di mantenere un telefono Windows 8 build dell'applicazione più a lungo possibile al fine di garantire il più ampio mercato disponibili per l'applicazione.
Per un sacco di applicazioni re-targeting non alterare o distruggere la vostra app. Tuttavia, prima di apportare ulteriori modifiche, o iniziare a incorporare nuove funzionalità, è importante verificare l'applicazione appena re-targeting è ancora in funzione come previsto.
Universale Progetti
Uno dei motivi principali per l'utilizzo di Windows XAML è la compatibilità tra le applicazioni Windows Phone e Windows. In questa versione, non è possibile costruire un singolo pacchetto che può essere distribuito a entrambi gli ambienti. Tuttavia, c'è molto di compatibilità tra le piattaforme che la maggior parte dei file di codice e markup possono essere condivise tra entrambi i progetti. Riconoscendo che la possibilità di condividere i file tra i progetti non è stata gestita bene in Visual Studio, Microsoft ha avuto l'idea di progetti universali, che contengono un progetto condiviso insieme a diversi progetti "di testa" per ogni piattaforma di destinazione.
La Figura 2 illustra un'applicazione appena creato universale basato sul modello Hub.Dispone di tre sotto-progetti: uno per ciascuno di Windows e Windows Phone (che è la "testa" o progetti mirati), e un progetto condiviso. Dalla barra degli strumenti è possibile scegliere non solo se eseguire l'emulatore o un dispositivo, ma anche che di destinazione che si desidera eseguire (Windows o Windows Phone).
[Clicca sull'immagine per ingrandirla.]Figura 2. La nuova applicazione universale.
Certo, a volte il progetto partirà come un solo obiettivo e finiscono per dover fornire più bersagli. Per fortuna, questo percorso di migrazione può essere facilmente raggiunto in Visual Studio facendo clic destro sul progetto originale e selezionando Aggiungi Windows Phone 8.1 o Aggiungi di Windows 8.1. Entrambe queste opzioni saranno creati due nuovi progetti; uno per l'altro obiettivo e un progetto condiviso. E 'poi a voi per capire quanto del codice e markup può essere condiviso. Si noti che questa non è un'opzione per Phone 8.0 applicazioni Silverlight per Windows esistenti.
Scegli la tua lingua 
di sviluppo Web per Windows Phone è sempre stato un cittadino di seconda classe, relegato ad essere visualizzati all'interno di un contenitore WebBrowser, seguendo il modello di stile PhoneGap per esporre funzionalità del dispositivo. Con Windows Phone 8.1, gli sviluppatori hanno la loro scelta della tecnologia e del linguaggio. Per i giochi, C + + e DirectX darà le migliori prestazioni. Per un rapido sviluppo, la combinazione di XAML - definire in modo dichiarativo le pagine e controllo - e C # (o Visual Basic) per scrivere la logica dell'applicazione è l'opzione migliore. Per gli sviluppatori Web, l'introduzione del modello di programmazione WinJS per Windows Phone consente di sfruttare la vostra abilità attuali per costruire attraverso le piattaforme Windows e Windows Phone.
Microsoft ha fatto un passo avanti, annunciando che è WinJS di sourcing aperti e continuando ad evolversi al lavoro su più piattaforme. Questo significa che gli sviluppatori di applicazioni dovrebbero essere in grado di sfruttare un insieme comune di API per lavorare con le funzioni del dispositivo (probabilmente approfittando del progetto di Cordova per fornire l'integrazione del dispositivo di basso livello), così come alcuni degli elementi di interfaccia utente ricchi forniti dal WinJS, l' GridView e ListView controlli, per esempio.
Layout
La distinzione tra telefoni e tablet è diventato sempre meno su dimensioni e di più su modelli di utilizzo. Come la piattaforma Windows evolve e converge con la piattaforma Windows Phone, sembra logico che quello che una volta era una scelta discreta tra lo sviluppo di un telefono cellulare o lo sviluppo di un desktop / tablet sta diventando un continuum di forme e dimensioni del dispositivo.
Gli sviluppatori di Windows Phone saranno utilizzati per sviluppare le proprie applicazioni basate su una larghezza di 480 unità. A seconda di quale dispositivo l'applicazione gira su, questo potrebbe equivalere a 480, o qualche altro numero di pixel effettivi. Questo permette un semplice modello di layout, perché hai solo bisogno di spiegare se il dispositivo è in modalità ritratto o paesaggio (e, in realtà, la maggior parte delle applicazioni sono progettate per funzionare solo in verticale). Tuttavia, come dispositivi scalabili oltre i 6 pollici, questa semplicità significa che il layout non fare un uso efficace degli ulteriori schermo immobiliare disponibile su dispositivi più grandi.
Windows Phone 8.1 è una tela di layout virtuale condiviso, con una logica DPI 166. Questo significa che i dispositivi con la stessa risoluzione, ma dimensioni fisiche diverse avranno una risoluzione effettiva diversa. Questo suona molto più spaventoso di quanto non sia in realtà.Un sacco di layout sarà ancora utilizzare l'allineamento per controllare le dimensioni e la posizione degli elementi. Dove diventa rilevante è per la lista e, in particolare, controlli griglia - invece di avere due colonne di tessere che semplicemente crescono con la dimensione del dispositivo, si vedrà automaticamente colonne aggiuntive appaiono come gli aumenti effettivi di risoluzione.
Mentre la risoluzione effettiva della vostra applicazione varia, si consiglia di regolare la disposizione dei comandi per sfruttare lo spazio aggiuntivo, o, nel caso di dispositivi più piccoli, forse, ridurre la quantità di contenuto visibile. Tutto questo può essere fatto utilizzando stati di visualizzazione. In primo luogo, definire stati visivi in ​​Blend per Visual Studio. Poi, come le dimensioni dello schermo varia, è sufficiente modificare lo stato corrente utilizzando il VisualStateManager. Questa strategia funziona non solo per schermi con risoluzione effettiva diversa, ma anche variando l'orientamento del dispositivo e lo schermo splitting per applicazioni desktop.
Windows Phone 8.1 applicazioni sono in grado di condividere i controlli con Windows. Questo significa che ci sono alcuni controlli (Button e TextBlock, per esempio) che sono comuni in entrambe le piattaforme. Ci sono altri controlli cui l'API è lo stesso, ma stanno ottimizzati per le diverse piattaforme. Ci sono anche i controlli specifici della piattaforma (come pivot per Windows Phone). Quando si costruisce controlli, anche voi, potete condividere (o personalizzare) i controlli per le diverse piattaforme.
Application Lifecycle e della Navigazione Modello 
Il modello del ciclo di vita di Windows Phone 8.1 applicazione è lo stesso come applicazione di Windows 8.1. Ciò significa che la logica per sospendere e riprendere può essere condivisa.Inoltre, il modello di navigazione è la stessa, basata sulla navigazione al tipo di una pagina, piuttosto che la sua Uri. Un effetto collaterale di questo è che gli sviluppatori di Windows Phone dovranno imparare come il NavigationCacheMode può determinare il ciclo di vita pagina. Guida semplice come l'attivazione della modalità cache di navigazione in avanti, e disabilitarlo su una navigazione schiena, può funzionare per applicazioni semplici, ma può avere bisogno di essere ottimizzato per le applicazioni che hanno un flusso di navigazione differente.
Multi-Tasking
L'agente e il modello di attività di Windows Phone 8.0 è sostituito dal modello di Windows per l'elaborazione in background. Questo sfrutta una serie di trigger un'applicazione può ascoltare per, come NetworkStateChange, posizione e trigger tempo, e notifica push attiva. Quando un trigger viene generato, l'applicazione ottiene da eseguire e reagire al cambiamento di stato del dispositivo sfondo.

Nessun commento:

Posta un commento