Windows Phone, Microsoft, Push notifications, Entity Framework, WCF, SQL CE, WhyMCA, Android, IOS, Mango, Service Reference, Mix, Mindscape, Silverlight, DotNetLombardia, Azure

Nel post precedente abbiamo realizzato il servizio che, per il nostro progetto di esempio sulle notifiche push, fa da ponte tra l’applicazione server e la nostra applicazione Windows Phone. E’ giunto il momento di realizzare l’applicazione server vera e propria, che si occuperà di inviare le notifiche push verso i device registrati

Premessa: l’esempio che andremo a realizzare è molto semplice, in uno scenario reale avrebbe senso implementare nella nostra applicazione molte più feature. Ci torneremo in un secondo momento.

Mettiamoci al lavoro: un client WPF

La tecnologia scelta per realizzare l’applicazione server è WPF, il “fratello maggiore” di Silverlight. Realizzeremo una semplicissima applicazione Windows che, alla pressione di un tasto, invierà la notifica al device e mostrerà a video la risposta ottenuta dal Microsoft Push Notification Server (che, vi ricordo, è il servizio on the cloud di Microsoft che si occupa di inviare le notifiche ai device per conto vostro).

Apriamo Visual Studio e, nella stessa soluzione che abbiamo creato nel post precedente per il servizio, aggiungiamo un nuovo progetto di tipo WPF Application (che troviamo sotto la voce Windows).

Come prima cosa cosa, dobbiamo predisporre l’applicazione per utilizzare la Push Notication Server Library di Microsoft: come anticipato nel post introduttivo a questo tutorial, si tratta di una “recipe” pubblicata dal team di Windows Phone che vi facilità la vita nella gestione delle notifiche push nella vostra applicazione server. Come sapete, le notifiche push non sono nient’altro che XML che vengono spediti tramite una chiamata HTTP in POST verso l’URL del canale: in condizioni normali, nella vostra applicazione dovreste definire il formato dei vari XML, aggiungere tutti gli header necessari, formattarli correttamente e poi, dopo l’invio, predisporvi a leggere la risposta del Push Notification Server. La libreria di Microsoft vi fa risparmiare tempo, facendo tutto questo per voi ed evitando di dover riscrivere sempre lo stesso codice in ogni progetto: tale libreria vi mette a disposizione tre oggetti diversi, uno per ogni tipo di notifica push, che accettano in input i vari parametri che identificano la notifica (ad esempio, nel caso di una notifica toast titolo e messaggio) e che espongono il metodo Send, che effettua l’invio vero e proprio, e che tramite un evento di callback, vi restituisce le informazioni sull’esito dell’operazione.

Scarichiamo perciò la recipe dal sito ufficiale e scompattiamola in una cartella: uno dei progetti contenuti all’interno della soluzione si chiama WindowsPhone.Recipes.Push.Messasges. Questa è la libreria vera e propria, che dovremo aggiungere allla nostra soluzione: possiamo aggiungere direttamente l’intero progetto (tasto destro sulla soluzione e scegliamo Add Existing Project) oppure possiamo aprirlo, compilarlo e aggiungere solo una reference alla DLL chiamata WindowsPhone.Recipes.Push.Messasges.dll.

Ora che è tutto pronto possiamo iniziare lo sviluppo e vero proprio. Partiamo dall’interfaccia grafica, molto semplice, ovvero tre pulsanti per inviare i tre tipi di notifica esistenti. Ecco il codice della MainWindow.xaml, ovvero la pagina che viene caricata all’avvio della nostra applicazione.

<Grid>
    <Button Content="Send toast" Height="23" HorizontalAlignment="Left" Margin="33,27,0,0" VerticalAlignment="Top" Width="75" Click="Button_Click" />
    <Button Content="Send tile" Height="23" HorizontalAlignment="Left" Margin="155,27,0,0"  VerticalAlignment="Top" Width="75" Click="Button_Click_1"/>
    <Button Content="Send raw" Height="23" HorizontalAlignment="Left" Margin="279,27,0,0" VerticalAlignment="Top" Width="75" Click="Button_Click_2" />
</Grid>

Il secondo step è quello di aggiungere una reference al nostro servizio WCF, così da poter recuperare l’elenco dei device: clicchiamo con il tasto destro sul nostro progetto e scegliamo Add Service Reference. Dato che il servizio fa parte della stessa soluzione, non abbiamo bisogno di fare l’host su un server Web, ma ci penserà direttamente Visual Studio. Ci basta premere il pulsante Discover e automaticamente verranno trovati tutti i servizi disponibili: a questo punto possiamo aggiungere una reference a PushService.

Vediamo ora il codice di esempio dell’evento Button_Click, che viene invocato quando mandiamo una notifica toast a tutti i device.

private void Button_Click(object sender, RoutedEventArgs e)
{
    List<Device> devices = new List<Device>();

    PushServiceClient client = new PushServiceClient();
    ToastPushNotificationMessage toast = new ToastPushNotificationMessage
    {
        SendPriority = MessageSendPriority.High,
        SubTitle = "Subtitle",
        Title = "Title"
    };

    client.RetrieveAllDevicesCompleted += (obj, parameter) =>
                                              {
                                                  devices = parameter.Result;
                                                  foreach (Device device in devices)
                                                  {
                                                      toast.SendAsync(new Uri(device.ChannelUri),
                                                                      result =>
                                                                      MessageBox.Show(
                                                                          result.NotificationStatus.ToString()),
                                                                      error =>
                                                                      MessageBox.Show(error.Exception.Message));
                                                  }
                                              };
    client.RetrieveAllDevicesAsync();
}

La prima cosa che facciamo è definire la nostra notifica, creando una nuova istanza della classe ToastPushNotificationMessage. Ogni notifica espone proprietà specifiche per il suo tipo: ecco perciò che questo oggetto espone le proprietà Title e SubTitle, la notifica di tipo Tile espone invece le proprietà Count e BackgroundImageUri e così via. Una proprietà in comune a tutti è SendPriority, che identifica la priorità che ha la nostra notifica. Viene accettato uno dei tre valori dell’enumeratore di tipo MessageSendPriority, ovvero Low, Medium e High. Più è bassa la priorità, maggiore sarà il tempo necessario affinchè questa venga ricevuta dal device. Siccome in questo momento vogliamo testare subito se la nostra applicazione funziona, utilizziamo la priorità High, che consiste nell’invio in tempo reale.

