La gestione dello stato delle applicazioni su Windows Phone 7

Print Content | More

0456.image_thumb_4249219B

Penso lo sappiate tutti, ma Windows Phone 7, esattamente come l’iPhone, non è multitasking: solo le applicazioni native (come Outlook) hanno la possibilità di girare in background, tutte le applicazioni di terze parti possono essere eseguite solo una alla volta. Come abbiamo visto in un post precedente le notifiche push sono nate proprio per sopperire ad una delle limitazioni di non avere un OS multitasking. Le notifiche però non soddisfano tutti gli scenari problematici che si possono verificare con un’architettura di questo tipo: non è piacevole che l’utente, dopo aver premuto il tasto Back o il tasto Start (magari inavvertitamente), si trovi a dover lanciare l’applicazione da capo e a ripetere tutti i passaggi necessari per tornare allo stato che aveva lasciato.

Per gestire questa situazione Windows Phone ha introdotto il concetto di suspend, ovvero quando l’applicazione viene chiusa in maniera non definitiva (telefonata in arrivo, pressione del tasto Back, ecc.): in questo caso lo stato dell’applicazione viene salvato, per essere ripristinato in caso in cui l’applicazione venga riaperta. Lo sviluppatore ha poi la possibilità di intercettare gli eventi legati a questo stato per implementare la propria logica.

Quello che magari non è risaputo è che l’architettura di funzionamento dello stato delle applicazioni è cambiato sensibilmente dalla release dei tool di Aprile (ancora in CTP) alla beta uscita poche settimane fa.

La vecchia architettura

Nella release di Aprile, Windows Phone 7 aveva introdotto un vero e proprio concetto di sospensione: quando l’applicazione veniva terminata non per esplicità volontà dell’utente veniva “congelata”, ovvero messa in background e il suo stato mantenuto. Si trattava comunque di un background fittizio, dato che l’applicazione non aveva modo di eseguire processi mentre era in questo stato. Nel sistema operativo c’era poi un processo (che possiamo paragonare, anche se impropriamente, ad un garbage collector) che si occupava di chiudere le applicazioni che erano rimaste sospese per troppo tempo oppure nel momento in cui era necessaria più memoria.

La nuova architettura

La release di Giugno ha mantenuto le stesse caratteristiche (salvataggio dello stato), ma cambiandone profondamente l’architettura, introducendo il concetto di tombstoned. Ora le applicazioni vengono sempre e comunque terminate, anche quando non è stato l’utente a richiederlo esplicitamente. Quello che avviene però è che viene salvato in memoria, in uno spazio ben preciso, un tombstoned, ovvero lo stato dell’applicazione, così che al suo riavvio possa essere ripristinato. Il tombstoned entra in gioco solo nel momento in cui l’applicazione viene riaperta tramite la pressione del tasto Back o perchè l’evento che ne ha provocato la chiusura si è concluso (è terminata la telefonata, ho spedito la mail, ecc.). Se l’utente decide di aprirla da zero, passando per il menu principale del telefono, allora il tombstoned viene scartato. Lo stesso può accadere se l’applicazione rimane disattivata per troppo tempo. Il concetto di fondo è quindi salvare il prima possibile, all’interno della vostra applicazione, le varie interazioni che l’utente fa (compilazione di un form, modifica di un’impostazione, ecc.) e non aspettare, ad esempio, quando l’applicazione viene chiusa.

Gli eventi utilizzati per gestire questi stati sono stati cambiati per riflettere questa nuova architettura: non parliamo più quindi di “suspended”, ma di activated e deactivated.

Attingiamo alla sorgente

E’ estremamente importante, per chi vuole sviluppare seriamente su Windows Phone 7, comprendere questa architettura, perchè capiterà sicuramente prima o poi che la vostra applicazione venga interrotta da una telefonata o da un SMS: bisogna quindi saper gestire al meglio queste casistiche, per evitare situazioni impreviste o problemi per l’utente (dover ripetere da capo un’operazione perchè non abbiamo gestito correttamente lo stato non è il massimo). Le informazioni che vi ho dato “grattano” solamente la superficie: ci sono tanti altri dettagli importanti da capire e conoscere. E quale risorsa migliore di quelle scritte da chi questo sistema l’ha progettato?

Vi consiglio caldamente perciò la lettura di un post intitolato Understanding the Windows Phone Application Execution Model, Tombstoning, Launcher and more… pubblicato sul blog del team di sviluppo di Windows Phone 7, suddiviso in tre parti data la lunghezza. I post trattano l’argomento in maniera molto approfondita ma anche molto semplice da capire e troviamo anche degli esempi di codice da scaricare che possiamo utilizzare per fare esperimenti.

Vi lascio perciò con i link delle tre parti in cui è stato suddiviso il post:

Se invece preferite leggere una risorsa in italiano, Corrado Cavalli ha dedicato un post sul suo blog a questo aspetto, che potete leggere qui

Buona lettura!


Windows Phone , Microsoft , Multitasking

0 comments

Related Post


(will not be published)
(es: http://www.mysite.com)