Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola App Lifecycle and Session State

Transcript

1 Tesina esame Programmazione di Sistemi Mobile realizzata da Roberto Giuliani matricola App Lifecycle and Session State

2 In questa tesina si approfondisce il concetto di Ciclo Di Vita di un applicativo Windows Phone ed i corrispondenti stati che lo distinguono. Come tutti sappiamo, quando un applicazione viene eseguita ed è in esecuzione nella schermata del dispositivo essa viene definita in stato di running. Questo stato è mantenuto fino a quando l utente utilizza direttamente l applicativo (senza depositarlo in background). Quello che interessa ora a noi è: Cosa succede quando non è in stato di running? Come viene gestito dal sistema? Quanti altri stati sono presenti? E quando entrano in gioco? In un mondo perfetto si potrebbe immaginare la possibilità di utilizzare un unica app per tutto, la quale permetta di scrivere messaggi, effettuare chiamate, visualizzare immagini.. In questo caso la gestione degli stati sarebbe molto semplice, un solo stato, cioè running che si avvia all accensione e rimane attivo fino allo spegnimento del dispositivo. Questo però avviene solo in un mondo immaginario, nella dura realtà tale concetto non è possibile! Non importa quanto piaccia o quanto sia completa quella applicazione, ci sarà sempre bisogno di trasferirsi da una ad un altra nel momento in cui si decida di svolgere un differente compito (che per esempio nel caso in cui l applicativo precedente non possa soddisfarlo). Per meglio dire, gli utenti sono abilitati a switchare tra le varie applicazioni, cambiando i view states, chiudendo applicazioni ed eseguendone altre, e nulla di questo può essere controllato. Ma solo gestito. Per questo motivo l applicazione deve comportarsi correttamente in tutte le circostanze! Questo viene previsto aggiungendo vari stati con caratteristiche differenti in maniera da garantire una corretta gestione dei differenti momenti (chiamati cicli di vita) dell app. La prima considerazione è detta FOCUS, che si applica quando controlli la tua applicazione. Si possono utilizzare semplicemente gli standard HTML per gli eventi blur e focus. Per esempio, se un gioco d azione in esecuzione sul dispositivo tipicamente viene messo in pausa (da sé stesso o per motivi esterni) viene invocato il metodo windows.onblur (cioè è stato perso il focus) e magari quando l utente si ricollega il windows.onfocus. NOTA: Questo non implica che l applicazione potrebbe smettere di funzionare, anzi, è il programmatore che ha il pieno controllo e può decidere il da farsi. (Vedi MediaPlayer di Windows). Come è possibile osservare dell immagine precedente, dove l applicativo risulta essere in stato di FOCUS. Un ulteriore condizione è VISIBILITY. Un applicativo può essere visibile ma non essere in focus, come quando viene condiviso uno schermo, oppure quando l applicativo è in esecuzione ma non in focus (come visibile dall immagine a fianco). In questo caso un app continuerebbe l esecuzione di elementi come animazioni o uploading, ma fino a quando visibility non viene a meno. Si utilizza perciò l evento visibilitychange nel DOM API e le proprietà del visibilitystate dell oggetto windows o document. Il cambiamento dei visibility è anche un buon modo per salvare i dati utenti nei documenti o, nel caso dei giochi, i progressi effettuati.

3 Facciamo ora un paio di considerazioni sullo stato closed. Un applicativo entra in tale stato quando viene effettuato uno swipe dal basso verso l alto nella schermata dei multi-task oppure semplicemente premendo ALT+F4. E importante notare che l applicazione è inizialmente spostata nello stato di off-screen (hidden), poi sospesa ed infine chiusa. In tal modo da non utilizzare troppo i tipici eventi DOM come body.unload. Differente invece quando un utente rimuove l applicazione direttamente dal Task Manager, nella quale, facendo Termina Attività nelle proprietà vengono tralasciati tutti i processi ed eseguita direttamente la chiusura. Ricordiamo inoltre che nessuna applicazione dovrebbe chiudersi da per sé senza darne un significato a meno che non sia una richiesta dell utente (questo violerebbe il Store Certification Requirements). Ma può essere utilizzato MSApp.terminateApp per una chiusura forzata dovuta alla condizione di stato: corrupted (corrotto) che si presenta quando avviene un anomalia interna. Suspend, Resume and Terminate Al di là di focus, visibility e view sates, ci sono altri tre differenti momenti critici nella vita di un app:. Suspending Quando un app non è visibile in alcun view state, essa verrà sospesa dopo cinque secondi (in accordo con il wall clock) per garantire una conservazione ottimane della batteria. Esso significa che rimane impiantato in memoria ma non sarà schedulato nel CPU time e non saranno presenti attività sul network e sul disco (a meno che non siano richieste attività di background). Quando questo accade l app riceve l evento Windows.UI.WebUIApplication.onsuspending. L app ha il compito di uscire da questo evento entro i successivi 5 secondi di periodo o Windows assumerà che è bloccata e terminerà. Durante questi secondi le applicazioni salvano gli stati di transizione e dovrebbero anche rilasciare qualsiasi risorsa che avevano richiesto in precedenza.. Resuming Se l utente torna all applicazione sospesa esso riceve l evento Windows.UI.WebUIApplication.onresuming. Esso è utilizzato per eseguire il refresh di qualsiasi informazione che potrebbe essere stata cambiata mentre l applicativo era in stato di sospensione (suspending). Per esempio, se l app è connessa ad un servizio online ed è passato abbastanza tempo da quando era iniziata la sospensione, allora verrà richiamato questo metodo per eseguire un refresh di tale servizio, ricontrollando lo stato della connessione. Questo non avviene solo con i servizi online, ma anche con sensori di tracking, per eseguire appunto un refresh della lettura e con altri differenti servizi. Bisogna sottolineare che questa tecnica di programmazione è sempre maggiormente utilizzata.. Terminating Quando sospesa, un app potrebbe essere terminata se c è la necessità di più memoria. Non ci sono eventi per questo perché per definizione l app è già sospesa e nessun codice può essere eseguito. Tuttavia questo è importante per il ciclo di vita delle app perché incide sul previousexecutionstate per quando l app verrà riavviata. Nella figura è possibile vedere brevemente un semplice ciclo di vita di un app e gli stati sopra citati, con i rispettivi metodi invocati per il cambiamento di stato.