E’ giunto il momento di chiamare il nostro servizio per recuperare tutti i device: creiamo una istanza del PushServiceClient e ci sottoscriviamo all’evento RetrieveAllDevicesCompleted, che viene invocato nel momento in cui il servizio ha terminato le operazioni lato server ed ha restituito il risultato dell’elaborazione. La sintassi che utilizziamo è quella degli anonymous delegates, ovvero non definiamo un nuovo evento con un nome ben preciso al di fuori del blocco di codice corrente  ma lo facciamo direttamente inline. In questo modo, possiamo accedere agli oggetti e alle variabili dichiarate all’interno del metodo Button_Click (nel nostro caso, l’oggetto toast) senza bisogno ad esempio di definirle come variabili globali.

L’oggetto parameter (che contiene gli argomenti di ritorno della callback) espone la proprietà Result, che contiene il risultato dell’elaborazione, ovvero la collection con tutti i device memorizzati nel database. Con un ciclo foreach passiamo in rassegna tutti i device disponibili e, per ognuno di essi, chiamiamo il metodo SendAsync esposto dalla notifica (di questo metodo esiste anche la versione sincrona, chiamata semplicemente Send, ma per evitare che la UI della nostra applicazioni si blocchi fino a che non è stata ricevuta una risposta ho preferito usare il metodo asincrono).

Il metodo SendAsync accetta tre parametrI:

• l’URL del canale a cui spedira la notifica, di tipo Uri, che recuperiamo dall’oggetto di tipo Device che stiamo iterando in quel momento.
• Un evento di callback che viene chiamato nel momento  in cui l’operazione è andata a buon fine. Nel nostro caso, mostriamo semplicemente un messaggio a video con lo stato dell’invio.
• Un evento di callbak che viene chiamato nel momento in cui si è verificato un errore. Nel nostro caso, mostriamo un messaggio di errore con l’eccezione.

L’argomento di ritorno del metodo SendAsync (nel nostro esempio si chiama Result) espone parecchie informazioni sull’esito dell’invio (come il codice della risposta), che sarebbe utile mantenere e tracciare in una applicazione client più completa.

Come dicevo all’inizio, infatti, l’esempio che abbiamo realizzato è molto semplice. Un client vero e proprio potrebbe implementare una serie di feature ulteriori quali:

• Salvare in un database lo storico delle risposte ricevute in seguito agli invii delle notifiche, così da mantenere per ogni device un log di quello che è stato fatto.
• Sfruttare i codici di ritorno per implementare un rudimentale QoS: il Push Notification Service di Microsoft infatti non offre un servizio che assicuri la corretta ricezione della notifica, ma si limita a riportarvi l’esito dell’invio. Sarebbe interessante implementare, ad esempio, un meccanismo di retry automatico dell’invio dopo un certo periodo di tempo nel caso in cui la notifica sia stata rifiutata per problemi di connettività (ad esempio, il device si trovava in quel momento in una zona dove non c’era segnale). Oppure ancora un meccanismo di fallback, per cui se ad esempio inviamo una notifica raw ma il MPNS ci risponde che l’applicazione in quel momento è chiusa, optare per una toast.
• Dare la possibilità di inviare una notifica ad un singolo device (o ad un gruppo di device): abbiamo già implementato un metodo nel servizio per ottenere questo risultato, ma al momento non è stato utilizzato nella realizzazione dell’applicazione server.

Largo alla fantasia perciò: scopo di questo post era darvi le basi necessarie per capire il meccanismo di invio delle notifiche push e la gestione dei relativi messaggi di ritorno. Ora tocca a voi darvi da fare per implementare la soluzione più adatta alle vostre esigenze!

Nel prossimo post vedremo l’unica parte del progetto che ci manca da realizzare: il client Windows Phone che riceverà le notifiche. Alla prossima!

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

Dopo aver gettato le basi teoriche necessarie per capire il progetto che andremo a realizzare, siamo pronti per iniziare a costruire il primo “pezzo”: il servizio WCF che farà da ponte tra l’applicazione server (che invierà le notifiche) e l’applicazione Windows Phone (che le riceverà). Come abbiamo detto l’altra volta, il servizio si occuperà di memorizzare tutti i canali aperti verso i device in un database SQL CE e di restituirli all’applicazione server quando richiesto.

Partiamo perciò aprendo Visual Studio e creando un nuovo progetto di tipo WCF Service Application, che troviamo sotto la categoria WCF. Il progetto includerà in automatico due file, chiamati IService.cs e Service.cs. Trattare qui tutta la teoria che sta dietro ai servizi WCF è praticamente impossibile: non basterebbe un libro di 1000 pagine per esaurire l’argomento.

Per i nostri scopi ci basti sapere che:

• IService.cs è l’interfaccia che definisce i metodi che verranno esposti dal servizio,  che vengono identificati grazie all’attributo [OperationContract], con il quale andremo a decorare la firma dei nostri metodi.
• Service.cs è l’implementazione concreta dell’interfaccia, che definisce cosa faranno effettivamente i nostri metodi.

Possiamo rinominare a piacimento queste due classi, oppure anche buttare via i file e ricrearli: nell’esempio da me realizzato le ho rinominate come IPushService.cs e PushService.cs.

E’ arrivato il momento di definire il dominio del nostro servizio, ovvero gli oggetti con cui lavoreremo e che verranno scambiati tra il servizio e l’applicazione server. Per questo progetto il dominio è molto semplice: quello che ci serve è semplicemente memorizzare ogni device che si registrerà per ricevere le notifiche push, ognuno dei quali sarà identificato dalle seguenti caratteristiche:

