Articolo
09/09/2015

Il presente articolo è stato tradotto automaticamente.

App Windows universali

Riutilizza asset di codice con app Windows universali

Ha molto changedsince ho scritto il mio articolo di luglio 2013, "costruzione di applicazioni per Windows 8 e Windows Phone 8" (msdn.microsoft.com/magazine/dn296517). Oggi, gli sviluppatori con esperienza di creazione di applicazioni per Windows 8.1 possono riutilizzare codice e condividere risorse per costruire nuove esperienze per Windows Phone 8.1. Gli sviluppatori di Windows Phone 8 possono anche massimizzare la stessa base di codice quando la destinazione 8.1 di Windows Phone. Visual Studio 2013, insieme con un Windows Runtime unificato, permette di sviluppare applicazioni destinati a 8.1 Windows Phone e altri dispositivi Windows da una soluzione Visual Studio . Questo nuovo approccio consente agli sviluppatori di ampliare significativamente la base di utenti, delle loro applicazioni, massimizzando il riutilizzo del codice.

In questo articolo, io condividere informazioni che vi aiuteranno a velocizzare il alle nuove funzionalità app Windows universale trovato in Visual Studio 2013, inclusi i modelli, linguaggi, API, compilatori, approcci diversi per condivisione di codice e considerazioni quando si aggiorna applicazioni specifiche della piattaforma per applicazioni Windows universale.

Figura 1 viene illustrata la relazione tra modello universal apps Windows, la soluzione di app e il pacchetto di output di compilazione.

Figura 1 modello App Windows universale, soluzione e pacchetti di Output

Utilizzando i modelli inclusi in Visual Studio, ad esempio il modello di progetto app Hub, è possibile creare soluzioni strutturate per consentire progetti separati per ogni piattaforma, così come un progetto speciale per la condivisione. Questo spazio condiviso è dove è possibile definire il codice per essere riutilizzato per le applicazioni destinate a PC, Tablet PC e Windows Phone. Questa struttura assicura che tutti gli elementi univoci per ogni app sono all'interno del progetto appropriato. Il processo di compilazione crea ogni pacchetto di applicazione specifica, integrando tutte le dipendenze del progetto condiviso. Il modello di app Hub è un ottimo punto di partenza per la costruzione di negozi, notizie, sport e applicazioni multimediali.

Figura 2 Mostra il modello Universal App nuovo progetto Hub App per c#.

A partire da Update 2, Visual Studio comprendeva tutto il supporto necessario per rendere più facile costruire applicazioni Windows universale che massimizzare il riutilizzo del codice.

Figura 2 Universal App nuovo progetto Hub App modello Windows

Supporto progetto app

In uno scenario tipico, dove gli sviluppatori di destinazione sia Windows 8.1 e 8.1 di Windows Phone, Esplora visualizza tre progetti distinti, come mostrato Figura 3:

Un progetto di Windows (Windows 8.1): per pagine XAML e codice specifico per Windows.
Un progetto Windows Phone (Windows Phone 8.1): per pagine XAML e codice specifico per Windows Phone.
Un progetto condiviso: per tutti i beni condivisibili tra le applicazioni di destinazione, come cs,. png. xml, resw e altri oggetti. Il progetto Share importa automaticamente in ogni progetto di piattaforma durante il processo di compilazione.

Figura 3 Windows Universal App progetti in Esplora

Per soluzioni esistenti è possibile utilizzare Aggiungi Windows Phone 8.1 o aggiungere 8.1 di Windows dal menu di scelta rapida del progetto.

Supporto per la lingua

Condivisione del codice può essere realizzato in C++, c# o JavaScript, se il vostro disegno coinvolge XAML, HTML o DirectX. Per Visual Basic, aggiornamenti recenti consentono chiamate Windows Runtime (WinRT) API e includono il supporto per XAML e la cartella del patrimonio della biblioteca portatile di classe (PCL). F # gli sviluppatori possono creare codice condiviso per le applicazioni legacy e più recente Microsoft .NET Framework e Windows Store.

Supporto API

