Windows Phone, Mango, DotNetLombardia, Microsoft, Marketplace, Chevron WP7, Background agents, Multitasking, ASPItalia

Visto il buon riscontro ricevuto sull'evento organizzato da DotNetLombardia su Windows Phone Mango abbiamo deciso di invogliarvi a mettere in pratica quello che è stato mostrato durante quella giornata. Eccomi qui perciò a presentare un piccolo contest di sviluppo per applicazioni Windows Phone!

La recente release della beta 2 dei tool di sviluppo e della beta di Mango per i device in commercio è l’occasione perfetta per invitare tutti a voi a realizzare un’applicazione per Windows Phone Mango! Avete tempo fino al 1° Settembre: una giuria composta dai membri di DotNetLombardia giudicherà le migliori, che verranno premiate con i seguenti gadget.

• 1° posto: Polo brandizzata Windows Phone Mango + 1 abbonamento per un mese a Pluralsight (accesso illimitato a tutti i corsi offerti dal portale per un 1 mese)
• 2° e 3° posto: maglietta di DotNetLombardia

Le applicazioni verranno valutate in base ai seguenti criteri:

• usabilità
• funzionalità
• idea innovativa
• uso intelligente di una o più delle nuove feature introdotte in Mango
• design

Al momento, non è ancora possibile caricare applicazioni Mango sul Marketplace: ecco perciò che vi chiederemo di inviarci il vostro XAP. Ovviamente, l’invito è quello di pubblicare le vostre applicazioni appena sarà possibile, così da condividerle con tutti gli utenti Windows Phone!

Cosa aspettate? Per l’occasione abbiamo messo in piedi un minisito dedicato, con il regolamento completo e il form di partecipazione.

Lo trovate all’indirizzo http://mangocontest.dotnetlombardia.org

In bocca al lupo!

This entry was posted on Monday, 11 July, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

Nella beta 2 dei tool di sviluppo, rilasciata qualche giorno fa, sono state introdotte una serie di modifiche inerenti ai background agents e ai background transfers. Non si tratta di cambiamenti importanti: relativamente ai background agent l’architettura rimane la stessa che vi ho descritto nei post che ho dedicato all’argomento qualche tempo fa. Se però cercate di eseguire la demo che era allegata al post questa non funzionerà più. Vediamo perchè.

L’evento OnCancel è stato eliminato

Se vi ricordate, il progetto del Background Agent conteneva un metodo opzionale chiamato OnCancel, in cui era possibile specificare eventuali operazioni da eseguire nel momento in cui lo slot di tempo assegnato all’agent stava per scadere. Questo metodo è stato eliminato: ora però le classi dedicate ai background agents (PeriodicTask e ResourceIntensiveTask) espongono delle nuove proprietà che ci permettono di recuperare informazioni sull’ultima esecuzione.

• LastExitReason: è una proprietà di tipo AgentExitReason che ci informa sullo stato dell’ultima esecuzione. Può assumere i seguenti valori:
• Aborted
• Completed
• ExecutionTimeExceeded (quando è scaduto lo slot di tempo assegnato)
• MemoryQuotaExcedeed (quando è stata superata la massima quantità di memoria utilizzabile da un agent)
• None
• Other
• Terminated
• UnhandledException (quando si è verificata un eccezione non gestita)
• LastScheduledTime: è una proprietà di tipo DateTime che ci dice l’ultima volta che l’agent è stato eseguito.

Un nuovo metodo per testare i background agent

Se ricordate, per testare un background agent era necessario aggiungerlo ai task in background schedulati nel sistema (utilizzando la classe ScheduledActionService), dopodichè uscire dall’applicazione e rimanere in attesa che l’agent venisse eseguito. Il processo però non era esente da problemi e spesso e volentieri succedeva che il background agent non venisse eseguito, oppure partisse mentre l’applicazione era ancora in esecuzione (e quindi non era possibile vederne gli effetti).

