2

Jul

Il multitasking in Mango – Fast App Switching e il nuovo ciclo di vita delle applicazioni

Iniziamo con questo primo post ad analizzare le novità per gli sviluppatori introdotte in Mango e partiamo da una delle feature a me più care, alla quale ho dedicato anche una sessione al WhyMCA: il multitasking.

Se abbiamo seguito il MIX, sappiamo che Windows Phone non implementa il multitasking in maniera tradizionale (alla Windows Mobile 6.5 o Android per intenderci, dove tutte le applicazioni rimangono effettivamente aperte e funzionanti fino a che non vengono esplicitamente terminate), ma offre una serie di servizi che permettono di eseguire alcuni tipi di operazioni in background e di passare velocemente da un’applicazione all’altra, senza incidere in maniera drastica sulle performance e sulla batteria.

Nelle prossime settimane parleremo perciò di Fast App Switching, di background agents, background audio e background transfers.

Iniziamo oggi parlando di Fast App Switching e del nuovo ciclo di vita delle applicazioni, introdotto per dare la possibilità all’utente di passare velocemente da una applicazione all’altra, eliminando (anche se non del tutto, come vedremo) il fastidioso messaggio Resuming che viene visualizzato nel momento in cui l’applicazione viene “risvegliata” dalla sospensione.

Le demo mostrate sia al Mobile World Congress che al MIX dovrebbero avervi fatto capire chiaramente che cos’è il Fast App Switching: il passaggio da una applicazione all’altra (nello specifico, si trattava di un gioco, Rise Of Glory) avveniva istantaneamente. L’utente era in grado di premere il pulsante Back e nel giro di un paio di secondi riprendere a giocare tranquillamente: oggi questo non è possibile, dato che quando un’applicazione viene sospesa il processo viene terminato perciò, quando questa viene riattivata, deve essere inizializzata da capo e deve essere recuperato lo stato dal tombstone. Se volete rinfrescarvi la memoria, vi rimando alla lettura dei post che avevo dedicato a suo tempo al ciclo di vita delle applicazioni Windows Phone 7.0. (Post 1Post 2Post 3)

E’ ovvio perciò che l’introduzione di questa feature debba aver cambiato questo ciclo di vita, dato che non è possibile che un’applicazione terminata venga riportata in vita in un tempo così breve. Vediamo perciò uno schema che rappresenta il nuovo ciclo di vita di Mango:

lifecycle

 

La novità sta nell’introduzione di un nuovo stato, chiamato Dormant, in cui il processo non è più terminato, ma semplicemente sospeso. Come vedremo nel post successivo, il sistema operativo adotterà tutta una serie di accorgimenti per ridurre al mimimo l’impatto sulle performance e sulla batteria (terminando ad esempio tutti i thread e chiudendo tutte le connessioni alla rete), ma l’applicazione fondamentalmente è ancora “viva”. Ecco perchè è possibile avere un restore così veloce! Il sistema dovrà solamente ricollegare le risorse che sono state disconnesse, ma non dovrà reinizializzare l’applicazione da capo.

Come possiamo vedere nello schema, però, lo stato Tombstoned esiste ancora: inoltre, abbiamo ancora la necessità di salvare lo stato della nostra applicazione nel momento in cui questa viene sospesa. Mantenere troppe applicazioni in stato Dormant, infatti, può influire negativamente sulle prestazione del telefono: nel momento in cui la memoria disponibile non sia sufficiente, il sistema operativo è in grado di portare le applicazioni più vecchie nello stato Tombstoned. In questo caso, il ciclo di vita diventa lo stesso delle applicazioni Windows Phone attuali: il processo viene terminato e, nel caso in cui l’applicazione venga riattivata, questo viene reinizializzato e lo stato recuperato dal tombstone.

La differenza rispetto al passato è che ora lo stato dobbiamo recuperarlo solo nel momento in cui l’applicazione è in Tombstoned: se si trovava in stato Dormant, infatti, non è necessario, essendo il processo ancora attivo. A questo scopo ci viene in aiuto una proprietà esposta dalla classe ActivatedEventArgs, la cui istanza viene restituita tra i parametri di ritorno del metodo Application_Activated esposto nell’App.xaml.cs. Questa proprietà di tipo booleano si chiama IsApplicationStatePreserved e ha valore true se l’applicazione proviene da uno stato Dormant, false se invece proviene dallo stato Tombstoned. Ecco lo scheletro del metodo Application_Activated in cui idealmente gestiamo questa casistica:

private void Application_Activated(object sender, ActivatedEventArgs e)
      {
      if (e.IsApplicationInstancePreserved)
      {
      //Ricollego le risorse disconnesse
      }
      else
      {
      //Recupero lo stato dal tombstone
      }
      }

Nel prossimo post

Nel prossimo post vedremo più in dettaglio cosa succede quando un’applicazione va in stato Dormant: vedremo inoltre come possiamo debuggare il passaggio da uno stato all’altro, aiutandoci con un piccolo progetto di esempio. Alla prossima!

by Il blog di Matteo Pagani on 7/2/2012
Post archive