Articolo
09/07/2015

Il presente articolo è stato tradotto automaticamente.

Silverlight e WPF

Scrittura di applicazioni Silverlight e WPF ispirata ai costrutti XAML di Windows Runtime

Windows Runtime (WinRT) XAML per nuove applicazioni Windows Store è l'ultima di XAML e c# / Visual Basic famiglie molti di noi hanno imparato ad amare. Tutto è iniziato ufficialmente nel 2006 con Microsoft .NET Framework 3.0 e "Avalon" (in seguito denominata Windows Presentation Foundation o WPF). Dopo che è venuto diverse revisioni più di WPF, compresa l'ultima, WPF 4.5, e insieme abbiamo avuto sette versioni denominate di Silverlight (compresi 1.1 e 5.1), alcune versioni di Windows Phone e di più. Troverete anche parte dello stack XAML disponibile sui dispositivi Micro Framework .NET.

Ci si potrebbe chiedere perché ci sono così tante variazioni su XAML e .NET Framework. Anche se molte delle implementazioni sono convergenti su usi simili (Silverlight per scrivere applicazioni desktop, ad esempio), ogni piattaforma è stato sviluppato e ottimizzato per i diversi scenari e piattaforme di destinazione. Ad esempio, Silverlight è stato progettato per essere multipiattaforma e Web-hosted. XAML su Windows Phone è stato progettato per scenari specifici del telefono e hardware e WinRT XAML su Windows 8 è stato progettato per alte prestazioni, sul metallo (x86 / x64 e braccio), apps Store Windows touch prima (ma non solo touch).

Tuttavia, queste implementazioni di XAML hanno molto più in comune che non. È a causa di queste somiglianze che le differenze sembrano così pronunciate. Naturalmente, le piccole differenze possono causare un sacco di problemi di sviluppo, qualcosa so per esperienza personale e di parlare con altri sviluppatori. Tuttavia, il fatto che possiamo anche parlare di compatibilità a livello di dettaglio illustra la somiglianza tra le lingue, le librerie e markup.

In questo articolo, sono destinati due scenari importanti: la condivisione di codice con un compagno app e a prova di futuro l'attuale sviluppo.

Compagno App questo è uno scenario simultanea di code-sharing, o cross-compilazione, per gli sviluppatori di applicazioni WPF e Silverlight che vogliono sviluppare applicazioni Windows Store compagno per Windows 8 allo stesso tempo.

Futura correzione In questo scenario, gli sviluppatori stanno creando nuove applicazioni WPF e Silverlight oggi ma non sono attualmente targeting Windows 8. Quando l'organizzazione adotta Windows 8, gli sviluppatori vogliono essere pronti; vogliono contribuire a garantire che adeguate porzioni delle loro apps saranno più facilmente portati sulla nuova interfaccia utente di Windows.

Decenni di esperienza di programmazione ci hanno insegnato che mai sono liberi riutilizzo e la portabilità. Tuttavia, con le tecniche coperte qui, troverete molti degli sforzi un minimo incremento sopra che cosa si farebbe normalmente per creare applicazioni con.

Architettura riflessivo è essenziale

Ultime applicazioni di grandi dimensioni in piccole applicazioni è possibile solo se hai buona architettura per cominciare. Infatti, se l'applicazione ha un sacco di interdipendenze tra i moduli di codice, un sacco di gerarchie di classe pesante, o altrimenti si sente come una palla di fango o codice usa e getta, i riutilizzo o porting nulla sarà estremamente difficile. Ma non disperate! Codice può essere rielaborata e nuovo codice può essere scritto con la nuova architettura in mente.

Durante la progettazione di nuove applicazioni, incoraggio gli sviluppatori XAML per seguire alcuni principali approcci: Associazione, le classi di servizio e pattern Model-View-ViewModel (MVVM).

Associazione più si abbraccia associazione dati quando lo sviluppo in XAML, è facile mantenere la logica separati dall'interfaccia utente. Idealmente, si imposta la proprietà DataContext per l'interfaccia utente, e tutto il resto viene gestito dall'associazione con comandi o dati. In pratica, alcune applicazioni sono in grado di raggiungere questo livello di separazione, ma si avvicina, più facile la tua vita sarà.