• Un id univoco, che utilizziamo per identificare il device in maniera univoca. Dobbiamo ricordarci infatti che l’URL del canale è sì univoco, ma non è detto che rimanga sempre lo stesso per tutto il ciclo di vita della nostra applicazione. In una applicazione reale avrebbe senso utilizzare come id l’Anonymous Live Id oppure l’ID univoco del device: per il nostro progetto di esempio utilizzeremo un Guid, dato che l’emulatore non è in grado di restituire queste informazioni (in quanto non è associabile ad un Live Id).
• L’URL del canale, a cui dovremo inviare le notifiche push.
• Un semplice DateTime con la data e l’ora in cui è stato registrato il device.

Ecco la semplice classe cha mappa queste caratteristiche:

public class Device
{
    public Guid Id { get; set; }
    public string ChannelUri { get; set; }
    public DateTime RegistrationDate { get; set; }
}

E’ il momento di definire cosa farà il nostro servizio: andiamo nel file che definisce l’interfaccia IService.cs ed aggiungiamo la firma dei tre metodi che ci serviranno per gestire le notifiche push.

[ServiceContract]
public interface IPushService
{
    [OperationContract]
    string RetrieveChannelUri(Guid id);

    [OperationContract]
    void SaveChannelUri(string channelUri, Guid id);

    [OperationContract]
    List<Device> RetrieveAllDevices();
}

• string RetrieveChannelUri (Guid id): questo metodo, dato l’id di un device, restituirà l’URL del canale a cui spedire la notifica.
• void SaveChannelUri (string channelUri, Guid id): questo metodo provvederà a salvare sul database l’id del device e l’url del canale e verrà chiamato dall’applicazione Windows Phone.
• List<Device> RetrieveAllDevices(): questo metodo restituisce una collezione di Device e verrà utilizzato dall’applicazione server per spedire una notifica a tutti i dispositivi registrati.

Prepariamo il database

Ora che abbiamo predisposto tutto il necessario, è il momento di mappare la nostra classe Device sul database grazie a Entity Framework. Abbiamo già definito la classe Device, che corrisponderà idealmente ad una riga della nostra tabella. Per far capire a Entity Framework che vogliamo trasformare questi oggetti in righe e tabelle, dobbiamo sfruttare la classe DbContext. Dobbiamo perciò creare una nuova classe che erediterà da DbContext e nella quale andremo ad inserire come sarà strutturato il nostro database, grazie alla classe DbSet, che rappresenta una collezione di oggetti mappata su una tabella. Ecco come apparirà il nostro context:

public class Context: DbContext
{
    public DbSet<Device> Devices { get; set; }
}

Utilizzando la sintassi tipica dei generics (DbSet<Device>) creiamo una collezione DbSet composta da oggetti di tipo Device. E’ con questa collezione che andremo a interagire all’interno del nostro servizio per recuperare, inserire o aggiornare dati sul database. Ma come facciamo a creare il database vero e proprio? Potremmo farlo manualmente tramite gli strumenti messi a disposizione da Visual Studio, ma Entity Framework Code First, grazie ad alcune convenzioni, è in grado di generare da solo il database se questo non esiste. Vediamo come fare.

Innanzitutto dobbiamo inserire nel file di configurazione del servizio (App.config) la stringa di connessione al database: nel nostro caso, essendo un database SQL CE 4.0 (quindi disconnesso e memorizzato su singolo file), sarà qualcosa di questo genere:

<connectionStrings>
  <add name="Context" connectionString="Data Source=C:\PushNotificationsDemo\PushNotificationDemo.Service\Data\Notifications.sdf" providerName="System.Data.SqlServerCe.4.0"/>
</connectionStrings>

La proprietà Data Source, nel nostro progetto di esempio, contiene semplicemente il percorso completo al file fisico dove vorremo memorizzare il database: non abbiamo aggiunto criteri di protezione, perciò non abbiamo specificato credenziali di accesso. Se fate attenzione, noterete una cosa importante: il nome della stringa di connessione è uguale al nome della classe che abbiamo creato in precedenza e che eredita da DbContext. Questa è la convenzione che fa sì che, in automatico, il nostro servizio, all’avvio, controlli se il database esiste o meno e, in caso contrario, lo crei.

Il servizio vero e proprio

Ora possiamo passare all’implementazione concreta del servizio, ovvero cosa devono fare i metodi esposti. Grazie a Entity Framework, a LINQ e all’uso delle lambda expression, il codice è molto semplice:

public class PushService : IPushService
{
    public string RetrieveChannelUri(Guid id)
    {
        using (Context context = new Context())
        {
            return context.Devices.SingleOrDefault(x => x.Id == id).ChannelUri;
        }            
    }

    public void SaveChannelUri(string channelUri, Guid id)
    {
        using (Context context = new Context())
        {
            if (context.Devices.Any(x => x.Id == id))
                context.Devices.SingleOrDefault(x => x.Id == id).ChannelUri = channelUri;
            else
            {
                Device device = new Device
                                    {
                                        ChannelUri = channelUri,
                                        Id = id,
                                        RegistrationDate = DateTime.Now
                                    };
                context.Devices.Add(device);
            }

            context.SaveChanges();
        }
    }

    public List<Device> RetrieveAllDevices()
    {
        using (Context context = new Context())
        {
            return context.Devices.ToList();
        }
    }
}

• Il metodo RetrieveChannelUri ritorna l’URL del canale che è stato assegnato un device dato l’ID univoco dello stesso.
• Il metodo SaveChannelUri verifica innanzitutto se esiste già un device registrato con l’ID assegnato. In caso affermativo, si limita ad aggiornare il record già esistente con il nuovo URL del canale; in caso negativo, crea un nuovo oggetto di tipo Device e lo aggiunge alla collection Devices esposta dal nostro context.
• Il metodo RetrieveAllDevice ritorna una collection di tipo List di tutti gli oggetti di tipo Device memorizzati sul database.