Per ovviare a questo inconveniente, nella beta2 è stato aggiunto un nuovo metodo da utilizzare solamente in debug, che si occupa di lanciare il background agent dopo un periodo di tempo da noi stabilito. Le operazioni base non cambiano: nell’applicazione in foreground dovremo creare un nuovo task, configurarlo e aggiungerlo ai task schedulati usando il metodo Add esposto dalla classe ScheduledActionService. La novità è che ora dobbiamo eseguire una operazione in più: eseguire il metodo LaunchAndTest (sempre esposto da ScheduledActionService) specificando il nome dell’agent e dopo quanto tempo dal momento in cui il task viene aggiunto vogliamo che questi venga eseguito (sotto forma di TimeSpan). Vediamo un esempio:

PeriodicTask action = ScheduledActionService.Find("TestAgent") as PeriodicTask;
if (action != null)
    ScheduledActionService.Remove("TestAgent");

PeriodicTask task = new PeriodicTask("TestAgent")
{
    Description = "Test task",
    ExpirationTime = DateTime.Now.AddDays(7)
};

ScheduledActionService.Add(task);
ScheduledActionService.LaunchForTest("TestAgent", new TimeSpan(0, 0, 10));

In questo esempio, il task in questione verrà lanciato dopo 10 secondi che è stato aggiunto ai servizi in background: questo ci darà tutto il tempo di uscire dall’applicazione e attendere l’esecuzione.

Un nuovo percorso per i background transfers

Nella serie di tutorial sul multitasking in Mango che sto scrivendo non abbiamo ancora affrontato i background transfers: tranquilli, arriveranno a breve Se avete già iniziato a fare qualche esperimento, saprete che si tratta di una nuova classe che permette di gestire download e upload all’interno della nostra applicazione che possono rimanere in esecuzione anche quando la chiudiamo.

Dato che il trasferimento potrebbe terminare anche quando l’applicazione è chiusa, le API dedicate ai background transfers salvano i file direttamente nell’Isolated Storage, in una cartella ben precisa che, se non esiste, viene creata. Tale cartella, nella beta 1, si chiamava transfers ed era posizionata nella root dello storage. Nella beta 2 questa cartella si chiama sempre transfers, ma è stata spostata sotto la cartella shared, la quale è dedicata a contenere una serie di dati che possono essere condivisi tra l’applicazione e i servizi in background (come le immagini da utilizzare per aggiornare la tile).

Il nuovo percorso quindi è shared/transfers, partendo dalla root dell’Isolated Storage. Ci torneremo comunque quando parleremo più in dettaglio di background transfers.

In conclusione

Se dovessero emergere altri cambiamenti importanti, pubblicherò sicuramente altri post con i dettagli! Nel frattempo, trovate qui sotto il link per scaricare la versione aggiornata alla beta2 del progetto demo sui Background Agents. Buon download!

This entry was posted on Monday, 04 July, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

Un po’ a sorpresa Microsoft ha rilasciato ieri due importantissime novità per tutti gli sviluppatori Windows Phone: la beta 2 dei tool di sviluppo per Mango e, soprattutto, l’accesso alla ROM beta di Mango per i device attualmente in commercio. Vediamo qualche dettaglio.

I tool di sviluppo

A distanza di poco più di un mese, Microsoft ha rilasciato una nuova beta dei tool di sviluppo per Mango, che non stravolge quanto già visto con la beta 1 ma si limita a risolvere bug e ad “affinare” alcuni aspetti in previsione del rilascio finale. Vi consiglio la lettura del changelog ufficiale: oltre ad alcuni breaking changes importanti (come nei background agents e background transfers, che dettaglierò in un post a parte) c’è anche l’elenco completo delle known issues, ovvero dei problemi noti nell’utilizzo di alcune API. In questo modo, nel caso doveste trovare problemi durante lo sviluppo avrete modo di verificare se si tratta di un vostro bug o di un problema riconosciuto.

I tool si scaricano all’indirizzo http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26648 . La procedura corretta per l’installazione prevede la previa disinstallazione della beta 1 dei tool.

Beta di Mango