Il Pattern MVVM modello MVVM la va mano nella mano con associazione dati. Il ViewModel è ciò che l'interfaccia utente verrà associato. C'è un sacco di informazioni (e Toolkit, di cui si parlerà più avanti) è disponibile gratuitamente su Internet e nei libri, così io non rimaneggiamento che qui.

Classi di servizio questo approccio non deve essere confuso con i servizi Web. Invece, queste sono classi che forniscono funzionalità riutilizzabili sul client. In alcuni casi, si potrebbe chiamare a RESTful o altri servizi. In altri casi, essi potrebbero interfacciarsi con la logica aziendale. In tutti i casi, essi incapsulano il codice potenzialmente volatile e fare sostituendo le implementazioni più facile. Per esempio, in Figura 1, il ViewModel parla di classi di servizio per poter utilizzare entrambi servizi di piattaforma e di risolvere le dipendenze esterne.

Relationship Between the ViewModel and Service Classes
Figura 1 relazione tra le classi di servizio e ViewModel

Lo so. Stai pensando, "Ugh! Un altro diagramma livello." Ma sapete quanto questi concetti sono importanti. L'intento è quello di separare se stessi dalla piattaforma sei in quanto è ragionevole entro il budget e vincoli di tempo. Di factoring codice che, ad esempio, rende COM o p-chiamate in desktop come Windows Imaging o di DirectShow, è possibile sostituire più facilmente che l'attuazione con la fotocamera di WinRT API nel tuo app Store di Windows. Classi di servizio sono anche un ottimo posto per incapsulare altre differenze di piattaforma, come implementazioni di contratto: inviando una e-mail dalla tua app Store Windows utilizzerà un contratto, ma sul desktop significherebbe probabilmente l'automazione di Outlook o di aggancio in un server SMTP.

Naturalmente, è facile esagerare con architettura e mai effettivamente offrire. Buona architettura dovrebbe semplificare lo sviluppo, non di più. Se trovate il vostro team alle prese con le minuzie di una particolare struttura architettonica, probabilmente stai sprecando tempo. Invece, capire i motivi e che cosa portano e poi prendere decisioni intelligenti e informati circa i compromessi. Nella maggior parte dei casi, l'implementazione 85 per cento di una grande architettura è meglio di 0% dello stesso. Analogamente, il costo coinvolto nell'ottenere che ultimo 15% implementato è spesso non vale la pena.

Una volta separano il codice dipendente dalla piattaforma, un po' di altro codice non banale può essere riutilizzato.

Abbracciare la nuova estetica del Design dell'interfaccia utente di Windows

Quando gli sviluppatori prima considerano la costruzione di versioni di Windows Store esistente Windows Presentation Foundation (WPF) e di applicazioni Silverlight, corrono subito in blocco di dover ripensare la UX e progettazione visiva. Per la maggior parte degli sviluppatori, la prospettiva di un'intera applicazione di restyling non è attraente. Se si pensa che Windows Store apps sono nel tuo futuro, un po' di lavoro ora di abbracciare la nuova estetica di interfaccia utente di Windows e linee guida davvero pagherà più tardi.

Il nuovo design dell'interfaccia utente di Windows fornisce un framework che è possibile utilizzare per aiutare la guida le scelte di progettazione dell'interfaccia utente. Diversi video di BUILD 2011 cover Windows Store app design. Li potete trovare su MSDN Channel 9 a bit.ly/oB56Vf. Inoltre, qui sono alcune cose che vorrete fare per abbracciare il nuovo design dell'interfaccia Windows estetico nelle applicazioni desktop:

