Ogni applicazione per Windows Phone 7 è corredata dal file WMAppManifest.xml, contenuto nel folder Properties della solution di Visual Studio 2010. Questo file è un normalissimo file XML, che contiene un po’ di informazioni inerenti la nostra applicazione.

Il nodo IconPath (all’incirca a riga 5) contiene il path dell’icona piccola della nostra applicazione – l’icona che viene utilizzata nel menù di Windows Phone 7.

Il nodo BackgroundImageURI (suppergiù riga 18) contiene il path dell’icona grande della nostra applicazione – l’icona che viene utilizzata nel menù Start. Questa icona viene utilizzata solamente nel momento in cui l’utente decide di voler metter la nostra applicazione sulla schermata principale di Windows Phone 7 – il menù Start appunto.

Il nodo App (riga 4) contiene diversi informazioni utili:

• attributo Title (esempio: “Bank Finder”)
• attributo Author (esempio: “Damiani Liborio Igor”)
• attributo Description (esempio: “bla bla bla”, e non ho capito dove viene mostrato)
• attributo Publisher (esempio: “VivendoByte.net”)
• attributo Genre (esempio: “apps.normal”)

Quest’ultimo riveste un’importanza particolare quando sviluppate giochi – sia Silverlight che XNA. Secondo il documento delle specifiche Microsoft, i giochi devono apparire all’interno dell’hub XBOX Live. Se lasciate “apps.normal” – che è il valore di default, questo non accade.

E’ necessario impostare l’attributo Genre a “apps.games”.

Ho preferito dare un po’ di enfasi, perchè se googlate fate un po’ di difficoltà a trovare questa cosa. Troverete post che dicono di mettere “app.game”, “App.Games”, insomma, una variante infinita di maiuscole/minuscole/plulari/singolari, mentre l’icona della vostra applicazione rimane inchiodata lì dov’è. Fidatevi, mettete “apps.games” e siete a posto.

L’ultimo appunto riguarda il tag Capabilities: all’interno di questo nodo dovete specificare quali funzionalità del telefono WP7 sono richieste dalla vostra applicazione. Quindi, aggiungete un nodo Capability con Name impostato a dovere. Avete bisogno del GPS? Aggiungete ID_CAP_LOCATION. Avete bisogno del microfono? Aggiungete ID_CAP_MICROPHONE. Accelerometro? ID_CAP_SENSORS. E così via. Maggiori informazioni direttamente su MSDN a questo indirizzo.

Questa cosa è importante, perchè una volta sul Marketplace, e prima di acquistare/scaricare l’applicazione, l’utente dovrà essere informato su cosa è richiesto dall’app per funzionare (c’è traffico dati per la rete? mi accende il gps e mi localizza? etc. etc.), e questa cosa – presumo – arriva direttamente dai metadati contenuti nel file WMAppManifest.xml.

Send to Kindle

Allora, questo è un problema che mi attanaglia. Considerate la seguente schermata:

E’ una applicazione Silverlight brutta e orribile, con 4 pulsanti. Non c’è uso di M-V-VM, ma il caro e buon vecchio code-behind. Tutti questi pulsanti effettuano il download di un normalissimo file pdf raggiungibile via http.

Cliccando sul pulsante PDF con code behind il codice eseguito è un semplice:

private void button1_Click(object sender, RoutedEventArgs e)
{
    HtmlPage.Window.Navigate(new Uri(URL, UriKind.Absolute));
}

Cliccando sul pulsante PDF con timer il codice è il seguente:

private void button2_Click(object sender, RoutedEventArgs e)
{
    DispatcherTimer timer = new DispatcherTimer();
    timer.Interval = TimeSpan.FromSeconds(3);
    timer.Tick += (s2, e2) =>
        {
            timer.Stop();
            HtmlPage.Window.Navigate(new Uri(URL, UriKind.Absolute));
        };
    timer.Start();
}

Cliccando sul terzo pulsante PDF con javascript il codice è il seguente:

private void button3_Click(object sender, RoutedEventArgs e)
{
    object[] param = new object[1];
    param[0] = URL;
    System.Windows.Browser.HtmlPage.Window.Invoke("openPDF", param);
}