La notizia che tutti gli sviluppatori attendevano con ansia è finalmente diventata una realtà: Microsoft ha reso disponibili a tutti gli sviluppatori con un account sul Marketplace una beta di Mango, installabile sui device attualmente in commercio. A partire da ieri pomeriggio alle 17 Microsoft ha iniziato a spedire a tutti i proprietari di un account un invito su Connect, la piattaforma Microsoft dalla quale si potrà scaricare la ROM. Ovviamente si tratta di una beta, con tutti i limiti del caso: recentemente ho però avuto modo di utilizzare e “giocare” con un prototipo dotato di Mango e vi posso assicurare che la stabilità e la reattività del sistema è più che ottima, quasi non si direbbe che è una beta. Potete quindi installare Mango con una certa serenità: le funzionalità del vostro telefono non verranno compromesse, anzi! L’unica accortezza è quella di seguire alla lettera il documento di istruzioni e, soprattutto, di salvare in un luogo sicuro il backup che verrà creato dal tool prima di procedere con l’update: al rilascio ufficiale di Mango, infatti, dovrete usarlo per ripristinare il vostro telefono ad uno stato pre-Mango. Solo in questo modo potrete ricevere l’aggiornamento ufficiale!

La buona notizia è che il processo di installazione è molto semplice e, cosa molto importante, non richiede un restore del telefono: esattamente come un update ufficiale, il vostro telefono verrà aggiornato mantenendo tutte le vostre impostazioni e i vostri dati (applicazioni, contatti, foto, ecc.). Gli step da seguire sono:

• Installazione della beta di Zune 4.8 (che supporta i telefoni Mango)
• Utilizzo di un tool che si occuperà di fare il prezioso backup e di installare un primo update della ROM, che "sblocca" il device abilitandolo a ricevere Mango.
• Installazione di due update direttamente tramite Zune, come se si trattasse di un aggiornamento ufficiale.

Unico accorgimento: come vi dicevo poco fa, al rilascio ufficiale di Mango dovrete ripristinare il telefono al backup che avete fatto; questo significa che perderete tutti i dati che salverete nei prossimi mesi, a meno che non li salviate da qualche altra parte (operazione facile ad esempio per foto e musica, un po’ meno se si tratta di dati di applicazioni installate, come i salvataggi dei giochi).

Ultima nota importante: prendetevi del tempo! L’intera procedura porta via infatti più di un’ora, non fatela perciò se siete di fretta o avete poco tempo a disposizione.

Infine, vi segnalo come sia importante l’installazione della beta 2 dei tools, perchè è quella che vi permetterà di fare il deploy sui device aggiornati con la beta di Mango.

Un concorso per gli studenti

Microsoft ha inoltre dato il via ad un interessante concorso per tutti gli studenti iscritti al programma DreamSpark: utilizzando il template per Sketch Flow rilasciato da poco siete invitati a realizzare il mock up di un’applicazione per Mango e a pubblicarlo. I migliori riceveranno un HTC Mazaa, uno dei prototipi commissionati da Microsoft dotati di Mango e di tutte le feature hardware previste dalle nuove specifiche (come il giroscopio) per testare le vostre applicazioni.

Maggiori dettagli li trovate sul post ufficiale del team di Windows Phone o su quello di MSDN Italia.

This entry was posted on Thursday, 30 June, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

Giovedì 23 Giugno si è tenuto, in sede Microsoft, il primo evento italiano dedicato completamente allo sviluppo di applicazioni per Windows Phone Mango, organizzato da DotNetLombardia. Nel corso della giornata io e gli altri speaker abbiamo realizzato l’applicazione ufficiale della community partendo praticamente da zero: ci siamo focalizzati sulla sezione dedicata agli eventi e, perciò, man mano abbiamo costruito il modello di dati (che recuperava le informazioni da un servizio WCF Data Service realizzato ad hoc), l’interfaccia fino ad arrivare a tutta una serie di feature specifiche per illustrare le novità di Mango (come la possibilità di pinnare in home gli eventi, di mantenere aggiornata la tile con il countdown all’evento tramite un background agent, la votazione delle sessioni realizzata usando dei tag e le nuove API per l’accesso alla fotocamera, ecc.).

