Isolated Storage Explorer: esplorare lo storage della vostra applicazione

Print Content | More

Tra le novità introdotte nella beta 2 c’è anche il tanto atteso Isolated Storage Explorer, uno dei tool annunciati al MIX assieme al nuovo emulatore (con il supporto per il testing dell’accelerometro e della geolocalizzazione).

Questa applicazione ci da la possibilità di esplorare lo storage delle nostre applicazioni, sia che siano installate sull’emulatore che su un device fisico. Occhio però che si tratta di un tool a riga di comando: se volete qualcosa di visuale, esiste un progetto su Codeplex, molto più intuitivo da usare ma che ha alcuni svantaggi (richiede l’utilizzo di una libreria apposita da includere nella nostra app ed, essendo ancora in beta, a volte da qualche problema). Vedremo più avanti qualche informazione in più.

Il tool viene installato nel seguente percorso:

C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\IsolatedStorageExplorerTool

Se avete un sistema operativo a 32 bit, il percorso sarà invece il seguente:

C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\IsolatedStorageExplorerTool

Essendo un tool a linea di comando, dovete usarlo da prompt dei comandi: dal menu Start digitate il comando cmd e, una volta aperto il prompt, digitate cd seguito da uno dei due percorsi riportati sopra, a seconda della versione del vostro sistema operativo (32 o 64 bit).

La sintassi

Il nome dell’eseguibile è ISETool.exe e i parametri accettati, nell’ordine, sono i seguenti:

  1. l’operazione che si vuole eseguire (vedremo dopo in dettaglio i comandi supportati)
  2. il target su cui vogliamo eseguire l’operazione (xd per l’emulatore, sd per il device)
  3. il product guid che identifica la nostra applicazione e che possiamo recuperare dal file di manifest (WMAppManifest.xml), nell’attributo del nodo App chiamato ProductId.
  4. Il percorso di destinazione (nel caso si tratti di un’operazione di download o upload).

SNAGHTMLacd0102

Vediamo ora in dettaglio le operazioni che possiamo eseguire con questo tool.

Elencare il contenuto dell’Isolated Storage

Il comando per visualizzare i file e le cartelle contenute nell’isolated storage è dir, seguito dal percorso che si vuole visualizzare. Ecco un esempio:

ISETool.exe dir:\Shared\Transfers xd 353cfc89-ebc8-4084-93a4-8a8badd30f67

Questo comando mostra tutti i file presenti nella cartella \Shared\Transfers della nostra applicazione installata sull’emulatore.

Scaricare i file contenuti nell’Isolated Storage

Il comando per trasferire sul disco fisso uno snapshot del contenuto dell’Isolated Storage è ts. Ecco un esempio:

ISETool.exe ts xd 353cfc89-ebc8-4084-93a4-8a8badd30f67 c:\temp

Questo comando trasferisce tutto il contenuto dell’Isolated Storage della nostra applicazione installata sull’emulatore nella cartella c:\temp. All’interno di questa cartella, verrà creata una sottocartella chiamata IsolatedStore con il dump dell’intero storage.

Caricare dei file nell’Isolated Storage

E’ possibile ripristinare un’intero snapshot nell’Isolated Storage della nostra applicazione, nel caso abbiamo la necessità di fare alcuni test modificando manualmente alcuni file. Il comando è rs ed ecco un esempio di utilizzo:

ISETool.exe rs xd 353cfc89-ebc8-4084-93a4-8a8badd30f67 c:\temp\IsolatedStore

Questo comando trasferisce tutto il contenuto della cartella c:\temp\IsolatedStore nello storage della vostra applicazione. Attenzione che si tratta del restore di uno snapshot: il contenuto nello storage verrà sovrascritto da quello contenuto nella cartella sul vostro disco fisso.

L’utilizzo più corretto è perciò quello di scaricare il contenuto sul vostro disco fisso con il comando ts, modificare o aggiungere i file che vi servono e dopodichè effettuare un restore della stessa cartella con il comando rs.

SNAGHTMLaca414c