Con javascript, viene invocata una funzione ‘openDF’ definita nella pagina .aspx che hosta il plug-in di Silverlight.

Comunque sia, in tutti questi casi elencati sopra, il download del file PDF da parte di Internet Explorer viene inizialmente bloccato per motivi di sicurezza. IE fa apparire una toolbar gialla:

Per effettuare il download, dovete dare l’autorizzazione e ripetere l’operazione. Nella mia applicazione scema di oggi non ci sono troppi problemi , ma in un’applicazione reale viene effettuato il refresh della pagina .aspx, e quindi l’utente deve rifare tutto daccapo.

L’unica soluzione che ho trovato è stata quella di usare un HyperlinkButton, “templizzato” in modo tale che sulla pagina della nostra applicazione possa apparire (quasi) come un normale Button. Cliccando sul bottone PDF con HyperlinkButton IE non blocca un bel nulla, e fa apparire il classico dialog Apri/Salva.

Ora, però, fate un passettino in avanti: supponiamo che l’url venga generato dinamicamente. Voi cliccate, richiamato un qualcosa-lato-server che genera il PDF, e restituisce al client l’indirizzo http completo. Il controllo HyperlinkButton diventa (quasi) inutile: nello XAML non impostate la proprietà NavigateUri – perchè non la conoscete – voi cliccate ed ovviamente non succede un bel nulla. Nemmeno l’evento Click serve a qualcosa, perchè semplicemente non viene invocato.

E quindi? Se avete consigli, aiuti o qualche dritta, sono tutt’orecchi.

Send to Kindle

Qualche minuto fa ho registrato un piccolo video della mia applicazione per Windows Phone 7, “La Prova del Cuoco”, pubblicato ovviamente su YouTube.

E’ una piccola applicazione, sviluppata in un paio di serate, che è stata implementata con:

1. emulatore Windows Phone 7 (all’inizio) ed un telefono Windows Phone 7 (alla fine)
2. Visual Studio 2010 Professional + WP7 Developer Tools in RTM
3. Un servizio WCF hostato sul mio hosting che viene consumato sul device e che mi dice giorno per giorno chi ha vinto
4. Un backend sviluppato in 15 minuti con ASP.Net Dynamic Data Entities Web Application
5. Il backend è stato tradotto in italiano per permettere a chi deve usarlo (in breve: mio padre) di inserire velocemente i dati, ogni giorno (in breve: l’ho schiavizzato )

Send to Kindle

Questa sera voglio parlarvi di un “dietro le quinte” di Entity Framework, ovvero una particolare situazione che mi è capitata durante le settimane scorse. Per la lettura di questo post assumo che sappiate:

• cosa sia un database
• cosa sia Entity Framework
• cosa sia un’applicazione Silverlight o giù di lì
• cosa siano i RIA Services

Dunque, cerco di arrivare al sodo in poche linee. Supponiamo di aver disegnato il seguente db:

Questa immagine arriva così com’è dal database diagram di SQL Server Management Studio. Forse è un database di cui avevo già parlato in passato in altri post. Abbiamo una tabella “Teams” contenente un po’ di squadre di calcio, ed abbiamo una tabella “Players” che mantiene l’elenco dei giocatori squadra per squadra. Il campo “IdTeam” della tabella “Players” serve proprio per mantenere questa relazione.

Ora, immaginiamo due scenari perseguibili:

• la tabella “Players” contiene solo giocatori che effettivamente appartengono ad una squadra
• la tabella “Players” contiene anche giocatori che NON appartengono ad alcuna squadra

Voi come realizzereste questa cosa? Il modo più semplice è quello di sfruttare in modo opportuno il campo “IdTeam” citato prima. Se “IdTeam” contiene NULL, quel record contiene un giocatore libero (non appartenente a nessuno), altrimenti contiene un ID che fa riferimento ad un Team esistente. Dal punto di vista del database, non ci sono particolari accrocchi da fare: è sufficiente impostare NULL / NOT NULL sul campo “IdTeam” ed il gioco è fatto (ed eventualmente rimuovere il valore predefinito dal campo stesso).