Essere autenticamente digitale. In genere, evitano la pratica di progettazione dell'interfaccia utente per essere un falso analogico di oggetti fisici (skeuomorphism). Si dovrebbe evitare di ricreare non solo gli oggetti fisici, ma anche derivano tecniche lucidi pulsanti, ombreggiatura 3D, ombre realistiche e sfondi di vetro.
Hanno una gerarchia di tipo chiaro. Non usare una tonnellata di font diversi e per i font da utilizzare, attenersi a un paio di taglie chiave e facilmente distinto. Rubriche dovrebbero essere facilmente distinguibili da etichette di campo e il testo della guida.
L'applicazione del marchio. Utilizzare i colori, loghi, tipo e più appropriato. Aiuta ad per avere i vostri sviluppatori Web e designer coinvolti qui, come spesso hanno più esperienza hands-on con branding.
Utilizzare una metafora di navigazione basata su pagina. Gli sviluppatori Silverlight troverete questo naturale (framework di navigazione è quasi identico), ma gli sviluppatori WPF potrebbero avere un po ' più lavoro da fare per passare dal tradizionale approccio desktop multi-window e di dialogo.
Essere orientati al compito. Mantenere l'interfaccia utente orientata al compito e non cercare di stipare ogni cosa su un unico modulo. Purtroppo, gli utenti spesso pensano che vogliono tutte le funzioni su una singola pagina, ma nel tempo che diventa difficile da usare, difficile da imparare e difficile da mantenere. In alcuni casi, considerare rompere grandi applicazioni apps più piccoli, attività mirata.
Evitare inutili decorazione. Mantenere l'interfaccia utente semplice. Volete disegnare gli occhi dell'utente per il lavoro che ha bisogno di concentrarsi su, non a menu, elementi di navigazione, bordi e altri cromo.

Pensate a questi concetti molto come se si trattasse di linee guida di progettazione dell'interfaccia utente di Windows più vecchie. Sono le linee guida che si dovrebbe seguire se volete il vostro app di sentire familiare all'utente e in sintonia con la nuova interfaccia utente di Windows. C'è più ad esso, naturalmente, così vi incoraggio a guardare i video di costruire e studiare esempi di applicazioni che hanno scritto altri sviluppatori e designer.

Un modo per ottenere un inizio capo sull'utilizzo degli stili dell'interfaccia utente consiste nel copiare le risorse di stile app Store Windows applicazioni desktop. Potete trovare molte delle risorse di stile nella cartella Windows Kits. Sulla mia macchina, tale cartella si trova in C:\Program Files (x86) \Windows Kits\8.0\Include\winrt\xaml\design.

Alcuni degli stili e delle risorse sono utilizzabili come è. Alcuni saranno inutilizzabili a causa di controlli più recenti (ListView e GridView, ad esempio), e alcuni possono richiedere un po ' Fiera di tweaking. Tuttavia, questo è un ottimo modo per ottenere un aspetto moderno per la vostra applicazione e per promuovere una facile transizione tra desktop e stili di Windows Store. Anche quando non utilizzi un modello o lo stile direttamente, si può imparare da esso per ottenere un inizio capo sul proprio lavoro di stile.

Interfaccia utente ancora bisogno di qualche lavoro quando si sposta al Runtime di Windows, ma se si abbracciano questi concetti nelle applicazioni ora, andare un lungo cammino verso assicurando che il vostro transizioni tra la nuova interfaccia utente di Windows Store e le applicazioni desktop non siano stridente per gli utenti o gli sviluppatori.

Sono tutti per meno lavoro. Stile app una volta, rendere più facile la transizione e ottenere un look moderno come un bonus.

Riutilizzo di codice e componenti

Il Runtime di Windows ottiene molta attenzione nel nuovo Store Windows apps. È nuovo, è veloce e ha un sacco di funzioni interessanti. Tuttavia, a volte ci dimentichiamo che il Runtime di Windows non è la somma totale di ciò che si deve lavorare; Windows Store apps costruito con XAML utilizzano un sacco del .NET Framework 4.5 con il Runtime di Windows. Infatti, il .NET Framework 4.5 ha aggiornamenti significativi, tra cui molti che gli permettono di essere usato side-by-side con il Runtime di Windows. È ancora .NET, però — condivisione di codice sorgente e file binari compilati anche, con altre implementazioni di .NET è abbastanza ragionevole da fare.