4 Prima di proseguire è lecito fare un accenno alle funzionalità che mette a disposizione Visual Studio; infatti esso permette di simulare queste condizioni tramite una toolbar. Questi comandi invocheranno i rispettivi eventi sopra citati. La domanda che sorge spontanea riguarda che cosa si dovrebbe fare con il valore contenuto in previousexecutionstate. Inizialmente analizziamolo in dettaglio e poi enunciamone il funzionamento: Se l activation kind è launch e lo stato precedente è notrunning o closedbyuser (come si possono vedere dall immagine precedente degli stati del ciclo di vita), l applicazione dovrebbe avviarsi con la sua interfaccia utente di default e applicare qualsiasi persistent state o settings presente. Ci potrebbero essere scenari per la quale l applicazione debba eseguire ulteriori azioni dopo che l utente esplicitamente chiuda l app e la lasci chiusa per un determinato periodo. Se l activation kind è launch e lo stato precedente è terminated, l app dovrebbe avviarsi nello stesso session state della sua ultima sospensione (stato suspended). Per launch e altre activation kinds che includono addizionali argomenti o parametri, esso dovrebbe inizializzare se stesso per permettere a tale scopo l utilizzo dei parametri aggiuntivi. L app potrebbe essere già in esecuzione (stato running) perciò non sarà necessario inizializzare ancora lo stato di default. Quello che è stato presentato adesso è proprio la relazione che lega gli eventi del ciclo di vita ai session state. Quando Windows determina un app in sospensione (suspended app), accade che nella testa dell utente l app è tuttora in esecuzione. Così quando l utente riattiva il normale utilizzo dell app (activation kind in launch), lui o lei si aspetta che l app sia in perfetta esecuzione e nel punto in cui era rimasta precedentemente. Questo significa che quando un app entra nello stato suspended essa necessita di avere salvati tutte le informazioni per rendere continuo l utilizzo da parte dell utente. E poi reidrata l app da questo stato quando previousexecutionstate è terminato. Questo permette di creare una forma di continuità tra i confini di suspend-terminate-restart. Sia chiaro comunque che se l utente chiude direttamente l applicazione effettuando lo swipe nel multi-task o premendo ALT+F4, l evento suspending e checkpoint saranno sospesi, così l applicazione conserva ancora lo stato della sessione. Comunque all app non sarà chiesto di riaggiornare il session state quando verrà eseguito il restart perché previousexecutionstate sarà notrunning o closedbyuser. Esso funziona meglio, in realtà, quando, per salvare lo stato della sessione, cambia il ciclo di vita dell app, riducendo al minimo il lavoro necessario in caso di sospensione (dove si hanno solo cinque secondi). Lo stato di sessione non include il persistent state, ma permette di illudere l utente che l applicazione è sempre in stato di esecuzione. Per questo motivo viene sempre salvato il session state nella cartella appdata, il quale è fornito dalle API di Windows.Storage.ApplicationData. Vediamone un veloce estratto: Primo è l evento WinJS.Application.checkpoint che è sollevato quando suspending termina. Checkpoint prevede un singolo posto dove salvare entrambi i session state e qualsiasi altro dato persistente si possiede. Inoltre se si ha la necessità di fare qualsiasi async work in questo handler, sii sicuro di passare il promise per questa operazione al eventargs.setpromise. Questo si lega al meccanismo WinRT deferral con l attivazione (vedi scritto sotto Suspending Deferrals ).

5 Secondo è l oggetto WinJS.Application.sessionState. Nel normale avvio, questo è solo un oggetto vuoto nel quale tu puoi aggiungere qualunque proprietà desideri, inclusi altri oggetti. Una tipica strategia è usare il sessionstate direttamente come un container per variabili di sessione. Entro l evento checkpoint, WinJS automaticamente serializza i contenuti di questo oggetto (utilizzando JSON.stringify) in un file interno alla tua cartella locale appdata (questo implica che tutte le variabili in sessionstate devono avere una rappresentazione String). Nota che, WinJS garantisce che il suo stesso handler per checkpoint è sempre chiamato dopo la tua app e successivamente riceve l evento, in tal modo si può essere assicurati che WinJS salverà qualunque cosa tu scriva in sessionstate ad ogni momento prima che ritorni il checkpoint handler. Poi quando l app è attivata con lo stato precedente di terminated, WinJS automaticamente reintegrerà l oggetto sessionstate così che ogni cosa venga inserita al suo interno sia ancora una volta disponibile. Se viene utilizzato questo oggetto per memorizzare variabili, allora si ha la necessità di evitare di impostare questi valori a quelli predefiniti quando ricarica lo stato. In conclusione, se non si desidera utilizzare l oggetto sessionstate o si hanno degli stati che non lavoreranno con tale oggetto, l oggetto WinJS.Application rende più semplice la scrittura del tuo file senza dover utilizzare le APIs async WinRT. In maniera più specifica esso prevede gli oggetti local, temp e roaming il quale ognuno presenta i metodi chiamati readtext, writetext, exists e remove, da utilizzare proprio per questo scopi al posto del sessionstate.