Il tool visuale

Come vi anticipavo all’inizio del post, esiste un tool su Codeplex che porta lo stesso nome e che ha il vantaggio di essere visuale e quindi offre un’esperienza d’uso più semplice. Possiamo scaricarlo dalla pagina ufficiale http://wp7explorer.codeplex.com/. Abbiamo due modi per utilizzare il tool:

  • Avviando l’applicazione stand alone, la cui icona verrà automaticamente posizionata sul desktop.
  • Utilizzando il plugin integrato in Visual Studio, richiamabile dal percorso View –> Other windows –> WP7 Isolated Storage Explorer.

In entrambi i casi, quella che vedremo all’avvio sarà il messaggio There are no applications connected: questo perchè, per poter collegare la nostra applicazione al tool, è necessario aggiungere un’apposita libreria e lanciare il servizio all’avvio. Facciamo perciò clic con il tasto destro sul nostro progetto in Visual Studio, scegliamo la voce Add References e andiamo a selezionare il file IsolatedStorageExplorer.dll posizionato nella cartella C:\Program Files (x86)\WP7 Isolated Storage Explorer\Library

Ora posizioniamoci nel file App.xaml.cs e, nell’evento Application_Launching, inseriamo il seguente codice:

private void Application_Launching(object sender, LaunchingEventArgs e)
{
    IsolatedStorageExplorer.Explorer.Start("localhost");
}

A questo punto, nel momento in cui lanceremo la nostra applicazione, il tool si aggiornerà, mostrando i file contenuti. Avremo la possibilità sia di scaricare file (tramite il menu contestuale con il tasto destro), sia di creare nuove cartelle o di caricare file presenti sul nostro disco (sempre facendo clic con il tasto destro su una cartella o sulla root).

SNAGHTMLac53bdf


Windows Phone , Microsoft , Mango

1 comments

Certificazioni, aperitivi, articoli e App Hub

Print Content | More

Post breve ma ricco di contenuti per segnalarvi alcune novità interessanti.

MCP su Windows Phone

E’ con soddisfazione che vi comunico di aver superato l’esame beta 71-599 “Designing and developing Windows Phone applications”. Sono ufficialmente MCP su Windows Phone ora Smile

Un paio di informazioni su chi fosse interessato a percorrere un percorso di certificazione su Windows Phone: Microsoft ha recentemente inaugurato l’MCPD (Microsoft Certified Professional Developer) su Windows Phone, che richiede il superamento dei seguenti esami:

  • 70-599: Designing and developing Windows Phone applications
  • 70-506: Silverlight 4 Development
  • 70-516: Accessing data with Microsoft .NET Framework 4

Ai link trovate tutto il materiale necessario per scoprire gli argomenti dell’esame e il materiale per prepararvi. Dopodichè il passo successivo è andare sul sito Prometric, registrarvi e prenotare l’esame presso la sede più vicina a voi.

Aperitivo di DotNetLombardia

Giovedì 21 Luglio abbiamo organizzato un aperitivo per festeggiare il primo compleanno di DotNetLombardia. Sarà un evento informale: niente sessioni o workshop, ma semplicemente un modo per ritrovarsi a fare due chiacchiere e pianificare le attività da organizzare per il nuovo anno 2011-2012 (e si partirà subito con il botto, dato che il 13 Settembre ci sarà BUILD e Microsoft sta organizzando proprio in collaborazione con le community degli eventi locali in parallelo).

Siete tutti invitati, soprattutto se vi piacerebbe entrare a far parte di una community in maniera attiva, scrivendo articoli, inaugurando un blog o contribuendo ai nostri eventi con delle sessioni. Sarà l’occasione giusta per conoscerci!

L’aperitivo si terrà nel locale Sugar Lounge, in via Alserio 9 a Milano. Per l’iscrizione e la partecipazione, fate riferimento alla pagina Facebook.

Integrare le proprie applicazioni Mango con l’hub Pictures

