Windows Phone 7 Series multi-tasking: altre (utili) info

header_logoContinuano a non placarsi i rumors, spesso errati, relativi all’assenza di multitasking su Windows Phone 7 Series. Dopo le tante notizie e le varie interpretazioni, arriva un commento che, vista la fonte, possiamo definire a tutti gli effetti ufficiale (e, IMHO, chiarificatore).

Dunque, l’altro giorno ho parlato di questo argomento cercando, per quanto ne sapessi, di fare chiarezza su come, per grandi linee, funziona il discorso del multitasking. Ora, grazie alla spiegazione di Peter, abbiamo maggiori elementi per comprendere come gestire le nostre applicazioni.

Partiamo da un concetto fondamentale alla base di Windows Phone 7 Series: l’utente è al centro di tutto. Come ho già avuto modo di dire, compreso questo punto cardine, si spiegano tanti elementi del sistema.

Questo concetto è rimarcato anche nel preambolo di Peter: 

…If your application is running when the user switches to another application (by using the Start menu, or tapping on a notification, or via some other means) then our assumption as a platform is that the user now wants to focus on the new application, and doesn’t want the previous one interrupting their experience by grabbing memory, CPU, network bandwidth, or other resources.

Concetto più volte ripetuto: se cambio applicazione, vuol dire che, al momento, l’applicazione che stavo usando non mi interessa. Come emerge dai commenti al mio precedente post però, ci sono situazioni particolari. Ed è a questo punto che, come sviluppatori, dobbiamo capire cosa succede quando la nostra applicazione va in background e come gestire il tutto. Questa parte, fino ad ora, non era sufficientemente chiara:

Before we suspend the application, we give it some time (exact time TBD) to prepare to be suspended. In this time, the application can save global state to disk, sign-off from web sites, or perform other clean-up operations.

Il comportamento non era difficile da intuire ma, vederlo scritto nero su bianco è un sollievo: Windows Phone 7 Series ci “concede” un intervallo di tempo per compiere delle operazioni, tendenzialmente rivolte a non perdere il lavoro che stavamo facendo. Come e cosa salvare è, ovviamente, compito nostro.

Qualche consiglio:

In general this should be relatively simple, because the page-based model of Windows Phone applications facilitates a relatively stateless programming model – much of your application’s state can be encoded in page URIs (as query-string data) or as small blobs of state stored and retrieved on each page navigation, just like the web.

Completato il processo di messa in pausa dell’applicazione…

…further user code will execute…

… ma …

Note that you can still have push notifications coming in from the cloud, so the user can be kept up-to-date via toasts or you can have your tile updated with the latest information from the web.

Le notifiche quindi, da oggi, rivestono un ruolo decisamente di rilievo nelle nostre applicazioni!!!
Ma andiamo avanti:

When your application is suspended, it is not killed immediately. If the user returns to the application “soon” then it can be resumed very quickly and the state saved during pause may not even be necessary.

Il meccanismo quindi è abbastanza furbo: se riprendo l’applicazione abbastanza in fretta, non passo dal processo di sospensione. Su questo punto però, mancano una serie di informazioni che mi aspetto arrivino a breve. In sostanza, c’è da capire di quanto sono questi intervalli di tempo e se ci sono eventi del sistema operativo che possiamo trappare per gestire al meglio la persistenza.
Se però l’applicazione non viene ripresa a breve, o viene avviata un’altra applicazione…

…But if the user launches other applications that end up needing a lot of memory, your process will be killed and the memory will be relinquished to the foreground application. This is a key difference between Windows Phone 7 and previous versions of Windows Mobile – the foreground application gets access to virtually all the resources on the phone (memory, CPU, etc.) without having to worry about being starved by background apps that are doing random things at unpredictable times in the background.

ed ancora

If your process was not killed, resume is trivial – you don’t need to restore any state from disk, but you may need to re-start device features like accelerometer or location, and you may need to re-connect to any web services. Assuming your process was killed, you can use the previously-saved data from pause to re-create your global state, and the per-page state / query-string data to recreate the page state for each page on the back stack.

E’ quindi evidente che, il modo in cui concepiamo le nostre applicazioni è di fondamentale importanza su Windows Phone 7 Series. Se ieri ci preoccupavamo principalmente dello start ed eventualmente dell’on closing della nostra applicazione, oggi dobbiamo anche preoccuparci di pensare alla persistenza delle informazioni e, soprattutto, del resume dell’applicazione.Questo è di fondamentale importanza al fine di ricreare la user experience del multitasking ma senza consumare inutilmente risorse.

Ed infatti:

The end result of all this is that users can switch back and forth between applications and have the illusion of multi-tasking without the downsides of erratic resource usage.

Concordo poi sull’ultimo paragrafo del post di Peter:

Now there are certain multi-tasking scenarios that this model can’t mimic, such as persistent location tracking or background music streaming, but for the vast majority of cases users simply want the ability to either get back to where they were (resume a previous task) or to be notified of updates (via toasts). For these scenarios, we think Windows Phone 7 does a great job.

Per questi casi specifici, non mi sono ancora fatto una idea precisa. Mi piace pensare che, nella maggior parte dei casi su scenari consumer, il modo di far funzionare il tutto ci sia. Ad oggi siamo, secondo me, troppo abituati a ragionare in ottica multitasking per renderci conto che, in moltissimi casi, tale esigenza non è reale (o è applicata solo per mera comodità/ignoranza dello sviluppatore)

Mettiamoci in testa che le nostre applicazioni devono essere concepite in modo totalmente diverso dal passato. Dobbiamo pensarle “user-centriche” e legate a doppio filo con il “cloud” e con le notifiche che rivestono un ruolo decisamente importante.

Fonte: Engagdet’s post on multi-tasking