Come si comporta invece Entity Framework in questi due scenari?
Beh, devo dire che si comporta piuttosto bene. Ecco come appare il designer in entrambi i casi:

	In questo primo caso, la relazione che lega le due entity è uno a molti. Se nel designer selezioniamo IdTeam, vediamo che la proprietà Nullable è False.
	In questo secondo caso, la relazione è 0..1. Se nel designer selezioniamo IdTeam, vediamo che la proprietà Nullable è (None).

Una piccola precisazione. Ci sono almeno due piccole imperfezioni nella funzionalità di Update model from Database del designer di EF:

1. non si accorge se cancellate un campo da una tabella (per adesso non ci riguarda)
2. non si accorge se un certo campo diventa NULL / NOT NULL (questo invece ci riguarda eccome!)

Morale: se andate nel Management Studio e cambiate la proprietà Allow Nulls del campo “IdTeam” della tabella “Players”, e poi andate in VS2010 per refreshare il data model di EF, questi rimarrà invariato. Avete due possibilità: o cancellate la tabella e la riaggiungete (fattibile se le cose sono davvero semplici), oppure cambiate semplicemente la proprietà Nullable del campo (quest’ultima strada non l’ho provata).

Comunque sia, alla fine vi ritrovate il data model che rispecchia esattamente la struttura del vostro database.

E con le classi POCO, come siamo messi?
Da quando ho cominciato a lavorare con Silverlight 4 & EF4, ho subito utilizzato la possibilità di persistere oggetti generati tramite il template di classi POCO. Come si comporta questo template nei due casi esaminati sopra? Beh, anche qui la cosa è abbastanza intelligente!

Se il campo “IdTeam” non ammette NULL, allora è la proprietà è un semplice int.
Se il campo “IdTeam” ammette NULL, allora la proprietà IdTeam della nostra classe è una Nullable<int>, ed appare come segue:

public virtual Nullable<int> IdTeam

{

    get { return _idTeam; }

    set

    {

        try

        {

            _settingFK = true;

            if (_idTeam != value)

            {

                if (Team != null && Team.Id != value)

                {

                    Team = null;

                }

                _idTeam = value;

            }

        }

        finally

        {

            _settingFK = false;

        }

    }

}

private Nullable<int> _idTeam;

Il codice qui sopra proviene dalla definizione della classe Player.

Caricare dati attraverso i RIA Services

Altro balzo in avanti. Supponiamo adesso di aver chiuso tutto il giro, e di aver implementato una piccola applicazione Silverlight che da qualche parte mostri una ListBox con l’elenco delle squadre: quando l’utente clicca su una squadra, viene eseguito un command che carica i giocatori di quella squadra, e li mostra in un’altra ListBox. Ora – non ci interessa sapere che il tutto è stato fatto con M-V-VM e tutto il resto.

Quello che conta è che da qualche parte il nostro codice sarà una cosa tipo questa:

void loadPlayersCommandExecute(object value)

{

    if (value == null) return;

    Team t = value as Team;

    TeamsDomainContext dc = new TeamsDomainContext();

    var query = dc.GetPlayersQuery().Where(pl => pl.IdTeam.Equals(t.Id));

    dc.Load<Player>(query, callbackPlayers, null);

}

Questo è l’execute del command che carica i giocatori. Arriva in input un object, che è il SelectedItem della ListBox delle squadre.

Domanda per voi: se abbiamo impostato che “IdTeam” ammette NULL (che alla fin fine è lo scenario che ho applicato), questa riga di codice a runtime funziona? Per compilare compila, ma in esecuzione si schianta. E si schianta sull’ultima linea, al momento della chiamata a Load().

Perchè? Notare la clausola Where: la proprietà IdTeam di pl è Nullable<int>, mentre t.Id ritorna int.

In questo caso ho chiamato il metodo Equals su un reference type (Nullable<int>, o int? che dir si voglia), passando come parametro un value type (int). E tutto ciò non va affatto bene. L’exception contiene il seguente messaggio:

Expression of type ‘System.Int32’ cannot be used for parameter of type ‘System.Object’ of method ‘Boolean Equals(System.Object)’

Come risolvere la cosa. Basta sostituire la chiamata a Equals con il più banale ==. Ecco come diventa la query:

var query = dc.GetPlayersQuery().Where(pl => (pl.IdTeam == t.Id));

Ed il gioco è fatto!

Send to Kindle

C’è molto rumore attorno a Windows Phone 7, il sistema operativo che Microsoft sta lustrando e sta promuovendo in lungo e in largo per – credo – il prossimo Natale. Dal punto di vista di noi developer, le cose sono molto interessanti, perchè cellulari con su WP7 possono essere tranquillamente programmati usando il nostro amato .NET Framework.

Scendendo più nel dettaglio, è sufficiente saper sviluppare applicazioni con Silverlight ed il gioco è fatto. Certo, ci sono dei piccoli dettagli da prendere in considerazione, perchè la nostra futura app non gira dentro un browser. Le applicazioni Windows Phone 7 sono applicazioni Silverlight 3 che girano in modalità out-of-browser. Poi bisogna pensare al fatto che – trattandosi di un device mobile – non ci sono tastiere, nè mouse, ma si interagisce con lo screen touch e così via. Le solite cose che per chi ho lavorato con dispositivi mobile non sono una novità.

Se volete scendere ancora più nel dettaglio, invece, vi consiglio di leggere questo post di Corrado, che evidenzia tra le altre cose un aspetto piuttosto importante di WP7: ovvero, questo sistema operativo non è multi-tasking.

Cosa comporta questo per un utente normale? Significa che può aprire una sola applicazione alla volta. Se apriamo l’applicazione “Pippo”, poi premiamo Home per tornare alla schermata iniziale, la nostra applicazione viene chiusa a tutti gli effetti (pare che tombstoned sia il termine ufficiale di Microsoft). Se l’utente riclicca sull’icona della nostra applicazione, dobbiamo fargli credere che in realtà non si sia mai chiusa, ripristinando lo stato esattamente com’era. lo spiega bene Corrado nel post linkato sopra.

Mi fa un po’ storcere il naso questo meccanismo. Ecco un po’ di punti deboli:

1. bisogna prestare attenzione ad un eventuale splash screen della nostra applicazione: se è davvero un avvio a tutti gli effetti, questi deve apparire. Se l’avvio avviene dopo un tombstone, allora questi NON deve apparire
2. impossibilità di scrivere applicazioni che girano davvero in background. Ad esempio: su Symbian posso tranquillamente lanciare l’esecuzione di un GPS tracking, che se ne sta lì buono buono a tracciare la posizione e a scrivere il suo file di log, e contemporanemente posso ricevere telefonate, navigare, scrivere un sms: tutto quello che il cellulare può fare
3. questa decisione è stata presa per risparmiare batteria e limitare i consumi, per salvaguardare il punto di vista dell’utente. Avrei preferito – però – che dicessero che un’app in background può usare solo l’1% del processore, oppure solo 16Mb di RAM, oppure non può accedere allo storage SD, ad esempio. Così si possono scrivere un sacco di belle applicazioni, ma se ne taglia comunque una bella fetta.

Anche durante l’evento DotNetLombardia della settimana scorsa è saltata fuori questa questione. Si ragionava che evidentemente sarà un po’ più scomodo usare Tom Tom Navigator su WP7, perchè se mentre sto guidando arriva una telefonata o un sms, beh, ecco, insomma, Tom Tom si chiude. Certo, si può riaprire, ma non è così rapido come può sembrare. Almeno credo.

Forse però parlo da utente skillato. Magari il target per WP7 studiato da Microsoft non è così esperto. Però vi dico solo una cosa: mio padre, che ha anche lui un Nokia piuttosto evoluto, ha imparato a riconoscere quando un’app è in esecuzione/aperta, perchè accanto alla sua icona ne appare un’altra … una specie di “ingranaggio” (che però dipende dal tema in uso sul cellulare), che indica appunto che quell’applicazione sta girando in background.

Vedremo, io non ho mica la verità in mano!

Send to Kindle