Un common Runtime Windows significa unificazione massiccia delle API di supporto per entrambe le piattaforme, 8.1 di Windows (per PC e tablet) e 8.1 di Windows Phone. Questa unificazione è la chiave per lo sviluppo multipiattaforma più facile e più capace. Universal apps Windows eseguiti nello stesso ambiente di Runtime di Windows, gli sviluppatori hanno un modo comune per architettare e costruire applicazioni per i dispositivi di Windows, da come gestiscono sospendere e riprendere e fare elaborazione, al modo in cui che riescono a sicurezza in-app in background. Infatti, in termini di costrutti di linguaggio chiave, il SDK 8.1 di Windows e Windows Phone 8.1 SDK condividere 566 classi, 119 puntoni e 57 interfacce. Ci sono, tuttavia, alcune API che sono disponibili solo in Windows Phone.

Supporto del compilatore

Anche se il processo di compilazione garantisce l'importazione del associata XAML, codice e attività per ogni progetto, a volte potrebbe essere necessario includere il codice specifico della piattaforma del progetto condiviso. È possibile sfruttare le direttive di compilazione condizionale #if e #endif per indicare il codice destinato per ogni piattaforma. In c#, i simboli del preprocessore compilatore sono WINDOWS_APP e WINDOWS_PHONE_APP; per C++, sono WINAPI_FAMILY_PC_APP e WINAPI_FAMILY_PHONE_APP.

Il c# riportato di seguito viene illustrata la compilazione condizionale per una situazione dove lo sviluppatore potrebbe voler spostare il file app. xaml al progetto condiviso (nell'esempio si presuppone qualsiasi stili definiti in essa utilizzano le risorse disponibili per altri tipi di applicazioni):

#if WINDOWS_APP
  if (!rootFrame.Navigate(typeof(HubPage)))
#endif
#if WINDOWS_PHONE_APP
  if (!rootFrame.Navigate(typeof(WindowsPhoneStartPage)))
#endif
  // ...throw exception
Here’s the equivalent C++ conditional compilation:
#if WINAPI_FAMILY==WINAPI_FAMILY_PHONE_APP
  if (!rootFrame->Navigate(WindowsPhoneStartPage::typeid, e->Arguments))
#else
  if (!rootFrame->Navigate(HubPage::typeid, e->Arguments))
#endif
  // ...throw exception

Codice e supporto Editor XAML

Visual Studio fornisce un grande aiuto per facilitare lo sviluppo di applicazioni universali. IntelliSense monitora il tuo codice per impedire l'utilizzo delle API non supportate nel progetto Universal App. Messaggi di errore corrispondenti identificherà un'API inadeguata quando si compila il progetto, come illustrato nel Figura 4.

Figura 4 IntelliSense mostrando un errore di utilizzo API

Barra di navigazione consente di cambiare il contesto del progetto. Questo è utile quando si desidera concentrarsi su un solo progetto in Esplora soluzioni. Il contesto del progetto (Windows Phone o Windows 8) spinge l'esperienza di IntelliSense nell'editor e designer.

Durante il debug, si consiglia di specificare il progetto di avvio predefinito per F5. Visual Studio fornisce un modo semplice per eseguire questa operazione utilizzando l'elenco a discesa destinazione di debug e, nell'ambito del progetto di avvio, selezionare il progetto desiderato. Questa funzionalità è supportata in entrambi i negozi, viene attivata quando c'è più di un progetto di applicazione della soluzione.

Il pannello del dispositivo, illustrato nella Figura 5, aiuta è assicurarsi che l'applicazione si comporta come previsto su tutti i dispositivi di destinazione. Esso consente di testare l'applicazione utilizzando diverse risoluzioni di schermo, orientamenti, accenti, temi e così via.

Figura 5 pannello dispositivo

Codice di condivisione di strategie

Durante la creazione di applicazioni Windows universale, è meglio massimizzare gli artefatti di applicazione condivisibili attraverso apps. Tradizionalmente, gli sviluppatori hanno contato su file collegati per condividere il codice tra più progetti. Visual Studio 2013 migliora questa funzionalità e fornisce due artefatti correlati per consentire la condivisione di codice: il progetto condiviso e PCL.

Un progetto condiviso (cartella condivisa) offre una semplice struttura organizzativa per la memorizzazione di tutto il codice condiviso e le attività, tra cui app. xaml e altri file XAML, file di codice, immagini, file XML/JSON e resw, così come modelli di modello e di comune. I riferimenti del progetto condiviso devono essere risolti per correggere gli errori del compilatore.