Sul blog di MSDN Italia è stato pubblicato un mio articolo su come integrare un’applicazione per Mango all’interno dell’hub Pictures. Ecco il link: http://blogs.msdn.com/b/italy/archive/2011/07/15/guest-post-integrare-la-nostra-applicazione-all-interno-dell-hub-delle-foto-con-windows-phone-mango.aspx

Buona lettura!

Restyling dell’App Hub

Dopo una notte di downtime per aggiornamenti, è stato inaugurato questa mattina la nuova versione dell’App Hub, sia in termini di layout che in termini di contenuti.

Alcune delle novità più importanti sono:

  • Disponibilità dei crash report
  • Possibilità di esportare i report di download e vendita
  • Inaugurazione del marketplace privato
  • Possibilità di modificare i dettagli della nostra applicazione (artwork, descrizione, ecc) in qualsiasi momento, senza essere costretti a fare il submit di un update

Per vederlo con i vostri occhi vi basta collegarvi su http://create.msdn.com usando il vostro account sul Marketplace: ne parleremo sicuramente in un post più approfondito per dettagliare meglio le novità.

image


Windows Phone , Microsoft , App Hub , DotNetLombardia , MCP

6 comments

Il ciclo di vita dei background agents: un esempio concreto

Print Content | More

Nel post precedente abbiamo visto come è strutturato il ciclo di vita di un background agent, soprattutto alla luce delle novità introdotte nella beta 2 dei tools per Mango. Ci eravamo lasciato affrontando nuovi concetti quali il metodo LaunchAndTest e le proprietà IsEnabled e IsScheduled esposte dalle classi PeriodicTask e ResourceIntensiveTask. Ora vediamo di mettere insieme tutti questi concetti per realizzare un’applicazione reale.

Passiamo ai fatti: l’applicazione

L’applicazione che andremo a realizzare è molto semplice, ma è molto utile per mettere alla prova i concetti che abbiamo imparato. La base sarà la stessa che abbiamo usato nella serie di tutorial precedenti sui background agent: un’applicazione collegata ad un agent in grado di mostrare notifiche toast di tipo locale. La differenza è che questa volta daremo all’utente la possibilità, tramite un form, di impostare titolo e contenuto della notifica. Egli sarà però in grado di pianificare comunque l’agent, anche senza impostare questi valori: in tal caso, però, ne interromperemo la schedulazione chiamando il metodo Abort, dato che non sussistono le condizioni perchè questo continui ad essere eseguito.

La UI della nostra applicazione è molto semplice: un form con due etichette e i due relativi TextBox (per inserire titolo e contenuto della notifica) e un pulsante, che useremo per schedulare l’agent.

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
    <StackPanel>
        <TextBlock Text="Title" Style="{StaticResource PhoneTextGroupHeaderStyle}" />
        <TextBox x:Name="txtTitle" />
        <TextBlock Text="Subtitle" Style="{StaticResource PhoneTextGroupHeaderStyle}" />
        <TextBox x:Name="txtSubtitle" />
        <Button Click="btnCreateAgent_Click" Content="Create agent" />
    </StackPanel>
</Grid>

Vediamo il codice che viene eseguito nel momento in cui viene premuto il pulsante Create agent.

private void btnCreateAgent_Click(object sender, System.Windows.RoutedEventArgs e)
 {
 if (!string.IsNullOrEmpty(txtTitle.Text))
 {
     IsolatedStorageSettings.ApplicationSettings.Add("Title", txtTitle.Text);
     IsolatedStorageSettings.ApplicationSettings.Add("Subtitle", txtSubtitle.Text);
 }

 bool isEnabled = true;

 PeriodicTask action = ScheduledActionService.Find("TestAgent") as PeriodicTask;
 if (action == null || (!action.IsScheduled))
 {
     if (action != null)
         ScheduledActionService.Remove(action.Name);
     
     PeriodicTask task = new PeriodicTask("TestAgent")
     {
         Description = "Test task",
         ExpirationTime = DateTime.Now.AddDays(7)
     };

     try
     {
         ScheduledActionService.Add(task);
     }
     catch (InvalidOperationException exc)
     {
         if (exc.Message.Contains("BNS Error: The action is disabled")) 
             MessageBox.Show("The agent has been disabled. Go to Settings to enable it.");
         isEnabled = false;
     }
 }

 #if DEBUG
 if (isEnabled)
     ScheduledActionService.LaunchForTest("TestAgent", new TimeSpan(0, 0, 10));
 #endif
 }
}

