1

Jan

Il multitasking in Mango: i background agents

Abbiamo già visto nei post precedenti alcune delle principali novità che sono state introdotte in Mango per gestire scenari di multitasking: il Fast App Switching, i Reminders, gli Alarms, ecc.

Oggi vediamo una delle feature più interessanti, ovvero i background agents. Gli agents sono dei servizi che possono accompagnare la nostra applicazione e che possono eseguire delle operazioni in background: si tratta in tutto e per tutto di DLL (e quindi progetti di Visual Studio) separati dall’applicazione vera e propria. Sono però strettamente legati: un agent non può essere usato da altre applicazioni e entrambi accedono alle stesse risorse (ad esempio, leggono e scrivono dallo stesso spazio nell’Isolated Storage). Tipicamente, perciò, parliamo di due progetti appartenenti alla stessa soluzione (anche perchè, come vedremo nel prossimo post, questo ci da alcuni vantaggi).

Uno degli aspetti fondamentali che Microsoft ha voluto tenere a mente nello sviluppo di questa feature sono le performance e il consumo di batteria: sempre tenendo come base il paradigma “al centro l’utente”, non sarebbe stato sensato dare la possibilità agli agents di agire in maniera indiscriminata e incontrollata, soprattutto perchè stiamo parlando di codice di terze parti e quindi non controllabile.

Ecco perciò che sono stati definiti dei limiti ben precisi agli agents, intesi come:

  • frequenza con cui vengono eseguiti
  • durata massima delle operazioni svolte
  • massima quantità di dati trasferita
  • numero di agents in esecuzione in contemporanea.

Il risultato di questa architettura è la definizione di due tipi di background agents: i Periodic Agents e i Resource Intensive Agents. Questi due tipi di agents non sono mutuamente esclusivi: una singola applicazione può definire sia periodic agents che resource intensive agents (anche se ne può avere uno solo per tipo).

Cosa possono fare gli agents?

Tra poco vedremo quali sono le differenze tra i tipi di agents: per ora focalizziamoci però su quali sono le caratteristiche comuni. Entrambi sono dei servizi legati alla nostra applicazione in grado di girare in background, ovvero anche quando l’utente non la sta utilizzando. Esistono però dei vincoli sulle operazioni consentite ad un agent. Ecco quello che possono fare:

  • Aggiornare la tile dell’applicazione.
  • Inviare notifiche di tipo toast.
  • Utilizare i servizi di geolocalizzazione.
  • Connettersi alla rete.
  • Scrivere e leggere dall’Isolated Storage.
  • Utilizzare le socket.
  • Utilizzare la maggior parte delle API messe a disposizione dal framework di Windows Phone.

Ecco invece quello che non possono fare:

  • Mostrare UI (ovviamente, dato che si tratta di servizi).
  • Utilizzare le librerie di XNA.
  • Utilizzare microfono e fotocamera (dato che sono risorse ad accesso esclusivo, solo un’applicazione alla volta può utilizzarle).
  • Utilizzare i sensori (accelerometro, giroscopio, ecc.)
  • Riprodurre audio (a meno che non si usino le API messe a disposizione dal servizio di background audio).

Gli agents hanno una vita massima di 14 giorni: quando vengono creati è possibile definirne un tempo di vita diverso, ma comunque non potrà mai superare i 14 giorni. Se la vostra applicazione viene però utilizzata con regolarità dall’utente, non avrete problemi: ad ogni avvio infatti il background agent verrà rinnovato per altri 14 giorni. Scopo di questo limite è evitare che applicazioni installate e poi dimenticate perchè non più utilizzate abbiano comunque la possibilità di consumare risorse e batteria tramite gli agents.

Vediamo ora i due tipi di agents esistenti e le loro differenze.

I periodic agents

I periodic agents nasconono per scenari in cui sono richiesti aggiornamenti frequenti e di breve durata: vengono infatti eseguiti ogni 30 minuti e possono eseguire operazioni per un massimo di 15 secondi e che non occupino più di 5 MB di memoria. I periodic agents vengono eseguiti uno alla volta se l’utente sta utilizzando il device, altrimenti se il telefono è in standby (schermo spento) vengono eseguiti in parallelo. L’obiettivo è quello di non “disturbare” l’utente e di sottrarre all’applicazione che si sta utilizzando meno risorse possibili in termini di memoria e consumo del processore.