Se notate, abbiamo racchiuso il codice di tutti e tre i metodi all’interno di un costrutto using: questo perchè ogni qualvolta eseguiamo delle operazioni tramite l’oggetto context apriamo una connessione al database, che dobbiamo ricordarci di chiudere nel momento in cui abbiamo terminato le operazioni, altrimenti lasceremmo delle connessioni “fantasma” aperte che andrebbero a causare problemi di performance non indifferenti. Il costrutto using (che possiamo utilizzare grazie al fatto che la classe DbContext implementa l’interfaccia IDisposable) fa si che la connessione al database venga automaticamente chiusa ogni qualvolta le operazioni contenute all’interno del costrutto siano terminate (sia con successo che con errori).

Un po’ di sano testing

Siamo pronti per fare una prova e verificare che il tutto vada correttamente: premiamo F5 in Visual Studio e lanciamo il servizio. Per il debug verà utilizzato in automatico Wcf Test Client, un tool di Microsoft molto comodo che vi permette di invocare i vari metodi esposti dal servizio e di vederne i valori di ritorno, senza la necessità di costruire ad esempio una applicazione a linea di comando per testare se il tutto funziona correttamente.

Nell’elenco di sinistra troverete tutti i metodi esposti dal servizio: facendo doppio clic su uno di essi, si aprirà un pannello (quello di destra) che vi permetterà di valorizzare i parametri di input del metodo e di vedere la risposta della vostra richiesta.

Fate doppio clic sul metodo SaveChannelUri() e date due valori fittizzi ai parametri id e channelUri, dopodichè premete il pulsante Invoke. Nella sezione Response non comparirà nessun risultato: è normale, dato che il metodo non ritorna nessun tipo di informazione. Se però è andato tutto a buon fine, nel percorso che avete specificato come Data Source nella connection string dovreste trovare un nuovo file, che rappresenta il vostro database. Come prova del nove, potete usare il tool di Visual Studio (che abbiamo installato nel post precedente) per vedere il contenuto del database:

• Aprite Server Explorer (se non lo vedete, cliccate su View, Server Explorer nei menu di Visual Studio).
• Ci sarà la voce Data Connections: fateci clic con il tasto destro e scegliete Add Connection.
• Alla voce Data Source, premete Change e dall’elenco selezionate Microsoft SQL Server Compact 4.0.
• Alla voce Connection Properties, premete Browse e andate a scegliere il database appena creato.
• A questo punto premete Ok: se tutto è andato a buon fine, in Server Explorer sarà disponibile la nuova connessione dati e avrete modo di lavorare sul database come fareste con SQL Server Managament Studio. Se il codice che abbiamo scritto prima era corretto e il test del servizio non ha dato problemi, dovremmo trovare una nuova tabella chiamata Devices, con all’interno un nuovo record: quello che è stato creato quando abbiamo premuto il tasto Invoke nel Wcf Test Client.

In conclusione

Abbiamo realizzato il nostro servizio e ci siamo “sporcati” le mani con Entity Framework e SQL CE 4: nel prossimo post costruiremo l’applicazione server che invierà le notifiche push, aiutandoci con la Push Notifications Server Side Library di Microsoft.

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

Abbiamo già affrontato in passato la “teoria” necessaria per capire cosa sono le push notifications e l’architettura messa in piedi da Microsoft per poterle utilizzare nelle applicazioni Windows Phone.

In questa prima serie di post vedremo come creare un semplice “ecosistema” per l’utilizzo delle push notifications, composto da:

• Un client, ovvero l’applicazione Windows Phone che riceverà le notifiche.
• Un server, ovvero una applicazione WPF che invierà le notifiche verso i device. Per realizzarla, sfrutteremo una delle “ricette” di Windows Phone: Notification Push Server Library, ovvero una libreria realizzata dal team di Windows Phone che wrappa tutto il codice necessario all’invio delle notifiche push, esponendoci dei semplici metodi che richiedono in input solamente i parametri della notifica.
• Un servizio WCF, che farà da ponte tra le due applicazioni: client e server si scambieranno le informazioni necessarie per gestire l’invio delle notifiche tramite questo database.

Giusto per mettere un po’ di carne al fuoco, utilizzeremo due recenti tecnologie di Microsoft per implementare concretamente il nostro scenario. Scopo di questo tutorial sarà quello di famigliarizzare con le notifiche push e con il loro funzionamento.

Entity Framework 4.1 Code First

Entity Framework è l’ORM di casa Microsoft: ORM sta per Object-relation Mapping e identifica tutti quei prodotti che nascono con lo scopo di “astrarre” allo sviluppatore la presenza di un database, consentendogli di lavorare con le strutture ad oggetti con cui è famigliare. L’ORM si occuperà, dietro le quinte, di tramutare le operazioni con i nostri oggetti in query SQL, che verranno eseguite sul database. In realtà, gli ORM che troviamo sul mercato sono molto più di questo: permettono infatti un livello di configurazione e di ottimizzazione che ci consente di lavorare con i database in maniera molto più efficace rispetto all’uso tradizionale di query SQL.

Entity Framework è la soluzione proposta da Microsoft e si distingue dalle altre per l’ottimo livello di integrazione con Visual Studio e le tecnologie Microsoft: strumenti visuali, tool di configurazione e quant’altro aiutano lo sviluppatore ad essere operativo il prima possibile. Ci sono tanti altri ORM sul mercato: uno dei più famosi è NHibernate (porting in .NET di Hibernate, ORM facente parte del mondo Java), che offre un grado di potenza e flessibilità che Entity Framework non è ancora riuscito a raggiungere; tutto questo viene “pagato” in termini di maggiore complessità per la configurazione e il mapping (ovvero la fase in cui si definisce la corrisponde tra oggetti e tabelle del database).

Code First è un nuovo metodo di mapping che è stato introdotto con la versione 4.1 di EF, di recentissima uscita (la RTM è stata rilasciata in occasione del MIX): questo metodo è molto comodo quando, come nel nostro caso, stiamo partendo con un progetto da zero, per il quale non esiste già un database pronto da utilizzare. Questo sistema consente di iniziare come faremmo con un progetto tradizionale, ovvero definendo le classi che compongono il dominio: rispettando una serie di convenzioni durante la scrittura del codice, Entity Framework sarà in grado di generare in automatico il database e le tabelle necessarie.