Personalmente, sono rimasto molto soddisfatto dell’evento: il feedback che ho ricevuto, sia durante la giornata che nei giorni successivi tramite mail, è stato molto positivo e credo che l’obiettivo sia stato centrato. Ovviamente, si tratta di impressioni personali: invito perciò tutti quelli che hanno partecipato all’evento a compilare il form di feedback, il cui link vi sarà arrivato via mail nei giorni scorsi. Solo così potremo realmente capire cosa è andato bene, cosa no e cosa migliorare in previsione dei prossimi eventi!

Ho pubblicato su SlideShare le slide delle mie tre sessioni: il keynote sulle novità di Mango, Introduzione a MVVM con MVVM Light e Multitasking, background agents e local notifications. Per quanto riguarda il codice vero e proprio, stiamo raccogliendo tutto il materiale prodotto dai vari speaker così da mettere a disposizione il codice sorgente completo dell’applicazione. Appena sarà disponibile, non mancherò di segnalarvelo!

Prima di lasciarvi alle slide, colgo l’occasione per ringraziare Roberto, Alessandro, Sandro e Dan per l’eccezionale contributo dato alla giornata con i loro interventi!

This entry was posted on Monday, 27 June, 2011 and is filed under Windows Phone Events , Devs . You can follow any responses to this entry through here . You can leave a response.

Recentemente mi capita spesso di ricevere mail di sviluppatori che mi chiedono consigli su guide e tutorial per iniziare a sviluppare applicazioni Windows Phone. Neanche a farlo apposta, qualche giorno fa ho ricevuto dagli amici di ASPItalia una copia del loro libro fresco di stampa dedicato proprio allo sviluppo di applicazioni per WP7.

La prima nota importante da sottolineare è che il libro è stato scritto da professionisti che non si sono occupati di Windows Phone solo in maniera teorica, ma che hanno lavorato e collaborato su alcune delle applicazioni più importanti disponibili sul Marketplace. Il libro è perciò frutto non solo di studio e passione, ma anche di tanta esperienza sul campo.

La seconda nota è che il libro è ovviamente basato su NoDo, la versione corrente di Windows Phone: al momento della stesura del libro Mango non era ancora uscito e, ancora oggi, siamo ancora in fase beta, quindi molte cose possono ancora cambiare. Questo non sminuisce però l’utilità del libro: Mango infatti aggiunge tantissime nuove API e funzionalità, ma le basi rimangono sempre le stesse, anzi, direi che sono fondamentali per poter capire a fondo le novità introdotte.

Il libro affronta tutti gli argomenti importanti legati allo sviluppo e alla distribuzione ed è adatto anche a chi è alle prime armi su Silverlight: nei primi capitoli infatti vengono gettate le basi necessarie per affrontare gli argomenti successivi. Ovviamente, è necessaria una comprensione minima di C# o VB.NET: assieme al libro vengono resi disponibili tutti gli esempi di codice in entrambi i linguaggi.

Il libro è strutturato in 5 parti:

• Introduzione a Windows Phone: Windows Phone non è solo un OS in grado di “ospitare” le nostre applicazione, ma è anche e soprattutto un ecosistema complesso, con le sue regole e linee guida. Questa sezione fa proprio da introduzione a questo ecosistema, con un occhio di riguardo a Metro, il nome in codice della UI di Windows Phone.
• Sviluppo di applicazioni con Silverlight: in questa sezione del libro si approfondiscono le tematiche di sviluppo di applicazioni “tradizionali” utilizzando Silverlight. Si affrontano argomenti come l’uso dei vari controlli, il tombstoning, la personalizzazione, ecc.
• XNA – Sviluppo di giochi: lo sviluppo su Windows Phone però non è solo Silverlight, ma anche XNA, il framework specifico per lo sviluppo di giochi. In questa sezione viene fatta un’introduzione ai concetti base di XNA, all’utilizzo di grafica 3D e all’integrazione di audio e animazioni.
• Le caratteristiche innovative: Windows Phone, rispetto ad altri OS concorrenti, offre una serie di innovazioni, come le live tile o l’integrazione con le applicazioni native. In questa sezione si parlerà di come uno sviluppatore può implementare tutte queste feature nelle sue applicazioni.
• Distribuzione e marketplace: “non di solo codice vive lo sviluppatore”. Ecco perciò che, una volta terminato lo sviluppo, arriva il momento di pubblicare l’applicazione sul Marketplace. Questa sezione vi farà da guida all’intero processo.

