Come aggiornare la tile della propria applicazione senza usare le notifiche push

Print Content | More

samsung-focus-windows-phone-71

Le tile sono una delle innovazioni di Windows Phone 7 più apprezzate sia dagli utenti che dagli sviluppatori: rispetto ad altri OS concorrenti, permettono di dare un tocco veramente personale al proprio device, grazie alla possibilità di “pinnare” in home page informazioni di ogni tipo, dai contatti alle mappe, passando per la musica e le stazioni radio.

In più, gli sviluppatori possono sfruttare le tiles grazie alle notifiche push per veicolare una serie di informazioni: partite un po’ in sordina (più che altro a causa del fatto che richiedono un’infrastruttura server per funzionare), le applicazioni che fanno uso di notifiche push sono in continuo aumento e stanno dimostrando sempre di più la loro utilità ed efficacia (pensiamo a Beezz, client Twitter in grado di aggiornare la tile con il numero di tweets non letti e di spedire notifiche toast ogni volta che riceviamo una mention o un direct message).

Ma se il nostro scopo fosse solo quello di rendere più “dinamica” la nostra applicazione, aggiornando la tile di tanto in tanto? Gestire le notifiche push ha comunque un costo, per quanto la loro implementazione sia semplice (soprattutto se paragonata al mondo iPhone): è necessario comunque prevedere un’applicazione lato server (ad esempio, un servizio WCF) e un database dove memorizzare l’URL e le informazioni dei vari device che si sono registrati per ricevere le notifiche della nostra applicazione.

Ecco perciò che Windows Phone 7 introduce il concetto di TIleSchedule, ovvero la possibilità di definire uno schedule all’interno della nostra applicazione: ad intervalli ciclici, Windows Phone si collegherà all’URL di una immagine che abbiamo specificato, la scaricherà e la userà come background della tile della nostra applicazione.

Rispetto alle notifiche push, ovviamente, questo sistema ha diversi limiti:

  • L’unica informazione che possiamo recuperare e modificare è una nuova immagine di background, al contrario delle Tile push notifications che ci permettono di modificare anche il testo e il contatore.
  • Quando definiamo lo schedule abbiamo modo di specificare uno e uno solo indirizzo dell’immagine, che verrà utilizzata per tutto il ciclo di vita dell’applicazione. Se vogliamo quindi che l’immagine cambi nel tempo, dobbiamo realizzare un’applicazione lato server che, dato lo stesso URL, restituisca una immagine diversa (ad esempio, un servizio Windows  che ciclicamente rinomini una serie di immagini o un HTTP handler che intercetti la chiamata).
  • Se vogliamo che l’immagine cambi in base a determinate condizioni, dobbiamo implementare tutta la logica nel client. Ad esempio, se volessimo realizzare un’applicazione meteo usando le Scheduled Tile invece che le Push Notifications, dovrebbe essere l’applicazione stessa a recuperare le coordinate GPS, richiedere le previsioni meteo e selezionare l’immagine più adatta. Utilizzando le notifiche push, potremmo invece snellire il client demandando tutte queste operazioni al server, lasciando all’applicazione Windows Phone solamente il compito di localizzare la città in cui si trova l’utente.

In definitiva, le scheduled tiles vanno bene solo se il nostro scopo è quello di rendere più dinamica la tile della nostra applicazione. Volendo, sarebbe anche possibile implementare meccanismi per gestire situazioni più complesse, ma sarebbe completamente inutile: per questo tipo di scenari la soluzione ideale sono le notifiche push.

Ora che abbiamo introdotto le Scheduled Tiles e quali sono i casi d’uso, vediamo come funzionano.

L’oggetto ShellTileSchedule