Il PCL è meglio supportato in applicazioni Windows universale. Per esempio, gli sviluppatori possono ora chiamare e creare WinRT APIs e portatili controlli utente XAML. Quando si modifica la destinazione di progetto per includere un'altra piattaforma, il compilatore produce un binario unico garantito per funzionare su tutti i bersagli. Si può anche fare un PCL una specifica piattaforma di destinazione rimuovendo gli altri obiettivi. Questa conversione in-place è supportata solo tra PCL, Windows Store 8.1 e 8.1 di Windows Phone.

Questi binari PCL possono essere distribuiti anche a terzi, e ciò ha generato una crescente comunità di sviluppatori di piattaforme che sono porting di librerie a PCL. Questo garantisce che le funzionalità abbondante biblioteca sarà disponibile per gli sviluppatori, tra cui gli sviluppatori di Visual Studio Express, per altre piattaforme di targeting. Attraverso MS Tech aprire, Microsoft lavora con varie comunità opensource per contribuire al codice per popolare Framework e ottimizzarli per dispositivi Windows. Per esempio, JQuery supporta pienamente Windows Runtime così gli sviluppatori possono riutilizzare il loro codice e le competenze per costruire applicazioni Windows 8.1 esistenti.

Decidere tra progetti condivisi e PCL

C'è un semplice fattore determinante per la scelta tra progetti condivisi e tributo: specificità della piattaforma.

Se il progetto non è destinato a distribuzione di terze parti, progetti condivisi vi darà la migliore esperienza.
Se il progetto comporta la distribuzione di terze parti, PCL è la scelta migliore.

Figura 6 indica alcuni dei punti di forza e di debolezza di ciascun approccio.

Figura 6 confronto del progetto condiviso e libreria di classi portatile

Punti di forza

Debolezze

Progetto condiviso

• Consente l'utilizzo delle API specifiche della piattaforma utilizzando #if.

• Può gestire i casi in cui l'origine è compatibile, ma il binario non sarebbe, come quando le API sono in diversi spazi dei nomi.

• Richiede condivisione l'origine o binari multipli, che inoltra parte della complessità al consumatore.

• Richiede la convenzione e la disciplina per centralizzare la gestione delle API di divergenti, affinché il codice non diventi impossibile da mantenere.

Libreria di classi portatile

• Distribuzione estremamente semplice e il modello di condivisione.

• Scale bene ai grandi sistemi che richiedono soluzioni multiple, che coinvolgono terzi o più linguaggi di programmazione.

• Si basa molto sul fatto che gli obiettivi sono confluite le API.

• Gestione API divergente richiede l'utilizzo di abstract di livello superiore, quali dipendenze o contenitori di inversione del controllo.

Altre considerazioni sulla condivisione di codice

Collegamento di file: Simile ai file condivisi, Add Visual Studio come caratteristica Link vi dà esplicita nel modo tradizionale, di condivisione di file utilizzando istruzioni condizionali del compilatore per condividere su altre piattaforme.

Codice di condivisione nel Front-End: Sia Windows Store 8.1 e 8.1 di Windows Phone condividono lo stesso stack WinRT XAML. Questa è una grande notizia che permette agli sviluppatori di riguardano anche l'interfaccia utente per la condivisione. È possibile condividere l'interfaccia utente tramite un PCL, anche utilizzando il designer XAML.

Codice di condivisione nel Back-End: Universal apps Windows beneficiare pienamente di condivisione del codice incentrata sulla trasformazione posteriore, e questo è perfetto per l'implementazione di modelli di dati condivisa con dipendenze di nuvola. Microsoft Azure Mobile Services, in particolare, è un buon esempio di potenti componenti di back-end che universal apps Windows può sfruttare attraverso applicazioni e dispositivi per accedere ai servizi di notifica e altre funzioni. Applicazioni Windows Store sia Windows Phone serve ugualmente bene, con lo stesso livello di sicurezza dei dati, la disponibilità delle applicazioni e la scalabilità.

Percorsi di aggiornamento applicazione