Innanzitutto, andiamo a salvare nell’Isolated Storage i valori inseriti nelle due caselle di testo, in modo che il background agent possa recuperare questa informazione. Dopodiché, sfruttando il metodo Find dello ScheduledActionService, andiamo a recuperare il nostro task (identificato dal nome TestAgent), e lo convertiamo in un PeriodicTask.

Dopodichè controlliamo lo stato del task: se questo è a null oppure non è schedulato (IsScheduled = false) allora lo riprogrammiamo. Quando ci possiamo trovare in questa condizione?

  • Quando l’agent non è mai stato programmato (tipicamente alla prima esecuzione, quindi l’oggetto recuperato dallo ScheduledActionService è a null).
  • Quando l’agent è scaduto.
  • Quando l’agent è stato interrotto perchè abbiamo chiamato il metodo Abort.

Ovviamente, in un caso reale se la proprietà LastExitReason dell’agent fosse su Aborted, dovremmo assicurarci che le condizioni che abbiamo identificato come non più idonee per l’esecuzione dell’agent siano state risolte. Nel nostro esempio, potremmo assicurarci ad esempio che l’agent venga rischedulato solo nel caso in cui le proprietà Title e Content siano state valorizzate. In questo caso non lo abbiamo fatto per dare la possibilità di testare il metodo Abort, che vedremo tra pochissimo.

Come spiegato nel post precedente, abbiamo incluso il metodo ScheduledActionService.Add dentro un blocco try / catch: questo perchè l’utente potrebbe aver richiesto la disabilitazione permanente dell’agent, perciò questa operazione potrebbe scatenare un’eccezione di tipo InvalidOperationException. Quello che facciamo è andare a mostrare un messaggio all’utente, avvisandolo che il background agent è stato disabilitato e che, se vuole riabilitarlo, può farlo dall’hub Settings. Lo facciamo però solo se il messaggio dell’eccezione è BNS Error: The action is disabled; questo perchè l’eccezione di tipo InvalidOperationException si possono verificare anche in altri casi (ad esempio, è stato raggiunto il massimo numero di background agent installabili nel device).

Il background agent

Come anticipato all’inizio, il background agent si limiterà a mostrare una notifica di tipo toast. La novità rispetto al progetto di esempio di qualche settimana fa, però, è che questa volta andremo a chiamare il metodo Abort nel caso in cui l’utente non abbia valorizzato le proprietà Title e Content.

protected override void OnInvoke(ScheduledTask task)
{
    if (IsolatedStorageSettings.ApplicationSettings.Contains("Title"))
    {
        ShellToast toast = new ShellToast
                               {
                                   Title = IsolatedStorageSettings.ApplicationSettings["Title"].ToString(),
                                   Content = IsolatedStorageSettings.ApplicationSettings["Subtitle"].ToString()
                               };
        toast.Show();

        #if DEBUG
            ScheduledActionService.LaunchForTest(task.Name, new TimeSpan(0, 1, 0));
        #endif
        NotifyComplete();
    }
    else
        Abort();
}   

Se nell’IsolatedStorage abbiamo salvato una chiave chiamata Title, allora eseguiamo il background agent in maniera tradizionale: mostriamo la notifica e chiamiamo il metodo NotifyComplete al termine. Notiamo inoltre che, se siamo in debug, ripianifichiamo una nuova esecuzione dell’agent stesso dopo 1 minuto.

Se invece tale chiave non esiste, allora chiamiamo il metodo Abort.

Facciamo un po’ di test