In rete ci sono molti articoli che su questa tecnologia scendono molto più in profondità di quanto faremo noi in questo progetto: vi segnalo ad esempio questo di Stefano Mostarda pubblicato su ASPItalia.

Per utilizzare Entity Framework 4.1 ci sono molti modi: potete scaricare il package ufficiale (che installa anche alcuni template di sviluppo), oppure cercarlo su NuGet, l’estensione di Visual Studio che funge da aggregatore in un unico package manager delle tantissime librerie .NET disponibili in rete.

SQL CE 4.0

SQL CE è una versione standalone di SQL Server, che permette di creare database disconnessi, ovvero che non richiedono un DBMS in esecuzione per poter funzionare e che vengono salvati come file su disco. Ovviamente, le performance e le potenzialità sono molto diverse rispetto ad un DBMS tradizionale: la complessità del progetto che stiamo per realizzare però è veramente bassa e, dato che sarà una demo, il carico di lavoro non sarà di certo un problema. Ecco perciò che possiamo approfittare di questa occasione per fare qualche esperimento con l’ultimissima versione di SQL CE, la 4.0 per l’appunto, che ha introdotto come principale novità il supporto alle applicazioni web ASP.NET in modalità “medium trust” (ciò significa che possiamo fare il deploy sul server del nostro database come se fosse un qualsiasi altro file del progetto, dandoci la possibilità di utilizzare un database senza avere a disposizione un server db dedicato).

La buona notizia è che SQL CE 4.0 supporta Entity Framework: potremo quindi usare l’ORM di casa Microsoft per mappare le nostre classi con le tabelle sul database come se si trattasse di un normale SQL Server.

Il modo migliore per installare SQL CE 4.0 è usare la Web Platform Installer, il package manager ufficiale di Microsoft che con pochi semplici click vi permette di installare tutta una serie di tools (come le varie versioni Express di Visual Studio, oppure il supporto a ASP.NET MVC 3) e prodotti (CMS, blog engine, ecc.).

I pacchetti da cercare e installare sono due: Microsoft SQL Server Compact 4.0 (la piattaforma vera e propria) e Microsoft SQL Server Compact 4.0 Tools (i tools che da Visual Studio vi permettono di interagire con i database SQL CE 4.0 come se fossero dei normali database SQL Server: potrete creare tabelle, eseguire query, inserire dati, ecc.).

Per poter lavorare con SQL CE 4 utilizzando Entity Framework è necessario installare un’ulteriore libreria, disponibile sempre su NuGet: utilizzando la funzione Add Library Package Reference che è disponibile facendo doppio clic su un progetto in Visual Studio dobbiamo cercare e installare la libreria EntityFramework.SqlServerCompact.

Per cosa useremo queste tecnologie?

Entrambe le tecnologie verranno usate per il servizio, che farà da ponte tra client e server:

• Se ricordate, ad ogni device che si registra per ricevere le notifiche push viene assegnato un URL univoco, al quale dovremo inviare le notifiche sotto form di POST HTTP di un XML. Il servizio si occuperà, quando il device avrà creato il canale di ricezione delle notifiche, di riceverne l’URL e di memorizzarlo nel database SQL CE.
• L’applicazione server, quando dovrà inviare la notifica, si collegherà al servizio per richiedere l’elenco dei device con i rispettivi URL che identificano i canali.

In entrambi i casi, non andremo mai a salvare o leggere informazioni dal database “manualmente” scrivendo query SQL, ma useremo Entity Framework per fare tutte le operazioni.

In questo post abbiamo posto tutte le basi teoriche necessarie per iniziare con i lavoro: nel prossimo post inizieremo a sporcarci un po’ le mani, iniziando a definire il servizio.

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

Vi avevo già parlato in passato di questo fastidioso bug, che fa sì che il tentativo di aggiungere una Service Reference (ovvero una reference per poter utilizzare un servizio WCF, ad esempio, all’interno della vostra applicazione) ad un progetto Windows Phone porti ad un fallimento: apparentemente, il servizio viene aggiunto correttamente; se però si va ad analizzare la classe proxy generata dal tool SvcUtil (chiamata Reference.cs) si troverà una classe vuota.

Finalmente, grazie ad un utente su Twitter, sono riuscito a capire dove stia il problema: il punto utilizzato all’interno del nome del nostro progetto (ad esempio, PushNotification.Service). A quanto pare, per un bug di Visual Studio (legato specificatamente ai progetti Windows Phone, dato che con un progetto Web, WPF o Silverlight non succede) l’utilizzo di questo carattere crea problemi in fase di generazione della classe proxy, con i risultati che tutti sappiamo.

Il bug è abbastanza fastidioso per il sottoscritto, dato che tipicamente uso proprio il punto per identificare i progetti che fanno parte della stessa soluzione (ad esempio, PushNotifications.Service, PushNotifications.Client e così via). Putroppo al momento l’unica soluzione per aggirarlo (oltrea a quella ovvia di non utilizzare il punto nei nomi di progetto) è creare un nuovo progetto Windows Phone con un nome “corretto”, importare il servizio, dopodichè copiare i vari file generati da Visual Studio nell’altro progetto “reale” dove dovete utilizzare il servizio.

Vediamo brevemente come fare:

• Aggiungete una reference al servizio nel vostro progetto reale: cliccate con il tasto destro sul progetto, selezionate Add Service Reference, date un nome al servizio e conferma.
• Ora create il progetto “di appoggio” e importate lo stesso servizio, facendo attenzionare a dargli lo stesso nome che avete utilizzato nel progetto reale.
• Aprite entrambe le cartelle dei vostri progetti: quello reale e quello finto. In entrambe troverete una cartella chiamata Service Reference, con all’interno una sottocartella con lo stesso nome che avete dato al servizio. Copiatela dal progetto di appoggio a quella del progetto reale, sovrascrivendo tutti i file.
• Ora portatevi nella root del progetto di appoggio e copiate questa volta nel progetto reale il file ServiceReferences.ClientConfig (sempre sovrascrivendo quello già esistente), che contiene la configurazione del binding utilizzato per collegarsi al servizio WCF.
• Ora chiudete pure il progetto di appoggio e tornate a quello reale: in Solution Explorer cliccate sul servizio contenuto nella cartella Service References. Tra i pulsanti in alto a Solution Explorer cliccate sul secondo, etichettato Show all files. In questo modo potrete accedere a tutti i file generati da Visual Studio per permettervi di utilizzare il servizio.
• Aprite il file Reference.cs (gerarchicamente, vi verrà mostrato come figlio di Reference.svcmap) e cambiate il namespace della classe, in modo che coincida con quello del vostro progetto reale (ora conterrà infatti il namespace del vostro progetto di appoggio).

Salvate e ricompilate: se tutto è andato a buon fine, all’interno della vostra applicazione dovreste essere in grado di istanziare il client del servizio (tipicamente NomeDelServizioClient, ad esempio se il nome che avete dato al servizio è PushService la classe da istanziare si chiamerà PushServiceClient) e di utilizzarne i metodi esposti.

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

Vi segnalo che su Channel 9 sono disponibili sia per la visione in streaming che per il download tutte le sessioni tenute al MIX riguardo le novità su Mango. Se avete dimestichezza con l’inglese ve ne consiglio caldamente la visione, dato che rispetto a quanto annunciato nel keynote (ed evidenziato nel mio post di ieri) le sessioni vanno molto più in profondità, mostrando anche esempi di codice concreti. Se invece preferite aspettare contenuti in italiano o di poter mettere le mani sui tool di sviluppo prima di approfondire l’argomento, sappiate che ho pianificato l’uscita di una serie di post e tutorial tecnici che andranno a coprire tutte le varie novità di Mango. Indicativamente ho previsto di pubblicarli per quest’estate, tenendo conto del fatto che la prima beta dei tool non uscirà prima di Maggio. Perciò, continuate a seguirmi!

Ma veniamo all’elenco delle sessioni:

• Get Ready For Fast Application Switching in Windows Phone: http://channel9.msdn.com/Events/MIX/MIX11/DVC09
• What’s coming next to the Windows Phone platform: http://channel9.msdn.com/Events/MIX/MIX11/DVC14
• What’s New in the Windows Phone Developer Tools?: http://channel9.msdn.com/Events/MIX/MIX11/DVC17
• Multitasking in the Next Version of Windows Phone, Part I: http://channel9.msdn.com/Events/MIX/MIX11/DVC18
• Multitasking in the Next Version of Windows Phone, Part II: Using Background Agents: http://channel9.msdn.com/Events/MIX/MIX11/DVC11
• Windows Phone Architecture: Deep Dive http://channel9.msdn.com/Events/MIX/MIX11/DVC19
• Enhanced Push Notifications and Tiles for Windows Phone: http://channel9.msdn.com/Events/MIX/MIX11/DVC08
• New Data Access Features Coming to Windows Phone: http://channel9.msdn.com/Events/MIX/MIX11/DVC12
• Sensor and Camera Access in the Next Version of Windows Phone: http://channel9.msdn.com/Events/MIX/MIX11/DVC13
• What’s New for Windows Phone Development with Silverlight?: http://channel9.msdn.com/Events/MIX/MIX11/DVC15
• What’s New for Windows Phone Development with the XNA Framework?: http://channel9.msdn.com/Events/MIX/MIX11/DVC16

Marketplace privato e “beta”

Una novità decisamente sostanziosa che è emersa durante l’ultimo giorno di MIX e che non era stata menzionata al keynote è l’introduzione di un marketplace privato e di un marketplace beta, che vanno a coprire due scenari molto richiesti dagli sviluppatori da tutto il mondo, entrambi accumunati dalla necessità di distribuire le proprie applicazioni in forma privata: il primo per gli scenari aziendali, il secondo per il testing.

Il marketplace privato consentirà di pubblicare applicazioni che seguiranno le stesse identiche regole di quelle tradizionali: potranno essere gratuite o a pagamento, dovranno superare l’abituale processo di certificazione e potranno ricevere update. La differenza è che queste applicazioni non saranno visualizzate nel Marketplace, nè saranno ricercabili con il motore interno, ma saranno disponibili solo per le persone a cui daremo il link di accesso. Questo tipo di distribuzione è perfetto per aziende, community, ecc.

Il marketplace beta invece consentirà di distribuire l’applicazione a un numero massimo di 100 persone che sceglieremo come tester: in questo caso, l’applicazione non dovrà superare alcun processo di certificazione, proprio perchè non si tratta di una distribuzione pubblica. L’applicazione sarà attiva per 90 giorni, dopodichè cesserà di funzionare; non sarà possibile inoltre effettuare submit di eventuali update. L’intero processo di distribuzione sarà basato sul Live Id: ogni beta tester dovrà possederne uno, che lo sviluppatore aggiungerà alla lista di utenti abilitati.

Certo, la strada per rendere Windows Phone 7 un device pienamente compatibile con le esigenze aziendali è ancora lunga, però questo è sicuramente un passo importante: queste nuove forme di distribuzione, unite alle nuove possibilità offerte dai tool (penso alle socket, che possono risultare molto utili in molti scenari business), apriranno sicuramente le porte ad un gran numero di applicazioni per il mondo delle aziende.

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

E poi non ditemi che non vi avevo avvertito: è valsa la pena di guardare il keynote del MIX o sbaglio?

Come previsto, Windows Phone è stato e sarà tra i protagonisti di questo MIX, dato che Microsoft ha scelto questo evento per annunciare pubblicamente tutte le novità che Mango introdurrà per gli sviluppatori: e che novità! Nuove API, nuovi scenari, un nuovo emulatore: la carne al fuoco è davvero tanta! Vediamole in dettaglio.

Miglioramenti al marketplace e alla gestione delle applicazioni

In Mango sarà possibile gestire meglio le applicazioni che abbiamo installato, tramite l’implementazione di una jump list (che, analogamente a quanto avviene nella rubrica, ci permettà di saltare direttamente alle applicazioni in base alla iniziale del nome) e di un motore di ricerca.