Il funzionamento è molto semplice: tutto ruota intorno alla classe ShellTileSchedule, che si trova nel namespace Microsoft.Phone.Shell. Una volta creata una nuova istanza di questa classe, siamo pronti per definirne i parametri principali:

  • Interval: l’intervallo di tempo trascorso il quale Windows Phone recupera l’immagine presente all’URL specificato. Il parametro è di tipo UpdateInterval e si va dal valore minimo EveryHour (ogni ora) al valore massimo EveryMonth (ogni mese).
  • MaxUpdateCount: è un numero intero che rappresenta il numero di volte dopo il quale lo schedule viene invalidato e perciò non viene più scaricata l’immagine e aggiornata la tile. Tale parametro è facoltativo: se non lo specifichiamo, lo schedule continuerà ad essere eseguito fino a quando l’applicazione non verrà disinstallata.
  • Recurrence: possiamo impostare se lo schedule deve essere ciclico oppure essere eseguito una volta soltanto. Il parametro è di tipo UpdateRecurrence e accetta i valori Interval e OneTime.
  • RemoteImageUri: è un oggetto di tipo Uri che rappresenta il percorso dell’immagine che deve essere visualizzata ogni qualvolta scatta lo scheduler.
  • StartTime: anche questo è un parametro opzionale e può essere impostato se vogliamo che lo scheduler si attivi solo a partire da una determinata data.

Infine l’oggetto espone due eventi, che ci permettono di gestire il ciclo di vita dello scheduler:

  • Start, che conferma la pianificazione dello scheduler secondo le impostazioni che abbiamo definito.
  • Stop, che annulla la pianificazione dello scheduler.

Vediamo un breve esempio di codice:

private void CreateShellTileSchedule()
{
    ShellTileSchedule shellTileSchedule = new ShellTileSchedule()
    {
        Recurrence = UpdateRecurrence.Interval,
        Interval = UpdateInterval.EveryHour,
        RemoteImageUri =
        new Uri(@"http://qmatteoq.tostring.it/UserFiles/uploaded/qmatteoq/Microsoft_Silverlight_thumb.jpg")
    };
    shellTileSchedule.Start();
}

Dove possiamo inserire questo codice?

Nell’esempio possiamo vedere la creazione di un semplice metodo CreateShellTileSchedule, che non fa altro che definire un nuovo oggetto di tipo ShellTileSchedule, definirne le impostazioni (nello specifico, si tratta di uno scheduler ciclico che ogni ora recupera una immagine dal mio blog) e lanciarlo.

Ma dove possiamo inserire questo codice? In realtà non esiste un punto preciso, lo scheduler può essere definito e attivato in qualsiasi punto della nostra applicazione. Uno e uno solo scheduler può essere attivo: se noi definiamo uno scheduler in un punto della nostra applicazione e poi, successivamente, ne definiamo un secondo, sarà quest’ultimo a vincere e ad essere attivato.

Che immagini possiamo utilizzare?

In questo caso valgono le stesse guidelines che vanno rispettate nella realizzazione della tile per la nostra applicazione: la dimensione richiesta è di 173 x 173. In realtà, l’immagine può avere anche dimensioni diverse, in questo caso ci penserà Windows Phone in automatico ad effettuare il resize dell’immagine. Non si tratta però di una scelta consigliata, dato che spesso e volentieri il risultato non sarà dei migliori.

Quali scenari?

Quali sono gli scenari in cui possiamo usare le Scheduled Tile? Come abbiamo già visto, sono da scartare tutte le situazioni in cui è necessaria della logica complessa che definisca il tipo di immagine da visualizzare. Un’idea potrebbe essere quella di realizzare un’applicazione che permetta all’utente di selezionare quale icona preferisce tra una set di immagini disponibili. Oppure ancora un’applicazione dedicata alle immagini (ad esempio, un client Flickr) potrebbe usare questo meccanismo per mostrare come tile l’ultima foto caricata dall’utente, oppure la più visualizzata. In casi come questi, è necessaria comunque un’infrastruttura server, anche solo per ospitare le immagini: il parametro RemoteImageUri non può infatti contenere l’URL locale di una immagine all’interno dello XAP. Si tratta però sicuramente di un’infrastruttura più semplice e agevole da implementare rispetto a quella richiesta dalle notifiche push.