Rifacendoci ai vari scenari presentati nel post precedente, andiamo a vedere il comportamento del nostro agent nelle varie condizioni. Come prima cosa, impostiamo due breakpoint: uno nell’applicazione, nel momento in cui viene premuto il pulsante, e uno nell’agent, nel momento in cui viene eseguito il metodo OnInvoke.

L’esecuzione va a buon fine

Lanciamo l’applicazione, inseriamo dei valori nei campi Title e Content e premiamo il pulsante Create agent: essendo la prima esecuzione, il metodo ScheduledActionService.Find restituirà null perciò l’agent verrà pianificato normalmente. Ora usciamo dall’applicazione e, nel giro di 10 secondi (l’intervallo di tempo passato come parametro del metodo LaunchAndTest), verrà eseguito il background agent. Dato che nell’Isolated Storage vengono trovate le informazioni inserite dall’utente nel form, la notifica toast verrà visualizzata a video e verrà chiamato il metodo NotifyComplete. Infine, un minuto dopo circa il background agent entrerà di nuovo in azione, dato che prima di terminarlo abbiamo riutilizzato il metodo LaunchAndTest.

Se ora riapriamo l’applicazione e ripremiamo il pulsante, potremo notare che la creazione e pianificazione del task verrà saltata: questo perchè la proprietà IsScheduled sarà ancora a true, dato che l’agent non è scaduto e l’ultima esecuzione è andata a buon fine.

Il task viene terminato

Ora disinstalliamo l’applicazione e ripremiamo F5 in Visual Studio: questa volta premiamo il pulsante Create agent senza inserire nulla nel form. Al primo avvio il comportamento sarà lo stesso di prima: il task, non esistendo, verrà creato e pianificato. L’unica differenza è che nell’Isolated Storage non avremo salvato niente: il risultata sarà che, dopo 10 secondi, il background agent verrà eseguito ma, facendo debug step by step grazie al breakpoint che abbiamo inserito, potremo verificare come l’esecuzione passi direttamente al metodo Abort.

Ora, se riapriamo l’applicazione e mettiamo un quick watch sull’oggetto action di tipo PeriodicTask, potremo verificare come la proprietà IsEnabled sia ancora a true, ma la proprietà IsScheduled sia questa volta a false. In più, se guardiamo il valore della proprietà LastExitReason avremo la conferma che tutto è andato come ci aspettavamo. Se continuiamo con il debug step by step ci aspettiamo che il background agent venga nuovamente rischedulato: questo perchè è stato semplicemente “sospeso” in attesa che si ricreassero le condizioni necessarie per l’esecuzione.

L’agent viene annullato dall’utente

Senza disinstallare questa volta l’applicazione, andiamo sull’emulatore, entriamo nell’hub Settings e, alla voce Applications, selezioniamo Background Tasks. Troveremo la nostra applicazione, il cui stato sarà su On. Facciamo tap e premiamo il pulsante Turn off. Ora ripetiamo il giro di prima: premiamo F5 in Visual Studio, lanciamo l’applicazione e premiamo il pulsante Create agent. Questa volta otterremo un comportamento ancora diverso: la proprietà IsEnabled sarà a false, ciò significa che l’utente ha esplicitamente richiesto la sospensione dell’agent. Per questo motivo, quando andremo a chiamare il metodo ScheduledActionService.Add si scatenerà un’eccezione: entreremo perciò nel blocco catch e verrà mostrato a video il messaggio.

Adesso ripetiamo quest’ultimo test: prima però torniamo nella sezione Settings, facciamo tap sulla nostra applicazione e abilitiamo il checkbox Turn background tasks back for this time the next time I open it. Ora rilanciamo l’applicazione da Visual Studio: questa volta il metodo ScheduledActionService.Add non farà scattare alcuna eccezione e il task verrà schedulato normalmente.

In conclusione

Come vedete, l’argomento dei background agent si è dimostrato molto articolato e complesso. In realtà, i concetti base da capire e tenere a mente sono semplici: sono tante però le situazioni e i casi da gestire. Spero che questa serie di articoli vi sia stato d’aiuto per chiarivi le idee! Di seguito trovate il link per scaricare il progetto di esempio con cui abbiamo lavorato in questo post.