Quando la condivisione di codice con applicazioni WPF, la cosa migliore che si può fare proprio ora è scrivere il codice WPF per lavorare con il .NET Framework 4.5. Apps Store Windows utilizzare un sottoinsieme di sicuro di .NET 4.5 a fianco il Runtime di Windows. Quando il .NET Framework fornisce la stessa funzionalità Windows Runtime (XAML è un grande esempio), il profilo di .NET apps Store Windows utilizza la versione di WinRT. Se ti infili in questo sottoinsieme quanto più possibile, il codice sarà estremamente portatile. Troverete questo particolarmente utile quando si lavora con i servizi e il codice asincrono.

Quando la condivisione con Silverlight, sei un po' più ristretto che Silverlight non usa il .NET Framework 4.5 o, per la maggior parte Task Parallel Library. Tuttavia, con async targeting pack per Silverlight 5, gli utenti di Visual Studio 2012 scrivere applicazioni Silverlight accedere ad alcune delle attività <T> e la funzionalità asincrona/attendono. Il codice Add Service Reference non genera codice asincrono lato client, tuttavia. Se è importante per voi, si può porta il codice proxy generato per Silverlight. Un approccio migliore, utilizzando l'architettura che ho proposto qui, è quello di incapsulare le interazioni di servizio Web all'interno di classi di servizio locale.

Per quanto riguarda il codice che è identico? Modello classi — e, in molti casi, le classi ViewModel, rientrano in questa categoria. Qui, si hanno due scelte: Portatile Class Library (PCL) e progetti collegati.

PCL progetti PCL è un ottimo modo per condividere dll compilata tra diversi obiettivi .NET. PCL consente di condividere gli assembly tra .NET, applicazioni .NET per Windows Store, Silverlight, Windows Phone e altro ancora. Per utilizzare il PCL, è necessario limitare i riferimenti dell'assembly a quelli della lista di compatibilità. Saperne di più su PCL a bit.ly/z2r3eM.

Collegati a progetti con codice sorgente condiviso e compilazione condizionale questa è una funzionalità di Visual Studio che consente di avere più progetti, ciascuno per diverse piattaforme, ma con un unico comune copia del codice sorgente. In passato, ho usato questo approccio, soprattutto quando la condivisione di codice tra ASP.NET sul server e Silverlight sul client. Potete trovare un esempio sul mio blog a bit.ly/RtLhe7.

Anche se ho usato tradizionalmente per la maggior parte del mio scenari di riutilizzo progetti collegati, PCL è davvero cresciuto nelle versioni più recenti. Se la destinazione di WPF e XAML WinRT, PCL vi permetterà di utilizzare quasi tutto nel profilo .NET 4.5 per Windows Store apps. In caso di dubbi, iniziare con PCL.

Una cosa che mi piace l'approccio di progetto collegato è che posso fornire funzionalità aggiuntive specifiche della piattaforma attraverso classi parziali e compilazione condizionale. Simboli di compilazione condizionale sono impostati nella scheda compilazione della pagina Proprietà del progetto, come illustrato nel Figura 2.

Project Properties Page Showing Compilation Symbols
Pagina delle proprietà del progetto figura 2 Mostra i simboli di compilazione

Per impostazione predefinita, un numero di simboli di compilazione condizionale è definito per voi, come mostrato Figura 3.

Figura 3 simboli di compilazione condizionale

Platform	Simbolo di compilazione
Windows Runtime + .NET Framework	NETFX_CORE
WPF/.NET Framework 4.5 Desktop	Nessuna
Silverlight	SILVERLIGHT

Nota che il Framework .NET completo non definire eventuali simboli di compilazione, è considerato la piattaforma predefinita. Che ti fa a disagio, è possibile aggiungere i proprio simboli di compilazione; Assicurati di che farlo per tutti i progetti .NET Framework nella soluzione.

Compilazione condizionale è anche come, nel codice, si può tirare in spazi dei nomi differenti, a seconda della piattaforma di destinazione:

#if NETFX_CORE 
using Windows.UI.Xaml; 
#else 
using System.Windows.Xaml; 
#endif