Per portarvi un esempio concreto, nella serie di applicazioni Citycam che ho sviluppato sto introducendo un meccanismo, basato proprio sulle ShellTileSchedule, che vi permette di visualizzare direttamente in home screen l’immagine ripresa da una delle webcam disponibili, aggiornata ora per ora.

Come testarla?

Il testing di questa funzionalità è semplice ma non immediato: lo scheduler infatti funziona correttamente anche usando l’emulatore, l’importante è ricordarsi di pinnare in home page l’icona della nostra applicazione. Quello che non rende molto agevole il testing è che l’intervallo di tempo minimo configurabile per lo scheduler è di un’ora e non è possibile in alcun modo forzare l’aggiornamento della tile. Una volta lanciata l’applicazione e pianificato lo scheduler, è necessario perciò attendere che questo vada in esecuzione per poter verificare il risultato.

Attenzione alla capabilities!

Come vi ho già spiegato in altri post in passato, le applicazioni Windows Phone fanno uso di un file XML che definisce tutte le caratteristiche dell’applicazione, tra cui le capabilities, ovvero quali funzionalità sono richieste dall’applicazione (in modo che una persona, prima del download dell’applicazione, sappia se l’app fa uso di qualche caratteristica particolare come le push notifications o la geolocalizzazione.

Nonostante non siano delle vere e proprie notifiche push, affinche le ShellTileSchedule funzionino correttamente è necessario abilitare la relativa capabilities, ovvero

<Capability Name="ID_CAP_PUSH_NOTIFICATION"/>

Se non lo fate, otterrete una InvalidOperationException nel momento in cui chiamerete il metodo Start dell’oggetto di tipo ShellTileSchedule.

Un’applicazione d’esempio

Allegato a questo post trovate una semplice applicazione di esempio, che permette all’utente di selezionare una delle tile disponibili tramite una serie di radio button. Premendo il pulsante Set schedule, lo schedule verrà pianificato. A questo punto, chiudendo l’app e mettendo la sua icona in home page nel giro di un’ora la tile si dovrebbe aggiornare con l’immagine scelta. Non sto qui a riportare il codice dell’applicazione, dato che il “cuore” della logica è il metodo CreateShellTileSchedule mostrato in precedenza: quello che cambia è solamente il parametro RemoteImageUri, che non è più fisso ma varia a seconda del radio button scelto dall’utente. Inoltre, in questo caso, lo schedule utilizzato è di tipo OneTime: l’immagine ospitata sul mio blog, infatti, non cambierà ciclicamente. Lo scopo della mia applicazione è semplicemente quello di consentire all’utente di selezionare la propria tile preferita.


Windows Phone , Microsoft , Push notifications

106 comments

Related Post

  1. #1 da Stefano Wednesday August 2011 alle 11:08

    Ciao Matteo,
    nella mia applicazione aggiorno la tile grazie alla classe ShellTileSchedule che ho scoperto proprio grazie al tuo blog.

    Tutto ha sempre funzionato abbastanza bene ma, da circa un mese a questa parte, a non pochi alcuni utenti, il metodo ShellTileSchedule.Start genera l'eccezione InvalidOperationException.

    All'inizio ho pensato ad un problema legato alle build beta di Mango ma, tutti utilizzano NoDo (7392).

    Preciso che agli utenti che hanno questo problema l'eccezione si presenta ogni qualvolta la mia app invoca il metodo ShellTileSchedule.Start, mentre agli altri, me compreso, non si è mai presentato.

    Qualche idea?

    Questi sono i dettagli:
    http://pastebin.com/2z0L9FW2

  2. #2 da Stefano Wednesday August 2011 alle 11:09

    p.s. Grazie

  3. #3 da Matteo Pagani Wednesday August 2011 alle 11:25

    Ciao Stefano,
    prova a fare questo test: tramite il CapDetect tool (se non sai come usarlo, guarda qui http://www.qmatteoq.com/blog/post/windows-phone-developer-tools-october-update), prova a rilevare le capabilities della tua applicazione e verifica che quella relativa alle push notifications venga riconosciuta.
    Ho avuto un problema simile anche io, a breve uscirà un post con la mia esperienza: si tratta di un problema con App Hub che rimuove le capabilities non identificate, anche se effettivamente poi sono usate.

    Fammi sapere.
    Ciao!

  4. #4 da Stefano Thursday September 2011 alle 08:44

    Grazie per la celere risposta.

    Premetto che sto usando i nuovi tools ma, sto compilando ancora per wp 7.0.

    Questo è quello che riporta CapabilityDetection:

    C:\Program Files\Microsoft SDKs\Windows Phone\v7.0\Tools\CapDetect>CapabilityDetection.exe Rules.xml NoDo
    ID_FNCTNL_SILVERLIGHT_FRAMEWORK
    ID_CAP_NETWORKING
    ID_CAP_WEBBROWSERCOMPONENT
    ID_CAP_IDENTITY_DEVICE
    ID_CAP_PHONEDIALER
    ID_CAP_PUSH_NOTIFICATION

    Pare essere tutto ok mentre questo è quello che riporta l'AppHub:

    Required Device capabilities:
    data services
    web browser
    phone calls
    Silverlight framework
    phone identity
    trial

    Qui le notifiche non vengono citate, quindi pare proprio esserci un problema.

    Qualche suggerimento?
    Grazie ancora


  5. #5 da Stefano Tuesday September 2011 alle 12:54

    Ho risolto! Con l'inganno ma... ho risolto:
    ho inviato una nuova versione inserendo questa funzione (che non richiamo mai):

    public void UpdateTileFake(string fake)
    {
    try
    {
    new HttpNotificationChannel(fake);
    }
    catch (Exception) { }
    }

    e l'app ha ricevuto l'autorizzazione per le notifiche push!
    Spero questo possa essere utile a qualcuno.

    Credo che il problema dipenda dal fatto che la classe ShellTileSchedule su mango non necessiti dell'autorizzazione alle notifiche push mentre su NoDo si!

    Saluti
    Stefano Pireddu

  6. #6 da Matteo Pagani Friday September 2011 alle 10:35

    Ciao Stefano,
    grazie per aver condiviso la tua soluzione.
    Mi riprometto di indagare più a fondo, perchè la questione è strana: anche a me è capitato di pubblicare recentemente applicazioni che facessero uso della ShellTileSchedule e che incappassero in un rifiuto da parte del Marketplace, nonostante il core sia lo stesso di altre applicazioni che ho scritto e che in passato sono state approvate senza problemi.

  7. #7 da Stefano Friday September 2011 alle 04:15

    Ciao Matteo,
    non credo ci sia tanto da indagare... ti racconto la mie esperienza...

    Tre utenti, dopo aver aggiornato la mia app, mi contattarono segnalandomi un anomalia grafica: una stringa che doveva cambiare colore rimaneva rossa.
    Dopo vari test, versioni beta, ecc... finalmente individuai la causa: ShellTileSchedule.Start.

    Allora creai un nuovo aggiornamento che risolvesse il problema grafico e che allo stesso tempo mi segnalasse gli errori derivanti dal metodo incriminato.

    Risultato: ho ricevuto centinaia e centinaia di segnalazioni e tutte da utenti che NON utilizzavano mango!
    Questo non poteva essere una coincidenza dato che più del 20% degli utenti utilizza Mango (nelle varie versioni).
    Inoltre il mio dispositivo, aggiornato alla beta di mango, non aveva mai generato alcuna eccezione pur avendolo sottoposto a centinaia di test!

    Quasi certamente quindi il problema è proprio quello che ho scritto nel commento precedente, ovvero su mango la classe ShellTileSchedule non richiede l'autorizzazione per le notifiche push, che invece è richiesta da NoDo e precedenti.

    In pratica credo sia un bug dell'App Hub che non distingue i due casi.

    Concludo dicendoti che non ho ricevuto nessuna segnalazione da chi utilizza l'ultima versione della mia app mentre continuo a riceverle da chi invece utilizza la precedente versione.

    Saluti
    Stefano


(will not be published)
(es: http://www.mysite.com)