Windows Phone , Mango , Microsoft , Background agents

1 comments

L’evento su Mango di Microsoft Italia è online!

Print Content | More

Brevissimo post per segnalarvi che l’evento online organizzato da Microsoft Italia di cui vi ho parlato settimana scorsa è ora disponibile: al sito http://www.microsoft.com/italy/windowsphone/evento/ potrete guardare in streaming il keynote introduttivo (a cura di Gabriele Castellani) e una serie di sessioni di approfondimento:

  • Introduzione allo sviluppo per Windows Phone di Cristian Civera (Microsoft MVP), dove ci vengono spiegate le basi dello sviluppo per Windows Phone: come districarsi tra Visual Studio, emulatore, debugging, ecc.
  • Il design delle applicazioni Windows Phone di Roberto Cavallini (User Experience Evangelist), dove ci vengono trasmessi i concetti base nonchè preziosi consigli riguardanti il design delle nostre applicazioni.
  • Le novità della piattaforma di sviluppo in Windows Phone "Mango" di Lorenzo Barbieri (Developer Evangelist), che ci presenta una panoramica di tutte le nuove API e funzionalità messe a disposizione degli sviluppatori in Mango.
  • Multitasking nelle applicazioni Windows Phone "Mango" del sottoscritto, in cui vi presento una panoramica di tutto ciò che riguarda il multitasking in Mango: Fast App Switching, background agents, background transfers, background audio, alarms & reminders.
  • Live Tile e notifiche in Windows Phone "Mango" di Michele Locuratolo (Microsoft MVP), nella quale scoprirete le novità di mango per quanto riguarda le notifiche push e le live tile (come il supporto alle notifiche locali e alle tile multiple).
  • Phone + Cloud in pochi clic con Azure Toolkit per Windows Phone 7 di Roberto Freato (Microsoft MVP) nella quale impareremo ad usare l’Azure Toolkit, una libreria rilasciata da poco su Codeplex che ci facilita l’integrazione con Azure nella nostra applicazione.

Per quanto riguarda la mia sessione, se dopo averla vista avete dei dubbi, volete dei chiarimenti o volete approfondire l’argomento, non esitate a contattarmi tramite l’apposito form di contatto!


Windows Phone , Microsoft , Mango

0 comments

Ancora sui background agents: il ciclo di vita

Print Content | More

Come ho anticipato in un post di qualche giorno fa, nella beta 2 sono stati introdotti diversi cambiamenti importanti riguardo al ciclo di vita dei background agents, i servizi che possono essere associati alla nostra applicazione ed eseguire operazioni anche quando questa non è in esecuzione.

In questo post esamineremo perciò tutte le novità e impareremo come gestire tutti i casi particolari che si possono verificare durante l’esecuzione.

LaunchForTest: un nuovo metodo per eseguire i background agent

Già nel post precedente avevo anticipato come la beta 2 avesse introdotto un nuovo metodo per lanciare i background agent, esposto dallo ScheduledActionService e chiamato LaunchForTest. Il vantaggio di questo nuovo metodo è duplice:

  • Da una parte, il meccanismo di testing e debugging dei background agent nella beta 1 era un po’ macchinoso e a volte capitava che l’agent non venisse eseguito.
  • Dall’altra, i background agents hanno un tetto massimo di 5 MB di memoria che possono occupare. Se testiamo un background agent con il debugger collegato, parte della memoria viene occupata dal debugger stesso, rendendo perciò non realistici i nostri test. Il metodo LaunchForTest invece ci permette di eseguire il background agent anche a debugger scollegato.