In qualsiasi applicazione non banale, probabilmente troverete voi stessi usando PCL sia progetti collegati per la condivisione di codice. Condivisione di XAML, tuttavia, è più complesso.

Condivisione di risorse e interfacce utente XAML

Per diversi motivi, condivisione XAML è più difficile di condivisione di codice. Il passo più importante per fare così è di personalizzare l'interfaccia utente per il fattore di forma e la piattaforma di che destinazione. (Vedi "Abbracciare il nuovo Windows UI Design estetico" per alcune indicazioni qui.) Nella maggior parte dei casi, il tempo di sviluppo è meglio speso assicurandosi che il codice è riutilizzabile, perché vedrete più profitto per meno sforzo. Tuttavia, ci sarà un desiderio e la tendenza a condividere progetti XAML.

XAML non ha il concetto di compilazione condizionale. Di conseguenza, differenze di spazio dei nomi sono più difficili da gestire rispetto a codice. Oltre a spazi dei nomi stessi, importati in XAML è stato modificato tra WinRT XAML e le altre versioni.

Considerare questo .NET Framework XAML:

xmlns:localControls="clr-namespace:WpfApp.Controls"

E questo WinRT XAML:

xmlns:localControls="using:WindowsApp.Controls"

Anziché l'istruzione "clr-namespace", WinRT XAML viene utilizzata l'istruzione "uso" in XAML durante l'importazione degli spazi dei nomi. Perché questo fatto il team di prodotto? Spazi dei nomi importati in XAML potrebbe venire dal codice non CLR — C++, ad esempio. Non solo ora avete supporto XAML in C++, ma è possibile scrivere gli assembly di estensione in C++ e utilizzarle nel codice .NET. Ciò significa che il termine "clr-namespace" non è più accurato.

Un modo per affrontare le differenze è caricare dinamicamente il codice XAML. Ai tempi di Silverlight 1.1 alpha, questo era il modo usercontrols sono stati generati: XAML dinamicamente è stato caricato e trasformato in fase di esecuzione. Da allora, questo approccio è stato utilizzato dagli sviluppatori di app per la flessibilità in tutte le piattaforme.

Quando si carica dinamicamente XAML si lavora con stringhe. Ciò significa che è possibile sostituire o testo sottoinsieme a volontà prima di caricarli in una struttura ad albero visuale. Per esempio, diciamo che avete una definizione vuota usercontrol nel progetto WPF o Silverlight. Usercontrol è solo un guscio che definisce gli spazi dei nomi e la classe. Allora avete una shell equivalente nel progetto WinRT XAML.

Ecco il codice XAML .NET:

<UserControl x:Class="WpfApp.Controls.AddressControl"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Grid x:Name="LayoutRoot">
  </Grid>
</UserControl>

Ed ecco WinRT XAML:

<UserControl x:Class="WindowsApp.AddressControl"
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml">
  <Grid x:Name="LayoutRoot">
  </Grid>
</UserControl>

I due controlli utente XAML sono uscita plain-vanilla di vecchio modello. L'unico cambiamento che ho fatto è stato per denominare l'elemento Grid radice e rimuovere alcuni spazi dei nomi non utilizzati per mantenere il codice breve. Code-behind per i controlli possono essere condivisi utilizzando le tecniche di code-sharing, anche se consigliamo di dividere il codice in una classe separata condivisa quando possibile.

Quindi, per caricare il codice XAML in fase di esecuzione, è possibile utilizzare codice simile a quello che si vede Figura 4.

Figura 4 codice per il caricamento di XAML in modo dinamico

public partial class AddressControl : UserControl
{
  public AddressControl()
  {
    InitializeComponent();
    LoadXaml();
  }
  private void LoadXaml()
  {
    string xaml =
    "<Grid xmlns=\"https://schemas.microsoft.com/winfx/2006/xaml/presentation\" " +
      "xmlns:x=\"https://schemas.microsoft.com/winfx/2006/xaml\">" +
      "<Grid.RowDefinitions>" +
        "<RowDefinition Height=\"Auto\" />" +
        "<RowDefinition Height=\"30\" />" +
      "</Grid.RowDefinitions>" +
      "<TextBlock Text=\"Address\" Grid.Row=\"0\" FontSize=\"10\" />" +
      "<TextBox x:Name=\"t1\" Grid.Row=\"1\" FontSize=\"15\" />" +
    "</Grid>";
    var reader = new StringReader(xaml);
    var xmlReader = XmlReader.Create(reader);           
    LayoutRoot.Children.Add((UIElement)XamlReader.Load(xmlReader));
  }
}

