Applicazioni moderne

Ciclo di vita delle applicazioni Windows Store

Rachel Appel Windows 8 sta cambiando come e quando eseguire applicazioni e vorrete capire le sfumature della durata di applicazione del nuovo in modo da poter costruire applicazioni che rispondono come dovrebbero in ogni punto. Applicazioni conformi alle linee guida di gestione del ciclo di vita di Microsoft di offrire una migliore esperienza per l'utente, soprattutto su dispositivi di piccole dimensioni dove sono garantiti conservazione memoria e batteria.

Progettazione delle applicazioni

Due concetti chiave di design sono alla base di Windows Store apps: possono essere eseguito da applicazioni a tutto schermo, modalità bloccati o pieni; e apps devono essere altamente reattivo, così l'utente può concentrarsi sul contenuto a portata di mano con meno distrazioni. Questi due principi assicurano che l'applicazione attualmente in esecuzione ottiene tutte le risorse disponibili dal sistema operativo e l'utente, a differenza di Windows 8 applicazioni desktop o applicazioni nelle versioni precedenti di Windows, che ha dovuto condividere le risorse.

Tutte le applicazioni Windows Store sono quattro stati: non funziona, funziona, sospeso e terminato. Quando si avvia un app, funziona. Più tardi, a seconda l'utente o l'attività del sistema, l'applicazione potrebbe transizione tra Stati in esecuzione e sospesi. Ad esempio, se l'utente passa da app A app B, Windows sospende app A dopo un breve ritardo, spostandolo verso lo sfondo. App A rimane sospesa (fino a quando l'utente passa ad essa o Windows e termina), mentre app B si attiva e si muove in stato di esecuzione (possibilmente da uno stato sospeso se fosse già in memoria). Se l'utente restituisce a app A, Windows semplicemente sveglia it up e, per quanto il sistema operativo e la app un sapere, è in corso tutti insieme. Poi, naturalmente, è il turno di app di B per essere sospeso.

Quando un'applicazione è in uno stato di sospensione, il codice non viene eseguito e l'app rimane in memoria, come è. In sostanza, l'app è memorizzato nella cache e immediatamente pronto a partire quando l'utente passa indietro. Tuttavia, non è tutta la storia — è possibile eseguire operazioni in background, se si seguono le procedure corrette e Windows potrebbe terminare applicazioni se pressione della memoria garantisce. Figura 1 illustra come apps spostare tra Stati di esecuzione (vedere bit.ly/TuXN9F per ulteriori informazioni).

How Windows Store Apps Move Between Execution States
Figura 1 come Windows Store Apps spostare tra Stati di esecuzione

Come Figura 1 suggerisce, un'applicazione può muoversi tra esecuzione e sospeso stati frequentemente. Le transizioni di stato del ciclo di vita di app evidenziano la differenza tra apps Store di Windows e applicazioni desktop tradizionali.

Visual Studio 2012 include un ricco set di strumenti, come pure un simulatore di Windows di debug (bit.ly/QzBy5I), che è possibile utilizzare per gestire le operazioni del ciclo di vita di app. Questo è importante, perché è necessario reagire in modo adeguato agli eventi del ciclo di vita di app e di gestire le transizioni di stato correttamente al fine di creare un'esperienza altamente reattiva per l'utente finale, un principio di base della progettazione di app su Windows 8. Rispondere adeguatamente agli eventi del ciclo di vita di app, è possibile assicurare gli utenti hanno un'esperienza coerenza durante il ciclo di vita dell'applicazione. In particolare, questo significa salvataggio e il ripristino dello stato dell'applicazione quando necessario. Questo potrebbe comportare restituendo l'utente torna a dove lei era nell'applicazione (ad esempio un mago), o repopulating i valori di un modulo che stava lavorando su, o ritornare all'ultimo articolo stava leggendo. Poiché application lifecycle è controllata dal movimento dell'utente tramite un app, un'applicazione deve essere preparato a checkpoint lo stato in preavviso un momento di — ogni volta che l'applicazione ottiene l'evento di sospensione.

Attivazione di App

Il processo di WWAHost.exe è un host di app che esegue applicazioni Windows Store JavaScript. Applicazioni XAML scritti con qualsiasi linguaggio — come c#, Visual Basic o C++ — eseguire corrispondente eseguibile dell'applicazione. Ad ogni modo, tutte le applicazioni passare attraverso l'attivazione, che ha un numero di catalizzatori:

L'utente avvia un'applicazione da una tegola.
L'utente passa a un app sospesa.
Windows lancia l'app attraverso un contratto di ricerca o condivisione di destinazione.
Windows richiama un'associazione di protocollo (schema URI) (bit.ly/QyzX04) o lancia un'app a causa di un'associazione di file.
Windows richiama un'estensione, ad esempio un File aperto selezione contratto o Contact Picker.

Come si verifica attivazione determina quale codice deve essere eseguito. Lancia da piastrelle, contratto o protocollo causa una libreria Windows per JavaScript (WinJS) app a fuoco un evento attivato e un app XAML per generare un evento OnLaunched. Durante questi eventi, si verifica lo stato precedente di app per intraprendere azioni appropriate.

Se l'applicazione è in movimento da uno stato di non-esecuzione per lo stato di esecuzione, è necessario caricare i dati freschi, come questa transizione indica che il lancio app provenienti da una tegola, fascino, protocollo o estensione. Se l'applicazione sta tornando da uno stato di sospensione, generalmente è necessario fare nulla; l'utente può solo scegliere da dove ha lasciato. Se l'applicazione è in movimento da uno stato terminato per lo stato di esecuzione, è necessario ricaricare i dati e navigare in app all'ultimo posto, che l'utente è stato (a meno che è stato mesi dopo l'ultimo utilizzo). Codice per gestire l'attivazione è mostrato in JavaScript nel Figura 2 e in c# in Figura 3. Come mostra il codice, è possibile verificare lo stato di esecuzione precedente così come Windows ha lanciato l'applicazione, perché le API di Windows è un pratico set di enumerazioni per entrambi i casi. Una volta che hai queste informazioni, si possono ripopolare i dati come necessario.

JavaScript attivato sia eventi XAML OnLaunched contengono un argomento args che è possibile eseguire una query per determinare lo stato che dell'app è stato prima dell'attivazione. Figura 2 e Figura 3 Visualizza esempi dell'evento attivato.

Figura 2 JavaScript App-attivazione codice

var app = WinJS.Application;
var activation = Windows.ApplicationModel.Activation;
var nav = WinJS.Navigation;
app.addEventListener("activated", function (args) {
  if (args.detail.kind === activation.ActivationKind.launch) {
    if (args.detail.previousExecutionState !==
      activation.ApplicationExecutionState.terminated) {
      // TODO: This application has been newly launched.
      // Initialize your application here.
      } else {
      // TODO: This application has been reactivated from suspension.
      // Restore application state here.
    }
    if (app.sessionState.history) {
        nav.history = app.sessionState.history;
    }
    args.setPromise(WinJS.UI.processAll().then(function () {
      if (nav.location) {
          nav.history.current.initialPlaceholder = true;
          return nav.
          navigate(nav.location, nav.state);
      } else {
        return nav.navigate(Application.navigator.home);
      }
    }));
  }
});

Figura 3 C# App-attivazione codice

async protected override void OnLaunched(LaunchActivatedEventArgs args)
  {
// Check whether the session data should be restored.
    if (args.PreviousExecutionState == 
      ApplicationExecutionState.Terminated)
    {
      // Here we've created a SuspensionManager class that
      // handles restoring session data from a file and
      // then gives access to that data through a Dictionary.
      await SuspensionManager.RestoreAsync();
// Retrieve the data for restore.                 
data = SuspensionManager.SessionState["savedData"];
    }
    // If not, use the app's default values
    else
            {
data = "Welcome";
    }
    Window.Current.Activate();
}

Codice che viene eseguito durante l'attivazione dovrà essere eseguito entro 15 secondi o Windows terminerà l'app. Anche se questo può sembrare severo, apps che bloccare l'utente di interagire con l'interfaccia utente per che non sono molto reattivi. Secondo la ricerca UseIt.com sugli utenti e i tempi di risposta (bit.ly/NWSumy), siti Web che prendono più di 10 secondi per caricare abbandonare la maggior parte degli utenti. Infatti, gli utenti diventano frustrati quando pagine prendono più di 1 o 2 secondi a caricare, e molti di lasciare molto prima il punto di riferimento di 10 secondi. Sapendo questo sugli utenti è particolarmente importante se si prevede di vendere il vostro app nel deposito di Windows, perché gli utenti frustrati post giudizi negativi app — per non parlare che l'applicazione potrebbe non nemmeno passare archivio certificazione se esegue male. (Vedi bit.ly/OxuEfu per ulteriori informazioni sull'invio di un app.) È importante considerare attentamente i dati da caricare e quando. Fortunatamente, le librerie di Windows Runtime (WinRT) rendono facile caricare i dati rapidamente e progressivamente offrendo un modello di programmazione asincrona di prima classe (bit.ly/NCx6gE).

L'oggetto Windows.ApplicationModel.Activation è parte dell'API Windows accessibile da tutte le applicazioni Windows Store, indipendentemente dalla lingua. L'oggetto di attivazione contiene un'enumerazione di activationKind con i seguenti valori:

Lancio: L'utente ha lanciato l'app o sfruttato una tegola secondaria.
Cerca: L'utente vuole cercare con l'app.
ShareTarget: L'app è attivato come destinazione per le operazioni di condivisione.
File: Un app lanciato un file di questo tipo il cui file app viene registrato per gestire.
Protocollo: Un app lanciato un URL cui protocollo questo app è registrato a gestire.
FileOpenPicker: L'utente vuole raccogliere file o cartelle fornite da app.
FileSavePicker: L'utente vuole salvare un file e selezionati app come posizione.
CachedFileUpdater: L'utente vuole salvare un file per il quale app fornisce la gestione dei contenuti.
ContactPicker: L'utente vuole raccogliere contatti.
Dispositivo: L'applicazione gestisce l'AutoPlay.
PrintTaskSettings: L'applicazione gestisce le attività di stampa.
CameraSettings: L'app cattura foto o video da una videocamera collegata.

Perché il vostro app potrebbe supportare più caratteristiche, come la condivisione e la ricerca, l'enumerazione activationKind consente di vedere ciò che è intenzione dell'utente per lanciare l'applicazione e quindi di eseguire il codice corrispondente.

Gestione sospensione, cessazione e ripresa

Quando un utente passa a una diversa applicazione, o il dispositivo entra in ibernazione o va a dormire, Windows si ferma il codice app in esecuzione, ma conserva in memoria le app. Il motivo di questa sospensione è che minimizza l'impatto della batteria e le prestazioni delle applicazioni, da che l'utente non è attivamente sempre valore. Quando Windows si sveglia app dalla sospensione o interruzione di una breve, l'utente dovrebbe sentire come se l'app non aveva mai smesso di esecuzione. Corretta gestione degli eventi del ciclo di vita garantisce una progettazione sensibile.

Windows avvia il processo di sospensione generando un evento XAML OnSuspending dove è possibile salvare dati e informazioni utente prima app si muove in modalità di sospensione o un evento di oncheckpoint di WinJS. Qualsiasi codice che si esegue in questi eventi deve essere completata entro 10 secondi o Windows smette completamente di app. Proprio come con il processo di attivazione, questa regola mantiene la salute generale della scuderia OS e consente il cambio rapido. Aggancio nell'evento oncheckpoint richiede una definizione semplice funzione:

app.oncheckpoint = function (args) {
   // Save app data in case of termination.
};

In XAML, è utilizzare un evento Application.Suspending:

async void Suspending(Object sender,
   Windows.ApplicationModel.SuspendingEventArgs e) {
   // Save app data in case of termination.
}

Durante la sospensione, è necessario salvare la posizione dell'utente oppure scorrere posizione app, rilascio di handle di file, connessioni e indicatore di data e ora i dati. Si può eseguire questa operazione utilizzando gli oggetti predefiniti di WinJS.Application.sessionState o SuspensionManager di XAML. Si deve sempre salvare informazioni utente e dati app in caso di sospensione perché Windows non notificare apps prima termina li. Questo è importante perché la terminazione può verificarsi in una varietà di circostanze, come quando Windows ha bisogno di liberare la memoria o il dispositivo perde (batteria).

Così codice difensivamente e assumere che l'applicazione terminerà. Questo significa che si dovrebbero salvare dati app per sessionState ogni volta. Se Windows terminare l'applicazione, i dati sono salvati e pronti per il ripopolamento.

Curriculum si verifica quando Windows si sveglia un app da sospensione. La maggior parte del tempo, Windows semplicemente riprenderà l'applicazione quando l'utente passa ad essa o si rilancia, e code-wise è necessario fare nulla. Durante la sospensione che l'app appena si siede nella memoria, intatta, così i contenuti dell'app rimane invariato e non non c'è alcuna necessità di intraprendere qualsiasi azione.

Mentre la maggior parte delle applicazioni non serve fare qualsiasi lavoro sulla ripresa da uno stato sospeso, applicazioni che contengono frequentemente cambianti dati — come feed RSS, stock o social networking — sono buoni candidati per l'utilizzo dell'evento ripresa. Perché l'evento ripresa si inserisce questi alcuni scenari specifici, vive nell'oggetto Windows.UI.WebUI.WebUIApplication, piuttosto che nell'oggetto WinJS.Application più comune, accanto alla oncheckpoint, onactivated e altri eventi di pari livello del ciclo di vita:

Windows.UI.WebUI.WebUIApplication.addEventListener("resuming", function () {
   // Repopulate data from sessionState.
});

È possibile aggiungere il gestore resume file js vicino il codice di attivazione per scopi di organizzazione del codice. Mantenere il vostro app reattiva caricando rapidamente la quantità minima di dati durante la ripresa.

Attività in background e comunicazioni in tempo reale applicazioni

Anche se mentre un'applicazione è in modalità sospensione, non viene eseguito il codice dell'interfaccia utente, un'applicazione può eseguire attività in background (bit.ly/QyRvsU), trasferire file di grandi dimensioni o controllare la posta elettronica. Alcune applicazioni di comunicazioni in tempo reale, quali client di messaggistica istantanea, devono essere in grado di informare l'utente quando un messaggio arriva, indipendentemente dallo stato di esecuzione di app.

Attività in background sono classi leggere che eseguire periodicamente, con alcune restrizioni, mentre l'applicazione tecnicamente non è in esecuzione. Corrono nella propria sandbox o contenitori di app, mentre l'applicazione rimane in uno stato di non esecuzione. Attività in background JavaScript eseguito in un apartment a thread singolo nuovo di WWAHost.exe, e attività in background non JavaScript eseguito in un in-process. dll caricato nel proprio appartamento in app di threading. Questa separazione consente operazioni in background eseguire indipendentemente dall'interfaccia utente di un app, che rimane sospesa fino a quando l'utente torna l'app.

Oltre ad essere in grado di eseguire codice in background, queste applicazioni anche visualizzare le informazioni sullo schermo della serratura. La schermata di blocco contiene un'immagine di sfondo con leggeri informazioni sovrapposte su di esso, quali data, ora, lo stato della batteria e sullo stato della rete. Inoltre, apps — in particolare le applicazioni in esecuzione in background — consente di visualizzare informazioni sullo schermo della serratura. Perché è importante mantenere lo schermo della serratura facilmente digeribili, le informazioni che possono essere visualizzate sono limitate. Distintivi da fino a sette apps possono essere visualizzati e il testo da piastrelle di una singola app può essere visualizzato su schermo della serratura. Per ulteriori informazioni, vedere la panoramica sulla schermata di blocco a bit.ly/RsE7pj.

Seguire il modello

Come sviluppatore di applicazioni Windows Store, è necessario essere interessati con questioni quali la pressione di memoria e di vita della batteria, che esegue l'applicazione su una varietà di dispositivi e, cosa più importante, l'UX. Troverete gli obiettivi più facili da raggiungere se si seguono gli orientamenti di gestione del ciclo di vita previsto. Inoltre, oltre le ragioni tecniche per la gestione del ciclo di vita di app, se la vostra applicazione è altamente reattivo e funziona bene, otterrà migliore cliente nell'archivio di Windows.

Rachel Appel è un developer evangelist presso Microsoft New York City. Contattarla tramite il suo sito Web a rachelappel.com o via email a rachel.appel@microsoft.com. È anche possibile seguire i suoi ultimi aggiornamenti su Twitter a twitter.com/rachelappel.

Tmatasse ai seguenti esperti tecnici per la revisione di questo articolo: Adam Barrus, Ben Betz, Arun Kishan, Michael Krause, Hari Pulapaka, John Sheehan e Ben Srour