Il metodo LaunchForTest accetta come parametri il nome dell’agent (che deve essere già stato aggiunto a quelli schedulati nel sistema) e dopo quanto tempo l’agent deve essere eseguito (sotto forma di TimeSpan). Grazie all’utilizzo delle direttive di compilazione, possiamo far sì che il metodo venga eseguito, ad esempio, solo se stiamo compilando l’applicazione in modalità Debug. In questo modo, ci assicuriamo che quando avremo l’applicazione sarà pronta per essere pubblicata sul Marketplace questo codice non verrà eseguito (dato che devono per forza essere compilate in modalità Release, pena il fallimento del processo di certificazione).

Ecco un esempio di codice:

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

ScheduledActionService.Add(task);


#if DEBUG
    ScheduledActionService.LaunchForTest("TestAgent", new TimeSpan(0, 0, 10));
#endif

La cosa interessante è che possiamo utilizzare il metodo LaunchForTest anche all’interno di un background agent, per simulare esecuzioni multiple senza dover attendere lo scheduling da parte del sistema operativo. Ecco un esempio di background agent che, terminato il suo compito (ovvero mostrare una notifica toast), pianifica una nuova esecuzione dello stesso dopo 1 minuto:

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

    #if DEBUG
        ScheduledActionService.LaunchForTest(task.Name, new TimeSpan(0, 1, 0));
    #endif

    NotifyComplete();

}   

Il ciclo di vita di un background agent: il background agent viene disabilitatoimage

Se ricordate quanto spiegato nella prima serie di post che ho pubblicato sui background agent, nell’hub Settings di Mango è stato introdotto un nuovo pannello, chiamato Background tasks, in cui l’utente può gestire i background agents che ha installato sul device. Nello specifico, viene data la possibilità di disabilitare i background agents di tipo periodic, senza costringere l’utente a dover disinstallare l’applicazione per fermare la loro esecuzione.

Ma cosa succede quando un background agent viene disabilitato? La proprietà IsEnabled del nostro task viene messa a false: quando si verifica questa condizione, non dovremmo cercare di aggiungere nuovamente il task allo ScheduledActionService, perchè violeremmo l’esplicita richiesta dell’utente. L’utente però ha a disposizione un checbox nel pannello di controllo che gli consente di riabilitare il background agent all’avvio successivo dell’applicazione.

Purtroppo al momento non esiste modo di sapere da codice se l’utente ha selezionato o meno quel checkbox. Quello che dovremo fare perciò non è tanto controllare il valore della proprietà IsEnabled, ma eseguire l’operazione di schedulazione dell’agent all’interno di un blocco try / catch. Se infatti l’utente non ha abilitato il checkbox e si cerca di schedulare il task, si scatenerà un’eccezione di tipo InvalidOperationException con il messaggio BNS Error: The action is disabled. Quando si verifica questa situazione sta a noi decidere qual è il comportamento migliore: ad esempio, potremmo mostrare un messaggio all’utente avvisandolo che il background agent è stato disabilitato e che, se vuole, può andare nei Settings a riabilitarlo.

Gli esempi di codice pubblicati su MSDN adottano un altro approccio: se la proprietà IsEnabled è impostata a false, l’agent non viene schedulato. Personalmente non vi consiglio questa soluzione(anche se è sicuramente più elegante), perchè non tiene conto del fatto che l’utente possa scegliere di riabilitarlo tramite il checkbox: il risultato sarebbe  che l’agent non verrebbe mai più rischedulato, a meno che l’applicazione non venga disinstallata e reinstallata.

Il ciclo di vita di un background agent: il metodo Abort

Ricordate il metodo NotifyComplete, che deve essere chiamato il prima possibile e che comunica al sistema operativo che il background agent ha terminato la sua esecuzione in maniera corretta?

Bene, ora abbiamo a disposizione un nuovo metodo per gestire il ciclo di vita di un agent, chiamato Abort, che possiamo invocare invece nel momento in cui qualcosa è andato storto e decidiamo che, dato che non sussistono le condizioni necessarie, il background agent non deve più essere eseguito fino a che la nostra applicazione non verrà riaperta e il problema risolto.