Il codice per caricare in XAML WinRT è ancora più facile a causa della stringa diretto supporto di carico:

string xaml = "..."
LayoutRoot.Children.Add((UIElement)XamlReader.Load(xaml));

Per semplicità, ho caricato XAML da una stringa hardcoded qui e utilizzato XAML che già è portatile e non richiedono alcuna manipolazione di stringhe. Il primo, se vuoi il supporto di progettazione, rendere il codice caricare testo da un file di risorse XAML. Quindi, includere tutti i soliti classe e xlmns definizioni per supportare il progettista, ma buttarli via durante la fase di caricamento di XAML.

Indipendentemente da come XAML ottiene nella struttura ad albero visuale, se si desidera collegare eventi nel codice XAML caricato dinamicamente, potete farlo da codice così:

LayoutRoot.Children.Add((UIElement)XamlReader.Load(xaml));
var t1 = FindName("t1") as TextBox;
if (t1 != null)
{
  t1.TextChanged += t1_TextChanged;
}

Come è possibile caricare XAML UI, è anche possibile caricare risorse in fase di esecuzione. Potete crearli da zero o, utilizzando gli stessi approcci mostrati qui, li carico dall'origine XAML:

private void LoadResources()
{
  string xaml =
    "<Style xmlns=\"https://schemas.microsoft.com/winfx/2006/xaml/presentation\" " +
      "TargetType=\"TextBox\">" +
      "<Setter Property=\"Margin\" Value=\"5\" />" +
    "</Style>";
  // Implicit styles use type for key
  var key = typeof(TextBox);
  App.Current.Resources.Add(key, XamlReader.Load(xaml));
}

Durante il caricamento delle risorse in modo dinamico, assicurarsi di che averli caricati prima essi riferimento. Nel caso di stili impliciti, che semplicemente non applicato a qualcosa già nella struttura ad albero visuale quando la risorsa viene creata.

Per essere chiari, questo approccio tutto è un po' hacky e non funzionerà senza problemi in ogni scenario. (A un certo punto, la manipolazione di stringa può essere più lavoro di quanto vale la pena). Ma se volete il massimo riutilizzo di piattaforme, questo è un possibile modo per realizzarla. Personalmente, vorrei utilizzare questo solo per i componenti critici di interfaccia utente che stanno per cambiare molto o sono troppo complessi o troppo numerosi per essere semplicemente copiare e incollare su base regolare.

Naturalmente, si potrebbe anche scrivere un azione di compilazione personalizzata o altra estensione di Visual Studio per gestire automaticamente l'elaborazione quando i file vengono salvati, estratti, costruito o per qualche altro passo.

Il modo finale è rifuggono complessivamente XAML e invece di creare l'intera interfaccia utente dal codice. In genere, attenzione contro questo approccio per la maggior parte delle applicazioni, è un sacco di lavoro supplementare, e si ottiene zero supporto di progettazione. Tuttavia, interfacce utente basate su dati fanno molto bene con questo approccio. Se è possibile crearlo in XAML, è possibile creare nel codice, come WinRT XAML mostrato in Figura 5.

Figura 5 la creazione di un'interfaccia utente con WinRT XAML

private void CreateControls()
{
  Grid g = new Grid();
  RowDefinition r1 = new RowDefinition();
  RowDefinition r2 = new RowDefinition();
  r1.Height = new GridLength(1, GridUnitType.Auto);
  r2.Height = new GridLength(30.0);
  g.RowDefinitions.Add(r1);
  g.RowDefinitions.Add(r2);
  TextBlock t = new TextBlock();
  t.Text = "Address";
  Grid.SetRow(t, 0);
  TextBox tb1 = new TextBox();
  Grid.SetRow(tb1, 1);
  g.Children.Add(t);
  g.Children.Add(tb1);
  LayoutRoot.Children.Add(g);
}