Sul telefono possono essere attivi massimo 14 periodic agents contemporaneamente: per tale scopo, è stato introdotto un pannello di gestione che permette all’utente di vedere quali background agents sono installati nel device e di disabilitare quelli che non vuole mantenere attivi. Questo pannello, posizionato nell’hub Settings, in realtà è in grado di mostrare tutti i tipi di agent: è possibile intervenire però solo sui periodic agents dato che, come vedremo tra poco, gli altri tipi di agents non influiscono sulla batteria e sulle prestazioni del telefono.

I periodic agents sono oggetti di tipo PeriodicTask e vengono istanziati e definiti all’interno dell’applicazione. Ogni agent (così come tutti gli altri task in background) è identificato da un nome ed è caratterizzato dalle seguenti proprietà:

  • BeginTime: di tipo DateTime, rappresenta la data e l’ora a partire dalla quale il background agent si attiva.
  • ExpirationTime: di tipo DateTime, rappresenta la data e l’ora in cui l’agent sarà disattivato. Come detto in precedenza, anceh se impostate un valore superiore ai 14 giorni questo verrà ignorato.
  • Description: è la descrizione di cosa fa il background agent e viene visualizzata nel pannello di controllo di gestione degli agents. E’ importante per dare all’utente informazioni sufficienti per capire se è interessato o meno a mantenere attivo il servizio.

I periodic agents nascono per soddisfare tutte quelle esigenze in cui è richiesta la sincronizzazione di pochi dati in maniera regolare: può essere un client Twitter, che verifica periodicamente la presenza di nuovi tweet e aggiorna la tile di conseguenza; può essere un’applicazione di tracciamento dei nostri spostamenti, che periodicamente comunica ad un server la nostra posizione, ecc.

Uno dei vantaggi principali nell’utilizzo di questi servizi è che in alcuni casi rendono superfluo l’utilizzo delle notifiche push e, soprattutto, di sviluppare e mantenere applicazioni lato server: riprendendo l’esempio del client Twitter, prima dell’avvento dei background agents saremmo stati costretti a realizzare un’applicazione server in grado di controllare periodicamente la presenza di nuovi tweet e di inviare una notifica push di tipo tile. Ovviamente, le notifiche push hanno ancora la loro importanza: sono infatti indispensabili in tutti gli scenari in cui abbiamo bisogno una comunicazione in tempo reale (ad esempio, vogliamo avvisare l’utente che la sua squadra del cuore ha segnato un gol nel momento stesso in cui succede e non aspettare il primo slot temporale di 15 secondi messo a disposizione dal device al nostro agent).

Resource Intensive agents

I resource intensive agents nascono invece per scenari di sincronizzazione poco frequenti, ma che coinvolgono una grande quantità di dati e di operazioni da svolgere. Questo tipo di agents vengono eseguiti solo nel momento in cui il device è sotto carica e collegato ad una rete Wi-Fi e possono eseguire operazioni per un massimo di 10 minuti. Come anticipato poco fa, questi agents non sono disattivabili dal pannello di gestione, proprio perchè non incidono sulla batteria del device.

I resource intensive agents sono ideati per scenari di sincronizzazione remota: pensate ad esempio ad un’applicazione che deve gestire il trasferimento di grosse quantità di dati (ad esempio, le foto scattate durante la giornata verso un servizio come Flickr). In caso di necessità di sincronizzazione a breve termine di qualche file possiamo ricorrere ai Background Transfers (che vedremo nel prossimo futuro); se invece vogliamo semplicemente trasferire la nostra libreria, ci basterà attaccare il telefono a ricaricare durante la notte per far si che il background agent entri in azione e completi il trasferimento.

I resource intensive agents sono oggetti di tipo ResourceIntensiveTask: anch’essi sono definiti all’interno dell’applicazione, sono identificati da un nome e sono caratterizzati dalle proprietà BeginTime, ExpirationTime e Description.

In conclusione

Nel prossimo post vedremo concretamente come creare, utilizzare e debuggare un background agent per la nostra applicazione.

by Il blog di Matteo Pagani on 1/1/2012
Post archive