Quando il metodo Abort viene chiamato, la proprietà IsScheduled del nostro task viene impostata a false. L’agent risulterà ancora abilitato e attivo, ma non verrà più eseguito automaticamente fino a nuovo ordine. Come comportarci quindi nella nostra applicazione? Se troviamo la proprietà IsScheduled a false ma IsEnabled a true, ci troviamo nella condizione in cui l’agent è stato volontariamente fermato. In più, la proprietà LastExitReason sarà impostata a Abort. In questo caso possiamo procedere a rischedulare il task, dato che siamo stati a noi a fermarne l’esecuzione e non l’utente, disabilitandolo dal pannello di controllo.

Ci sono altre due condizioni che possono portare la proprietà IsScheduled a false (in questo caso però la proprietà LastExitReason avrà un valore differente):

  • L’agent è scaduto, ovvero la sua proprietà ExpirationTime è stata raggiunta senza che venisse rinnovato. In questo caso, possiamo procedere a rischedularlo.
  • L’utente ha disabilitato l’agent dal pannello: in questo caso, però, come abbiamo visto prima anche la proprietà IsEnabled sarà a false.

Il ciclo di vita di un background agent: gestire le eccezioni

Esiste però un’altra condizione che può disabilitare temporaneamente lo scheduling di un background agent, impostando la proprietà IsScheduled a false: quando l’esecuzione del background agent fallisce a causa di un’eccezione (la LastExitReason del task è UnhandledException) oppure perchè ha superato la massima quantità di memoria utilizzabile (la LastExitReason del task è MemoryQuotaExceeded).

In questo caso, dopo due esecuzioni consecutive fallite per uno di questi motivi, lo scheduling viene automaticamente fermato: la proprietà IsScheduled viene perciò impostata su false.

Il consiglio, perciò (soprattutto se state usando background agent al limite come utilizzo della memoria o possibilità di fallimento), è quello di controllare la proprietà LastExitReason e, in caso di fallimento, rischedulare il background agent solo se si è ragionevolmente sicuri che alla prossima esecuzione il problema non si presenterà.

Nel prossimo post: un esempio concreto

Nel prossimo post adatteremo l’applicazione che abbiamo usato in precedenza per testare i background agent per gestire il ciclo di vita completo, andando a gestire in maniera corretta le varie casistiche presentate in questo articolo.


Windows Phone , Microsoft , Mango , Background agents

0 comments

Volete una polo brandizzata Windows Phone Mango? Leggete qui!

Print Content | More

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!


Windows Phone , Mango , DotNetLombardia

0 comments

Un evento online su Windows Phone Mango il 14 Luglio

Print Content | More
logo_windowsphone

Microsoft Italia ha organizzato per Giovedì 14 Luglio un evento virtuale completamente dedicato a Mango: l’evento sarà trasmesso in streaming sul sito ufficiale e vedrà una prima parte introduttiva in cui verranno presentate tutte le novità di Windows Phone Mango per gli sviluppatori. Nella seconda parte, invece, verranno messe a disposizione degli utenti una serie di sessioni di approfondimento on-demand, a cura degli Evangelist Microsoft e di alcuni MVP.

Avrò il piacere di dare anche io il mio contributo, proponendo una sessione sul multitasking in Mango: in mezz’ora cercherò di fare una panoramica il più completa possibile su Fast App Switching, background agent, background audio, background transfers e alarms & reminders.

Se siete sviluppatori mobile non perdetevi questo appuntamento: ci vediamo il 14 Luglio su http://www.microsoft.com/italy/windowsphone/sviluppo/default.aspx


Windows Phone , Mango , Microsoft

0 comments

Alcuni cambiamenti nei servizi in background nella beta 2 dei tool di sviluppo

Print Content | More

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 Smile 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!


Windows Phone , Mango , Microsoft

3 comments

Beta 2 dei tool di sviluppo e beta di Mango per i device in commercio!

Print Content | More

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! Smile 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.


Windows Phone , Marketplace , Mango

2 comments

Evento su Mango di DotNetLombardia: ecco com’è andata!

Print Content | More

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!


Windows Phone , Mango , DotNetLombardia

0 comments