Questo codice, ad eccezione delle impostazioni dei caratteri (per mantenere l'elenco breve), è equivalente al XAML caricato dinamicamente che aggiunge un oggetto TextBlock e TextBox alla griglia LayoutRoot, contenuto in una griglia.

Considerare Toolkit Open Source

Molti dei migliori XAML c# Toolkit sono open source. In un progetto attivo open source è probabile vedere persone interessate pick up e aggiungere i tipi di caratteristiche che rendono possibile lo spostamento tra Silverlight e WPF, il Runtime di Windows.

Ci sono un certo numero di MVVM Toolkit, per esempio, che sono principalmente portatile attraverso i diversi sapori di XAML. Utilizzando uno di questi, si può aiutare a ridurre il numero di modifiche codice sorgente ha bisogno quando si condivisione o porting. Allo stesso modo, troverete controlli, database locali e altri strumenti disponibili per l'utilizzo su piattaforme.

C'è sempre il rischio che gli sviluppatori open source non funzioneranno le nuove versioni destinazione delle piattaforme, ma con accesso al codice sorgente, si potrebbe forcella del codice e assumere che se volete. Contribuiscono solo il codice quando hai finito.

Decidere che cosa dovrebbe essere un'interfaccia utente di Windows Store App

Quando arriva il momento di creare il vostro nuovo app Store di Windows, tenere presente che non tutti gli aspetti di tutte le applicazioni desktop di tradurre direttamente in Windows Store apps. Ad esempio, un'applicazione di grandi dimensioni con 300 forme, eseguendo un'intera suite di funzioni diverse per utenti diversi, non è necessariamente un buon candidato per la nuova interfaccia utente di Windows. Invece, apps Store di Windows dovrebbe essere orientato al compito e su misura per un uso specifico.

Si consideri un'applicazione di assicurazione. Si potrebbe avere un app che è condivisa da un gran numero di utenti in azienda. Gestisce le funzioni di vigilanza per la gestione della sicurezza degli utenti. Permette di prendere vetro-danno indicazioni per telefono, così come su un computer portatile nel campo. Dispone di una funzionalità incorporata per la creazione di nuove politiche, e così via.

Se si interrompe l'applicazione in un numero di applicazioni più piccole attività concentrata (o orientati all'utente), sarà più appropriato per la nuova interfaccia utente di Windows. Ad esempio, si potrebbe desiderare un app campo di regolazione separata che si concentra in particolare sull'assunzione di informazioni incidente alla scena. Perché si è focalizzata, include il supporto per scattare fotografie e registrare video, così come locali di memorizzazione nella cache dei dati per aree disconnesse o segnale di poveri. Questo app probabilmente condivide un sacco di codice con le altre applicazioni nell'impresa, ma il suo focus rende più facile da adattare per gli scenari per i quali è stato costruito.

Conclusioni

WinRT XAML WPF e Silverlight sono stati creati con scopi diversi in mente, ma sono più simili di differenti. Condividere codice tra loro è facile, e condivisione XAML è possibile. Ci sono un sacco di tecniche aggiuntive che si possono seguire per tutte e tre le piattaforme di destinazione e spostare dal desktop alla nuova interfaccia utente Windows Store. Mi piacerebbe continuare questa conversazione su Twitter e sul mio blog a 10rem.net. Se hai utilizzato altre tecniche per codice multi-targeting o porting per il Runtime di Windows, mi piacerebbe sentire da voi.

Pete Brown è il ragazzo di Windows 8 XAML e gadget Microsoft. Egli è anche autore di "Silverlight 5 in azione" (Manning Publications, 2012) e "Windows 8 XAML in azione" (Manning Publications, 2012). Il suo blog e sito Web sono 10rem.net, e possibile seguirlo su Twitter a twitter.com/pete_brown.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Tim Heuer