Infine, il libro termina con una serie di appendici dedicati ad argomenti correlati, come l’utilizzo del pattern MVVM o la disponibilità di librerie e tool di terze parti che possono semplificare il nostro lavoro.

Il libro è disponibile nelle migliori librerie o online al costo di 24,90 ed è pubblicato da Hoepli Informatica: trovate tutte le informazioni e i link per l’acquisto sulla pagina ufficiale.

Ottimo lavoro ragazzi!

This entry was posted on Thursday, 23 June, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

Ricordate Chevron WP7, l’applicazione non ufficiale che era stata rilasciata per permettere lo sblocco dei device senza avere un account sul Marketplace? L’applicazione funzionava, ma come tutte le soluzioni non ufficiali aveva dei problemi: in caso di malfunzionamenti, non c’era nessuno disposto a rispondere della cosa; ad ogni aggiornamento del sistema operativo si rischiava un nuovo blocco e la conseguente attesa di una nuova versione dell’applicazione; ecc.

Microsoft però aveva annunciato di voler collaborare con il team di Chevron, al fine di migliorare la piattaforma e di ascoltare i feedback degli utenti: il risultato di questa collaborazione è ora finalmente pubblico! Tramite il blog ufficiale, il team di Chevron ha infatti annunciato che a breve rilasceranno un tool ufficialmente supportato da Microsoft per l’unlocking, che darà la possibilità a tutti gli sviluppatori di caricare le proprie applicazioni sul device senza acquistare un account per il Marketplace. Ovviamente, l’account sarà comunque richiesto per la pubblicazione: se però siamo sviluppatori alle prime ami su questa piattaforma e vogliamo fare qualche esperimento prima di decidere se pubblicare o meno delle applicazioni, ora possiamo farlo ad un costo decisamente inferiore rispetto ai 99 $ richiesti per l’iscrizione all’App Hub.

Si, perchè il tool di sblocco sarà a pagamento: non si sa ancora la cifra esatta, ma il sito ufficiale la definisce una “small fee”, quindi non credo che dobbiate rompere il vostro salvadanaio per acquistarlo

Le reazioni degli sviluppatori a questa notizia sono state per lo più entusiaste, anche se con qualche riserva: dal punto di vista dell’immagine, infatti, diverse persone hanno definito la soluzione bizzarra, dato che sarebbe stato meglio proporre una soluzione ufficiale piuttosto che “ufficiosa”.

Personalmente, invece, pur condividendo anche io qualche dubbio, la trovo tutto sommato una soluzione vincente, proprio a livello di immagine e di capacità di Microsoft di ascoltare i feedback: in un mondo dove società come Apple si battono continuamente per bloccare il jailbreak (inutilmente, la prima beta di iOS 5 è stata sbloccata dopo meno di un giorno), è bello vedere come Microsoft abbia deciso di intraprendere una strada completamente opposta, collaborando con un team di programmatori appassionati e ascoltando i tanti sviluppatori che volevano provare le loro applicazioni sui device senza spendere 99 $ per un account sul Marketplace.

Non mancherò di tenervi aggiornati quando si avranno maggiori informazioni sul rilascio ufficiale.

This entry was posted on Monday, 20 June, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

Nel post precedente abbiamo visto la teoria necessaria per capire cosa sono e come funzionano i background agents. Ora è giunto il momento di passare alla pratica e realizzare un’applicazione che faccia uso di un agent.