In più, la ricerca di informazioni sul marketplace sarà organizzata meglio, grazie ad un utilizzo più intensivo del controllo pivot: lanciando una ricerca, con un pivot sarà possibile filtrare i risultati per tipologia (applicazioni, musica, ecc.). Lo stesso tipo di UI verrà utilizzato nella pagina di dettaglio di un’applicazione: le recensioni, gli screenshot e le app collegate verranno mostrate in item separati di un pivot.

Suonerie

Mango supporterà le tanto attese suonerie personalizzate, offrendo in più la possibilità agli sviluppatori di salvare suonerie direttamente dalle loro applicazioni nel telefono. Si tratta di una feature molto interessante, che offre un grado di personalizzazione superiore anche a quello offerto da piattaforme concorrenti (su iPhone la sincronizzazione delle suonerie deve passare per forza da iTunes, impedendo ad applicazioni di terze parti di integrarle e salvarle nel telefono).

Integrazione con le ricerche di Bing

L’integrazione con Bing è stata migliorata ulteriormente: ora sarà possibile ricercare anche delle categorie specifiche (come cinema, ristoranti, ecc.) e “agganciare” le nostre applicazioni ai risultati della ricerca. L’esempio mostrato durante il keynote illustra bene lo scenario: cercando la parola “movies” Joe Belfiore è stato in grado di scoprire i film programmati nei cinema vicino a lui e di visualizzare alcune informazioni base (come durata, genere, attori, ecc.). Insieme ai risultati, però, era disponibile anche una sezione chiamata Extras, nella quale venivano visualizzate le applicazioni in grado di gestire quel tipo di informazione. Ecco perciò che cliccando sull’icona di IMDB Joe Belfiore ha lanciato l’applicazione già posizionata sul dettaglio del film scelto.

Multitasking

Il multitasking, si sapeva già, è una delle feature che faranno la parte del leone in Mango: già al Mobile World Congress ci era stato dato un assaggio della funzionalità di Fast App Switching, che permette di passare da una applicazione all’altra in maniera istantanea, al contrario di quanto avviene oggi a causa del tombstoning.

Ora finalmente sappiamo qualcosa di più su come funziona questo Fast App Switching: il processo non è più terminato, ma rimane residente in memoria. Questo significa che le applicazioni, una volta riaperte (tramite il tasto Back o con il nuovo task manager) partiranno istantaneamente, dato che Windows Phone non deve più preoccuparsi di reinizializzare l’applicazione e ricaricare dal tombstone i dati.

Multitasking non significa però solamente il passaggio veloce da un’applicazione all’altro, ma anche la possibilità per un app di eseguire delle operazioni in background: ecco perciò che Microsoft ha implementato dei servizi che permettono di eseguire dei compiti ben specifici (come la riproduzione di audio o l’upload / download di dati) anche quando la nostra applicazione è chiusa. In più, avremo la possibilità di impostare dei reminders (esattamente come quelli del calendario o della sveglia) che verranno mostrati anche quando l’utente non sta usando la nostra app.

Ma il bello deve ancora arrivare: Microsoft ha introdotto infatti gli Agents, ovvero dei servizi che possono accompagnare la nostra applicazione e che sono in grado di effettuare operazioni in background.  Il discorso agents in realtà è molto complesso: tante sono le cose che si possono fare e ci sono alcune limitazioni da tenere a mente (introdotte per evitare consumi impropri di risorse e batteria). Ci torneremo sopra  sicuramente in maniera più approfondita in futuro!

Nuove modalità di accesso ai dati del telefono

Anche in questo caso Microsoft ha dato grande ascolto ai feedback degli sviluppatori, aumentando le possibilità che hanno le nostre applicazioni di interagire con le applicazioni native e con i dati presenti nel telefono. Sarà possibile accedere alla rubrica telefonica e al calendario in maniera programmatica, senza più passare da un launcher: potremo perciò ad esempio recuperare i contatti della rubrica o gli appuntamenti del calendario direttamente da codice ed effettuare query di ricerca complesse.

In più, avremo a disposizione una serie di nuovi launchers & choosers, per selezionare ad esempio l’indirizzo di un contatto, salvare appuntamenti nel calendario o visualizzare un luogo in Bing Maps.

Altra novità tanto attesa è il pieno accesso allo stream della fotocamera, al contrario di quanto avviene oggi, dove è possibile solamente importare le foto scattate con essa grazie ad un chooser. Questa nuova feature permetterà di realizzare tanti tipi di applicazioni (come quelle basate su realtà aumentata) ad oggi non realizzabili.

Sensori

Ci sarà una nuova API per gestire in maniera più intuitiva rispetto a quanto avviene oggi la posizione del telefono nello spazio e i movimenti dell’accelerometro. Tale API sarà in grado, inoltre, di interfacciarsi con altri sensori come la bussola e il giroscopio (non presente nell’attuale generazione di device), fornendo una precisione maggiore, utile soprattutto nello sviluppo dei giochi.

Database

Altra caratteristica tanto desiderata dagli sviluppatori di mezzo mondo, il supporto ai database, è finalmente una realtà, grazie al supporto a SQL CE: sarà possibile creare e utilizzare nella nostra applicazione database disconnessi memorizzati in un singolo file. Su questa novità c’è poco da dire: si tratta di un database SQL  in tutto e per tutto, con il quale potremo utilizzare lo stesso approccio a oggetti a cui siamo abituati grazie all’uso di LINQ.

Socket

Altra feature molto richiesta e che apre le porte a tantissimi nuovi scenari e tipi di applicazioni (la parola VoIP vi dice qualcosa?): il supporto alle socket. I primi “effetti” di questo annuncio si sono già visti: al keynote è stato presentato Skype per Windows Phone, sicuramente una delle applicazioni più attese e richieste dagli utenti.

Notifiche push