Gli sviluppatori con applicazioni in qualsiasi negozio ora possono facilmente aggiornare l'app per supportare altri negozio. Tutti i percorsi di aggiornamento richiedono di avere Windows 8.1 e Visual Studio 2013 installato.

Aggiornare un app Windows Phone 8 per un universal app di Windows: Aggiornamento app Windows Phone 8 per Windows Runtime come un universal app Windows significa che è possibile utilizzare Windows XAML per creare il nuova UX e offrono caratteristiche come opzioni di notifica che capitalizzare il nuovo Windows Phone 8.1 Action Center, o anche offrire interamente nuove funzionalità per gli utenti. Una volta che hai aggiornato a un universal app, è possibile condividere facilmente codice con un parallelo app per tablet e PC.

Se si sta aggiornando da Windows Phone 8 app per Windows Phone 8.1, consultare la documentazione per le differenze di supporto API, come ci sono parecchi cambiamenti di comportamento e funzionalità API (aka.ms/waphone81) legate alla elaborazione in background, i file e archiviazione, controlli e altre funzionalità del dispositivo.

Aggiornando un app Store di Windows a un universal app di Windows: Se hai già costruito un app Windows 8.1 e desidera pubblicare l'archivio di Windows Phone 8.1, si applica anche il modello universale di applicazioni Windows. Come nel caso di Windows Phone 8.1, è importante comprendere i cambiamenti del comportamento di API (aka.ms/wawindows81) che possono influenzare il processo di migrazione. Ad esempio, AppBar, riquadro a comparsa, Hub e altri controlli non supportati su Windows Phone.

Aggiornamento di un'applicazione Windows Store e aggiungendo app Windows Phone 8.1: Fornendo un compagno 8.1 di Windows Phone di app da app Store di Windows è semplificato dal modello universal app Windows, che permette di aggiungere semplicemente un nuovo progetto Windows Phone 8.1 alla soluzione Windows Store. L'editor di codice e il compilatore riconosce l'aggiunta e apportare le modifiche appropriate a comportamenti per garantire il buon esito dello sviluppo.

Archivio certificazione

Il Kit di certificazione App di Windows (WACK) è uno strumento strumentale per gli sviluppatori di preparare la loro applicazione per la presentazione al negozio. È anche possibile utilizzare lo strumento per testare il tuo Windows Phone 8.1 apps, ma non gli app Windows Phone 8. WACK 3.3 è incluso in Windows SDK per Windows 8.1 e si possono trovare ulteriori informazioni circa i nuovi requisiti per WACK a bit.ly/1qXPKmf.

Conclusioni

Convergenza della piattaforma è stato un lungo tempo a venire, e anche se non abbiamo raggiunto il nirvana, il progresso ha dato agli sviluppatori sostanziali miglioramenti nella funzionalità di piattaforma, valorizzazione di strumenti, caratteristiche UX e ampiezza del supporto di scenari di applicazione. Oggi, non è abbastanza per essere in grado di eseguire codice in diversi dispositivi. L'UX deve massimizzare la caratteristica specifica del dispositivo su cui viene eseguita l'applicazione. È altrettanto importante sostenere la caratteristica parità attraverso quei dispositivi. È semplicemente ciò che gli utenti si aspettano.

Questo articolo ha esplorato le funzionalità chiave che consentono di sviluppare simultaneamente applicazioni per piattaforme Windows Phone e il PC/tablet se costruire soluzioni da zero o l'aggiornamento di quelli esistenti. Universale Windows apps offrono un modo eccellente per gli sviluppatori per aumentare il valore del loro investimento codice, pur ampliando la portata degli utenti.

Si può trovare un assortimento completo di universale esempi di app di Windows che è possibile eseguire su entrambi Windows 8.1 e 8.1 di Windows Phone a aka.ms/wasamplese una vasta collezione di campioni di funzionalità che utilizzano il nuovo modello di app Windows universale a aka.ms/uap.

Joel Reyes è senior technology evangelist in Microsoft Developer esperienza & Gruppo evangelizzazione incentrato sulla strategia di sviluppo di avvio. È possibile contattarlo al joel.reyes@microsoft.com.

Grazie al seguente Microsoft esperto tecnico per la revisione di questo articolo: Lora Heiny