Come prima cosa, dobbiamo creare due progetti di Visual Studio: se ricordate quanto detto nel post precedente, un background agent è una DLL separata dall’applicazione vera e propria. Creiamo perciò una nuova soluzione in Visual Studio e aggiungiamo due progetti: uno di tipo Windows Phone Application e l’altro di tipo Windows Task Scheduler Agent.

L’applicazione Windows Phone

Nell’applicazione Windows Phone andremo a creare il background agent e ad aggiungerlo allo scheduler di Windows Phone. Nel post precedente abbiamo visto come esistano due tipi di agents: entrambi si istanziano allo stesso modo ed espongono le stesse proprietà, l’unica differenza è il tipo di oggetto che andremo ad utilizzare.

Vediamo un esempio:

ScheduledAction action = ScheduledActionService.Find("TestAgent");
if (action != null)
    ScheduledActionService.Remove("TestAgent");

PeriodicTask task = new PeriodicTask("TestAgent")
                        {
                            Description = "Test task",
                            ExpirationTime = DateTime.Now.AddDays(7)
                        };

ScheduledActionService.Add(task);

Tutti i background task introdotti in Mango derivano da una classe base chiamata ScheduleAction, che rappresenta per l’appunto un generico servizio capace di girare in background. ScheduledActionService rappresenta invece lo scheduler di Windows Phone (lo abbiamo già visto quando abbiamo parlato di reminders e alarms), che si occupa di gestire tutti i task in background che sono stati introdotti in Mango. Ecco perciò che come prima cosa andiamo a controllare se nello scheduler è già presente un servizio con lo stesso nome e, in caso affermativo, lo rimuoviamo: se infatti cercassimo di aggiungere un task duplicato allo scheduler, otterremmo un’eccezione.

Dopodichè definiamo il nostro background agent: nell’esempio, si tratta di un periodic agent (che fa riferimento alla classe PeriodicTask). Se si fosse trattato di un resource intensive agent il codice sarebbe stato lo stesso, con la differenza che l’oggetto istanziato sarebbe stato di tipo ResourceIntensiveTask. Il task viene istanziato con un nome, una descrizione e una data di scadenza, passata la quale viene automaticamente eliminato da quelli schedulati.

Infne aggiungiamo il task nella coda dello scheduler, sfruttando il metodo Add esposto dal servizio ScheduledActionService.

Ci siamo: il nostro task è stato definito e ora Windows Phone lo prenderà in carico secondo le regole che abbiamo visto nel post precedente e in base al tipo di agent che abbiamo definito. Ora dobbiamo definire però che cosa farà effettivamente il nostro background agent.

Il background agent

Il progetto di tipo Windows Background Scheduler Agent che abbiamo creato all’inizio avrà già una classe definita al suo interno, di nome TaskScheduler, che possiamo rinominare a nostro piacimento. Questa classe rappresenta il nostro agent ed ha tre caratteristiche fondamentali:

• Eredita dalla classe ScheduledTaskAgent
• Implementa il metodo OnInvoke, che contiene il codice che viene eseguito quando il background agent viene lanciato.
• Implementa il metodo opzionale OnCancel, che viene invocato nel momento in cui il tempo assegnato al nostro agent sta per scadere. Nel caso in cui le operazioni definite nel metodo OnInvoke non siano ancora concluse, possiamo usare questo metodo per gestire eventuali operazioni che vogliamo eseguire prima che questi venga definitivamente terminato.

Il cuore è il metodo OnInvoke, in cui possiamo inserire il codice che vogliamo, l’importante è che rispetti le condizioni spiegate nel post precedente a cui devono sottostare gli agents (ad esempio, nessuna interazione con la UI o utilizzo di librerie di XNA). Vediamo un semplice esempio in cui usiamo un background agent per mostrare una notifica di tipo toast:

public override void OnInvoke(ScheduledTask task)
{
    ShellToast toast = new ShellToast
                           {
                               Title = "Toast",
                               Content = "Test"
                           };
    toast.Show();
    NotifyComplete();
}