Grandi novità anche per le notifiche push: la più interessante è sicuramente la possibilità per le applicazioni di creare più tile. Questa feature va a nozze con l’altra novità (disponibile sia per le toast che per le tile), ovvero la possibilità di portare un utente dalla notifica ad una pagina specifica dell’applicazione. In questo modo potremo creare diverse tile, ognuna delle quali sarà in grado di portare l’utente ad una pagina specifica della nostra applicazione. Gli esempi che si possono fare sono tanti: pensiamo ad una applicazione meteo, che può consentire di pinnare in home page le previsioni relative a più città da noi scelte. Oppure un’applicazione legata ad un quotidiano, che può aggiungere una tile per ognuno dei canali di notizie offerti (prima pagina, economia, ecc.).

In più, in combinazione con i background agents, sarà possibile anche aggiornare le tile della nostra applicazione localmente, senza la necessità di avere una applicazione server che invii le notifiche.

Interoperabilità Silverlight / XNA

Questa feature sarà molto apprezzata da chi si occupa di sviluppo giochi: sarà possibile ospitare all’interno di una pagina Silverlight una parte che verrà renderizzata in XNA. Questo consentirà di combinare il meglio dei due mondi, creando ad esempio un gioco in grado però di sfruttare la navigazione a pagine offerta da Silverlight. Oppure ancora di utilizzare controlli Silverlight (pulsanti, radio button, ecc.) all’interno di un gioco XNA.

Nuova versione dei tool di sviluppo

Mango porterà con sè un nuovo emulatore, con tutta una serie di feature che saranno sicuramente apprezzate:

• Possibilità di simulare le gestures multitouch senza la necessità di possedere per forza un monitor multitouch.
• Integrazione di un tool che permetterà di simulare con il mouse l’accelerometro e i movimenti del device sui vari assi x, y e z.
• Integrazione di un tool, simile a GPS Emulator, che ci permetterà di testare i servizi di geolocalizzazione.
• Integrazione di un tool di profiling, per analizzare le performance della nostra applicazione.

In conclusione

Che dire? Di carne al fuoco come vedete ce n’è tantissima ed è difficile trattenere l’entusiasmo: grazie alle novità introdotte si apre un numero di scenari pressochè illimitato, raggiungendo (e in alcuni casi anche superando) le possibilità offerte oggi agli sviluppatori iPhone e Android. Tutto questo, combinato alle novità che sicuramente Mango porterà dal punto di vista utente, trasformano Windows Phone 7 da una piattaforma molto promettente ma ancora acerba in un pezzo da novanta, in grado di giocare alla pari con i principali competitor sul mercato.

Ma parliamo di cose concrete: quando sarà possibile mettere mano a tutto questo ben di Dio? Microsoft ha annunciato che per Maggio sarà disponibile la prima beta pubblica dei tool di sviluppo, con i quali si potrà iniziare a fare esperimenti grazie all’emulatore. Il percorso che si prospetta è più o meno lo stesso dell’anno scorso: da qui alla fine dell’anno ci saranno diverse release intermedie e, in attesa del rilascio finale (e quindi della possibilità di testare le applicazioni sui device veri e propri), si potranno fare esperimenti grazie all’emulatore e grazie ai device di prova che sicuramente Microsoft metterà a disposizione agli sviluppatori nei vari eventi e laboratori.

Aspettatevi, dopo la release pubblica dei tool, una serie di post più tecnici, in cui andremo a vedere esempi di codice concreti relativi alle novità che abbiamo visto in questo post. Se nel frattempo volete iniziare ad approfondire gli argomenti, tenete d’occhio il calendario delle sessioni di MIX: tante dedicate a Windows Phone sono di approfondimento su questi temi e a breve saranno disponibili in streaming. Infine, se volete è già a disposizione la registrazione del keynote di ieri dove sono state presentate tutte le novità oggetto di questo post.

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

Mindscape, software house già conosciuta tra gli sviluppatori per diverse suite di controlli per altre tecnologie .NET, ha da poco rilasciato una nuova suite dedicata al mondo Windows Phone, che potrebbe risultare molto utile a chi si occupa di sviluppare applicazioni business.

I controlli di Mindscape, infatti, sono focalizzati soprattutto sulla creazione di grafici di vario tipo all’interno delle nostre applicazioni Windows Phone 7: a torta, a barre, istogrammi, ecc. La suite in realtà comprende anche altri controlli, che però abbiamo già visto in altre librerie, come il TimePicker e il DatePicker: la parte del leone la fanno perciò proprio i grafici.

La suite sarebbe a pagamento, con un costo base di 299 €: Mindscape, in occasione del lancio del prodotto, ha deciso di regalare un numero limitato di licenze. Fino a qualche tempo fa, bastava registrarsi sul sito ufficiale compilando l’apposito form e si riceveva via mail un codice sconto da utilizzare in fase d’acquisto di una licenza personale. Purtroppo però ora queste licenze gratuite sono esaurite.

Niente paura! Se siete interessati a questa suite ma non avete avuto modo di usufruire dell’offerta, vi farà piacere sapere che, grazie ad una partnership con Mindscape, ho a disposizione un codice che vi darà la possibilità di ottenere gratuitamente una licenza!

Il codice è valido per circa un centinaio di attivazioni e sarà disponibile fino a fine Aprile: il suo utilizzo è ad esaurimento, perciò chi prima arriva meglio alloggia Il funzionamento dell’offerta è molto semplice; vi basta collegarvi al http://www.mindscapehq.com/products/phone-elements e procedere con l’acquisto del pacchetto da 1 Developer da 299 $. Durante la fase di acquisto, ad un certo punto avrete la possibilità di inserire un discount code. Il codice da inserire è:

WP7-PAGANI

Noterebe subito che il totale dell’acquisto passerà da 299 $ a 0 $: vi basta perciò terminare la procedura per ricevere la vostra licenza gratuita!

La licenza comprende 1 anno di aggiornamenti: questo significa che tutti gli update della suite che verranno rilasciati da qui a Marzo dell’anno prossimo saranno comunque gratuiti. Che aspettate? Correte a scaricarli! Un grazie a Mindspace per questa opportunità!.

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