Il codice è semplice: creiamo una notifica di tipo toast, gli diamo un titolo e un testo fittizi e la mostriamo (torneremo in un prossimo post sulle notifiche push locali). L’unica cosa da notare è la chiamata al metodo NotifyComplete, che deve essere richiamato nel momento in cui il background agent ha terminato il suo compito. In questo modo, lo scheduler di Windows Phone è in grado di liberare le risorse utilizzate dall’agent il prima possibile.

Come collegare l’agent all’applicazione

Nell’applicazione abbiamo aggiunto un nuovo task allo scheduler, mentre nel background agent abbiamo definito le operazioni da eseguire. Come facciamo a collegare i due, per far si che l’applicazione sappia qual è il task che vogliamo utilizzare? Il tutto viene definito nel file di manifest, che già abbiamo visto in passato in quanto definisce tutte le funzionalità del device che vengono utilizzate dalla nostra applicazione (accesso ai sensori, utilizzo della rete, ecc.).

Ecco la sezione del manifest della nostra applicazione dove viene dichiarato il background agent:

<Tasks>
  <ExtendedTask Name="BackgroundTask">
    <BackgroundServiceAgent Specifier="ScheduledTaskAgent" Name="TestAgent" Source="TestAgent" Type="TestAgent.TaskScheduler" />
  </ExtendedTask>
</Tasks>

L’agent è identificato da:

• Name: il nome dell’agent
• Source: il nome della DLL che contiene l’agent (tipicamente coincide con il nome del progetto)
• Type: il namespace completo (compreso del nome della classe) dell’agent all’interno della DLL

In realtà, aggiungere le informazioni sull’agent nel manifest è estremamente semplice, dato che ci penserà Visual Studio a fare tutto: quello che dovrete fare voi sarà semplicemente aggiungere una reference all’agent all’interno della vostra applicazione (tasto destro sul progetto, selezionate Add Reference e selezionate il progetto contenente l’agent che sarà disponibile nella sezione Projects).

Come effettuare il debug?

In Visual Studio esiste una toolbar che vi permette di vedere i processi in esecuzione, che assume una certa importanza nella nuova versione dei tool. Ora infatti sono due le tipologie di processi che Visual Studio si troverà a gestire: UI Task (l’applicazione vera e propria) e background task (il background agent). Quando lancerete il debugger di Visual Studio, se la vostra applicazione prevede un agent verranno deployati entrambi. Nel momento in cui uscirete dall’applicazione, noterete che il debugger non si staccherà; verrà infatti eseguito l’agent e, se avete messo un breakpoint all’interno del metodo OnInvoke, potrete fare debug step by step del vostro codice.

In conclusione

Abbiamo visto una panoramica (spero esauriente) sui background agent: prossimamente parlerò anche di un tipo particolare di background agent, quello dedicato alla gestione dell’audio in background. Nel frattempo, potete fare esperimenti con il progetto di esempio che trovate in allegato. Buon download!

This entry was posted on Friday, 17 June, 2011 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.

Oggi su WinPhoneItalia.com, sito completamente dedicato a Windows Phone facente parte del celebre network italiano ASPItalia, è stato pubblicato un mio articolo di approfondimento sulle novità introdotte in Windows Phone Mango per gli sviluppatori. Vista la mole di nuove feature, l’articolo non vuole essere completamente esaustivo su ogni singolo aspetto: può essere però un buon punto di partenza per farsi un’idea più precisa delle novità e per vedere anche qualche piccolo esempio di codice.

Lo trovate all’indirizzo http://www.winphoneitalia.com/articoli/windows-phone-7/mango-novita-windows-phone-7.1.aspx: occhio che per leggere le pagine successive alla prima dovete essere registrati (in modo completamente gratuito) sul network di ASPItalia.

Buona lettura!

This entry was posted on Wednesday, 15 June, 2011 and is filed under Windows Phone Devs . You can follow any responses to this entry through here . You can leave a response.

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.

This entry was posted on Tuesday, 14 June, 2011 and is filed under Windows Phone Tutorials . You can follow any responses to this entry through here . You can leave a response.