Roberto Freato - Windows Phone

111213 – PhoneCamp @UNICAL

Come già ripreso in questo post da RoB, martedì si è svolto a Cosenza (in particolare ad Arcavacata di Rende, in università) un evento gratuito in collaborazione con Microsoft e Microsoft Student Partners.

Data la numerosa affluenza e le richieste di follow-up, ecco il materiale presentato durante la giornata:

Sorgenti delle demo

Slides dei contenuti

Un grazie ai ragazzi di Unical per l’egregio supporto all’evento.

[WP7 Mango] DotNetLombardia WP Workshop – It’s Mango Time

DotNetLombardia ha organizzato un evento per chiunque sia interessato allo sviluppo di applicazioni per Windows Phone: l’evento, chiamato Windows Phone Workshop One, si terrà il 23 Giugno in sede Microsoft e sarà una giornata di approfondimento su tutte le novità per gli sviluppatori introdotte in Mango.

L’idea è quella di realizzare un’applicazione completa dall’inizio alla fine (stiamo ancora fissando le idee su quale sarà il risultato finale, vi terrò aggiornati): partendo dallo studio di User Experience e terminando con il deploy sul Marketplace, ogni speaker presenterà una delle nuove feature di Mango e mostrerà concretamente come implementarla all’interno dell’applicazione. Poche slide e molto codice insomma!

L’agenda non è ancora definitiva al 100%, ma potete farvi un’idea degli argomenti che verranno trattati: SQL CE, multitasking e background agents, integrazione con Azure, ecc.

Come da tradizione per ogni evento community che si rispetti, il workshop è completamente gratuito e aperto a tutti. Cosa aspettate a iscrivervi? Vi lascio con il link al sito ufficiale dell’evento, che verrà aggiornato nel tempo man mano che nuove informazioni saranno disponibili:

http://wp7one.dotnetlombardia.org/

Goodbye WM 6.x… – Stop alle applicazioni

Sebbene già da un anno fosse chiaro che Windows Mobile sarebbe morto, questa agonia controllata sta per giungere al capolinea. Un pò di storia:

• Summer 2009: Microsoft lancia il Marketplace e motiva gli sviluppatori mobile a sviluppare le app, ad incrementare il numero di applicazioni e ad entrare nella strategia di aggressione delle masse del mondo smartphone.
• 6 Ottobre 2009: il Marketplace apre con poche centinaia di prime applicazioni.
• Mesi a seguire: numerose mail (che ho conservato) da parte del team del marketplace ci spronano a sviluppare nuove apps per fare numero, noi seguiamo il trend e le applicazioni crescono.

Poi, da quando Belfiore ha presentato Windows Phone, il resto è storia. Come ho già detto molte volte, si è tolto il supporto completo a Windows Mobile come se, semplicemente, non esistesse. Così, in un bagliore di comportamento Apple-style (del tipo, “sorry, nuovo modello”) molti degli sviluppatori WM hanno tristemente e difficilmente migrato a Windows Phone:

• Perchè tristemente? perchè erano abituati ad avere a che fare con un dispositivo fully-customizable e si sono trovati in mano una API talmente ristretta che la cosa più avanzata che avrebbero potuto fare sarebbe stata una notifica push.
• Perchè difficilmente? perchè silverlight per uno sviluppatore Windows Forms ha una curva di apprendimento notevole.

Ma moltissimi, io compreso, non si sono abbattuti e si sono subito cambiati il cappello, pensando a quando avrebbero staccato definitivamente la spina a Windows Mobile. Il momento è arrivato, il 16 Maggio ci è stato detto di chiudere baracca e burattini poichè il 15 Luglio (quasi a due anni dai primi annunci sul Marketplace) si toglierà la possibilità di postare nuove applicazioni o modificare quelle esistenti: sostanzialmente si metterà offline la parte di applicativo che gestisce le submission di WM6.

Non che questa comunicazione sia una novità inaspettata tantomeno una provocazione: penso che Microsoft abbia utilizzato questa esperienza per fare un pò di pratica su un mondo nuovo. Sebbene infatti da anni sappia come coccolare e come rapportarsi verso la community degli sviluppatori, ora spero imparerà dai propri errori a delegare con migliaia di sviluppatori i cui interessi verso la novità sono frenati da lampanti interessi economici (derivanti dalla vendita di apps). Uno sviluppatore Microsoft infatti, sebbene con il cappello di solo sviluppatore sia sempre stato enormemente felice rispetto al grado di innovazione dell’azienda, con il cappello di sviluppatore WM6.x, avrebbe preferito potersi accomodare un pò più comodamente sul mercato prima di esserne escluso repentinamente.

Supporto di WM6.x in VS 2010 – le ultime parole famose

Niente di eccezionale da dire in questo post tranne che, quando prima ho fatto un pò di piazza pulita tra vecchio materiale e webcast, ho trovato questa slides (in un webcast di Bill Lodin) che fa un pò sorridere:

Soprattutto l’ultimo punto… Ovviamente con gli occhi di oggi aveva voluto dire "che per lo sviluppo mobile si contnuerà ad usare VS”. All’epoca il senso sembrava veramente tutt’altro.

The Why and How’s of Windows Phone 7 @MWC

Mercoledì sono stato al Mobile World Congress 2011 di Barcellona, per seguire il team di Windows Phone 7 che avrebbe presentato, oltre a cose già note della piattaforma, qualche spunto di riflessione in più, anche in seguito all’emergente novità della futura (e ormai corrente) alleanza con Nokia. La giornata si articolava così:

La giornata è iniziata un pò in ritardo rispetto al previsto anche se Larry e soprattutto Bryan hanno saputo ripristinare egregiamente l’agenda originale. Ha parlato anche Rich Green (il CTO di Nokia) in un format che prevedeva le domande da parte di Microsoft. Green ottimo relatore, anche se non ha dipanato i dubbi dei Nokia developer che, come i poveri WM6.x developer ora si trovano in una situazione anche peggiore. Lui garantisce un passaggio indolore (forse con la differenziazione per fascia dell’OS installato); i developer chiedono supporto.

Le domande migliori le hanno fatte in panel dopo pranzo anche se come divulgatore ho preferito Larry Lieberman che indubbiamente ha affrontato la sala (assolutamente un-aware di Windows Phone 7 come lo possiamo essere noi coinvolti) nel modo migliore. Alcuni si aspettavano che gli venisse regalato un Windows Phone come aveva fatto Nokia il giorno prima al suo evento (regalando un terminale ad OGNI persona registrata, pazzesco ).

Joe Marini non mi è piaciuto: è stata sostazialmente una sessione di IE9 e HTML5 giustificandola come IE9 su Windows Phone (poi magari mi sbaglierò, ma mi sa che ne passerà ancora un bel pò di acqua sotto i ponti prima di vedere qualcosa del genere).

La piattaforma piace molto agli sviluppatori (per la semplicità di sviluppo), tantissimo ai grafici (per via dello XAML) e un pò meno agli utilizzatori. Il motivo potrebbe essere dato dal fatto che si sta creando qualche movimento psicologico che, nato dal confronto iPhone-WP7, porta la gente a non convincersi delle potenzialità di WP7: occhio, “potenzialità”; perchè in quanto a funzionalità è sotto gli occhi di tutti che bisogna lavorare ancora molto. Diciamo che l’approccio “Buy to develop onto” è decisamente più motivante dell’approccio “Buy to use” al momento. Le opinioni delle persone poco al corrente di WP7 che ho sentito l’altro ieri a Barcellona erano molto allineate: gli sviluppatori erano abbastanza entusiasti (anche se lamentavano la piccola footprint delle azioni che si possono svolgere sul dispositivo tramite API); i non sviluppatori erano un pò scettici sul futuro del dispositivo (non tanto quanto adoption, vista la recente partnership con Nokia, bensì sugli aggiornamenti del software e sulla crescità delle funzionalità di base). Molti hanno anche posto domande ai relatori, relativamente alla possibilità di “uscire” dall’isolamento delle applicazioni Silverlight o di scrivere addirittura codice non gestito.

Ecco forse a domande del genere avrei preferito “non si può fare e non si potrà mai fare”, piuttosto che “ora non è in programma”. Capisco che tutto può succedere, ma scrivere codice unmanaged è assolutamente contro tutto ciò che abbiamoimparato essere il punto forte di WP7; ogni tanto bisogna saper dire no.

Smartphone Day 01 – il giorno dopo

Diciamo “il giorno lavorativo dopo”, visto che il primo Smartphone Day, organizzato da Rosalba Fiore, è stato venerdì scorso. Ha riscosso un buon successo e già si parla di una eventuale replica in luogo che non so se posso divulgare. Per i presenti e non allego al post anche il materiale utilizzato durante la sessione, in cui ho parlato di:

Windows Phone 6 (aka Windows Mobile):

• Creazione di una Applicazione Mobile
  • Introduzione a Visual Studio
  • Tools per lo sviluppo mobile
• Controlli Visuali e Forms
• Gestione dello stato nelle applicazioni Mobile
  • XML e SQL Server Compact
  • LINQ on Mobile
• Controlli DataBound, accesso ai dati
  • Griglie e controlli pronti
• Interazione con il Sistema
  • System state e Short Messaging System
• Deployment di una Applicazione Mobile
  • Distribuzione manuale con ActiveSync
  • Creazione di un installer CAB
• Introduzione ai WebServices
  • Consumare WS remoti da Windows Mobile

Windows Phone 7:

• Ambienti di sviluppo
• Ciclo di vita dell’applicazione
  • esempi di running, sospended, exited
• Interoperabilità con l’OS
  • Launchers e Choosers
  • Demo su Launche PhoneCall
• Controlli visuali di Silverlight per WP7
• Cenni alle notifiche Push
  • Tipologie di notifiche
• Isolated storage
• Demo sul binding XAML e Launcher

Ci vediamo al DotNetCampus

E’ più di un mese che non scrivo su questo blog poichè mi sono sposato e ho fatto il mio meritatissimo viaggio di nozze. Prima che torni a parlare di contenuti tecnici è importante ricordare come quest’anno si replichi per il secondo anno l’iniziativa DotNetCampus che l’anno scorso ha avuto tanto successo.

L’evento

Sono particolarmente legato all’evento in questione perchè l’anno scorso mi ha visto direttamente coinvolto durante la sua organizzazione tra RoB e Microsoft Italia. Come è scritto sul sito http://www.dotnetcampus.it/ChiSiamo.aspx, l’evento è organizzato da DevLeap con il supporto (oltre che delle Communities .NET) dei Microsoft Student Partner, gruppo di cui sono fiero aver partecipato per quasi tre anni e nel quale ho conosciuto persone molto in gamba.

La grande, forse maestosa, differenza dall’anno scorso, è però che quest’anno gli eventi sono due (infatti avrei dovuto scrivere nel titolo “Ci vediamo AI DotNetCampus”, poichè uno è a Roma e l’altro, pochi giorni dopo, a Milano. Non posso che essere entusiasta della scelta e condividere la linea di DevLeap, anche perchè l’anno scorso si è “sentita” la mancanza di un equipollente del genere per noi milanesi.

Quando

Quindi, esorto tutti coloro che hanno interesse in Windows Phone 7 a rivederci a Roma il 26 Marzo e a Milano il 9 Aprile: dove in ogni caso ci saranno 6 track parallele per colmare le curiosità di tutti (Web / Cloud, Design / Modeling, WP7, Fun, Pattern / Agile Dev., Prodotti / Sponsor).

L’iscrizione è obbligatoria agli indirizzi che trovate online e potrete trovarmi alla sessione WP7-01 dalle 9.00 alle 9.50 nella track WP7.

WP7 App Hub (= Marketplace) Tutorial

Il Marketplace o, come ormai viene chiamato definitivamente, l’App Hub è ormai online, pronto e fiammante. Dopo l’avviso di ieri sera agli sviluppatori WP7 e Xbox 360 il famigerato portale è nuovamente online per ospitare le nostre applicazioni.

E non potendo aspettare ancora, ho fatto la mia prima submission, da cui ecco un tutorial per sottoporre le vostre applicazioni sul portale.

Registrazione

Il processo si apre, solo la prima volta, con la registrazione dell’utente e assegnamento della sua “icona” che lo caratterizzerà nel corso del suo ciclo di vita (dell’utente si ) all’interno dell’App hub.

L’utente oltre a scegliere l’icona può anche scegliere un gamertag per l’integrazione in Xbox Live. Se accedete tramite un Live ID già abilitato al Live, il processo lo riconosce automaticamente e sarete riconosciuti con il vostro (magari eroico) gamertag di sempre.

Processo di submission

Il processo si divide in 5 step:

• Upload dello XAP
• Compilazione delle informazioni relative all’applicazione
• Aggiunta dei loghi/icone/screenshots
• Prezzi
• Review e conferma

step 1 upload

Siccome già l’immagine sotto è abbastanza autoesplicativa, cerchiamo di commentare insieme i punti scoperti. Il nome dell’applicazione è un campo abbastanza logico ma non è il nome visualizzato sul marketplace. Per impostare quello si va allo step successivo e a tal proposito, la guida testualmente dice:

Questo è il nome dell'applicazione utilizzato per identificare la vostra applicazione nell’elenco applicazioni. Avete la possibilità di scegliere il nome applicazione che sarà visto dagli utenti Marketplace nella schermata successiva.

Poi abbiamo la lingua dell’applicazione, che non è nient’altro che la lingua principale in cui è scritta l’app. Se abbiamo applicazioni multilingua che non hanno, per architettura, una “lingua principale”, penso che scegliere “English” sia più che sensato.

La versione serve soprattutto a noi per dare un ordinale alla nostra applicazione e per dare all’utente la percezione degli aggiornamenti o dei cambi versione nel caso di aggiornamento del prodotto. Il framework supporta la versione principale e la secondaria (revisione e build sono fuori).

Poi dobbiamo fare l’upload dello XAP, operazione del tutto straightforward e opzionalmente inserire delle note di sviluppo (che non saranno visualizzate all’utente finale) e delle note per il processo di testing. Per queste ultime, la guida recita:

Utilizzare questo campo per fornire tutte le istruzioni speciali per la prova, come ad esempio le istruzioni per impostare le credenziali di un account di prova, ecc. Questo sarà usato durante il processo di certificazione dal nostro team di test.

Vi voglio rammentare quanto sia importante quest’ultimo passaggio nel caso l’applicazione necessiti di qualche particolare prerequisito per avviarsi. Detto ciò, non è obbligo dello sviluppatore mettere in condizioni il tester di testare ogni funzionalità, anche se è procedura consigliata se non vogliamo rischiare la certification failure.

L’ultima opzione, forse la più interessante, è ancora da chiarire appieno, ma secondo la guida si tratta di un flag per sottoporre la submission ad attenzioni “speciali”, un pò come quando si presenta all’ufficio anagrafe una pratica di residenza per un cittadino con 4 cittadinanze e si chiede allo sportello “guardi che deve stare attento, perchè la situazione è un pò complicata”. Oppure quando il processo di certificazione magari ha portato ad una failure e si vuole “insistere”. La guida dice:

L'invio di una eccezione tecnica aggiungerà diversi giorni per il processo di approvazione a meno che non siano state preventivamente approvate. Nuove richieste di eccezione non sono garantite di essere approvate e devono essere utilizzate solo in circostanze eccezionali.

step 2 description

Il passaggio più semplice (almeno tecnicamente) è la descrizione del prodotto. Sebbene infatti una descrizione fuorviante o delle keywords poco significative possano alterare le ricerche degli end-users, è anche vero che per gente abituata al web 2.0, taggare una applicazione propria può essere banale quanto fare un post su facebook.

La difficoltà di questa schermata sta nel trovare le parole giuste che un utente finale (non uno smanettone o un informatico) possa utilizzare per cercare qualcosa. Con mia grande sorpresa e sgomento, un giorno vidi una ragazza cercare su internet “negozio di jeans miss sixty vicino a buenos aires” che, sebbene qualche motore semantico dovrebbe andarci a nozze e trovare qualcosa, è ancora una ricerca troppo at-large e magari, il povero negozio di abbigliamento di una traversa di buenos aires che vende tutti i jeans del pianeta, non viene trovato.

Certamente non è colpa dell’end user, ma del commerciante che dovrà trovare (e sforzarsi di trovare) le parole chiave giuste per le ipotetiche ricerce dei più disparati utenti in circolazione.

L’unica voce di questa schermata che può essere poco chiara è la Featured app description e, a tal proposito, cito la guida:

Questa è una descrizione facoltativa della vostra applicazione che può essere utilizzata per mostrare la tua applicazione nell’hub del Marketplace e per metterla nella vetrina App. Si consiglia di fornire una breve descrizione.

Nota: vogliamo notare (in fondo) quanto è intelligente il processo che dal file XAP ha estrapolato il manifest e letto le capabilities necessarie all’applicazione per poter girare: grande!

step 3 artwork

Che dire qui, un consiglio per tutti (soprattutto gli “amatoriali” come me): non arrivate al processo di certificazione sottovalutando la parte grafica. A parte che con il nuovo WP7 è difficile sottovalutarla (a differenza di prima), ma senza le icone richieste, lo screenshot richiesto e le immagini richieste (il tutto rigorosamente della definizione e risoluzione richiesta) non si va da nessuna parte. Ogni cosa in più ben venga, ma prima occorre prestare attenzione ai requisiti obbligatori che ripetiamo qui:

• Una immagine 173x173px per 96 DPI
• Una immagine 99x99px per 96 DPI
• Una immagine 200x200px per 96 DPI
• Uno screenshot 480x800px per 96 DPI

step 4 pricing

In realtà dovrebbe chiamarsi “distribuzione” visto che è la parte relativa a questo aspetto della pubblicazione. Il pricing, a mio avviso, è solo un dettaglio (). Come vedete sotto in questo caso abbiamo scelto di non distribuire l’applicazione su tutti i mercati (scelta che MS come vedete in alto nell’immagine, sconsiglia).

La distribuzione in tutto il mondo vi permette di ottimizzare la disponibilità della vostra applicazione. L'adesione alla distribuzione a livello mondiale consente all'applicazione di essere distribuita automaticamente nei nuovi paesi supportati.

Ma siccome la mia app funzione solo sotto copertura H3G e sotto piani tariffari italianissimi, non c’è alternativa. Inoltre non offro trial del software perchè è una applicazione gratuita.

E se la mettessi a pagamento? Sotto ho provato a metterla a pagamento e il risultato è stato divertente: l’App Hub mi ha consigliato un prezzo per ogni mercato (che posso customizzare tranquillamente) già convertito nella valuta locale.

step 5 submit

Abbiamo finito, non ci resta che (opzionalmente) fare la review della nostra applicazione e poi premere il bottone “Submit for certification”. Nel caso si selezioni “Save & Quit” l’applicazione viene solo salvata senza passarla ai tester per l’approvazione. Inoltre, dal flag in figura, si può indicare se far passare l’applicazione sul catalogo non appena passa la certificazione.

Sebbene consigli questo approccio (visti i tempi genesiaci del processo), se una azienda vuole controllare l’uscita nel mercato del suo prodotto, questo flag è necessariamente da togliere.

Divertitevi!

Windows Phone 7 Navigation Framework

In realtà si dovrebbe dire Silverlight Navigation Framework ma poi non verrebbe indicizzato come vorrei sui motori di ricerca, perciò passatemi la licenza poetica.

In questo post parliamo della navigazione tra pagine su una applicazione SL per WP7. Intanto cominciamo dicendo che la famosa MainPage.xaml di una app SL WP7 in realtà parte perchè nel manifest viene invocata la navigazione su di essa. Quindi fatto, entry point a parte, anche lo startup dell’applicazione è, per certi versi, una navigazione (la cui pagina di origine però non può esistere).

L’idea alla base del sistema di navigazione è simile al concetto di browsing web: infatti si parte dal concetto che una applicazione è un insieme di pagine e da una pagina, tolta la glassa sintattica, quello che facciamo, semanticamente, è invocare un’altra pagina passando anche opzionalmente dei parametri in query string. Sembra molto una GET di HTTP.

E se vogliamo passare degli oggetti? Vanno serializzati in richiesta come per la POST?!? Ora non esageriamo, per passare oggetti abbiamo a disposizione la class App che è condivisa dalle varie pagine dell’applicazione.

Il chiamante

Il chiamante, tipicamente al click di un elemento, di un pulsante o al verificarsi di un evento può eseguire questo codice:

Il chiamato

A questo punto la pagina Pagina.xaml verrà invocata, la pagina corrente verrà scaricata (come fosse una pagina stateless di una WebApp) e al chiamato verrà fatto scattare questo handler:

dove, come da estratto, potremo ricavare i parametri passati in uno stile veramente molto simile allo stile di una WebApp.

L’UriMapper

L’UriMapper non è altro che un dizionario url:url in cui viene mappato un url reale con un suo corrispettivo “user-friendly” un pò nello stile dei routed urls in ASP.NET. L’idea è non doversi ricordare dei nomi dei parametri da passare e/o non volersene legare troppo.

Per cui il risultato è che se volessimo invocare la pagina di prima riscrivendo l’url così:

dovremo da qualche parte dire che “1” deve essere mappato al parametro “id” e che “aaabbbccc” deve essere mappato a “options”. Questo si fa in un UriMapper, che dichiareremo nelle risorse dell App.xaml così:

Infine bisogna dire che questo UriMapper deve essere imposto come l’UriMapper che l’applicazione dovrà andare a pescare per ogni richiesta di navigazione, altrimenti rimane nient’altro che un oggetto di tipo UriMapper completamente svincolato da ogni logica applicativa. Per fare questo quindi basta:

E il gioco è fatto!

WP7 ApplicationBar e System Tray – Tricks

Partiamo con il rispondere ad una domanda, lasciando ai lettori più interessati la spiegazione lunga: come facciamo a nascondere le icone in alto e fare una applicazione full-screen in Silverlight per WP7? Così:

Come vedete dall’immagine a sinistra, un applicazione WP7 viene hostata all’interno del contesto di un Frame (all’avvio dell'applicazione è il cosiddetto RootFrame dell’oggetto App), dove poi si divertirà a fare scorrere tutte le pagine che vuole, sempre sopra lo stesso frame.

Sebbene questo sia importante a livello concettuale, magari per chiarirsi le idee riguardo agli eventi in gioco, alle internals sulla navigazione o quant’altro, allo sviluppatore inizialmente non serve a nulla conoscerne il significato perciò, passiamo oltre.

Quando l’applicazione SL per WP7 parte, l’unica cosa che rimane del telefono, sempre visibile è la barra in alto (aka System Tray) che per l’appunto contiene le icone dello stato della batteria, il campo della linea GSM e così via, le solite cose.

Se stiamo sviluppando un gioco è impensabile che rimanga visibile mentre magari stiamo tenendo il dispositivo in orizzontale: perciò XNA di base quando viene lanciato va in full-screen senza troppe difficoltà.

Nelle applicazioni SL invece bisogna comunicare al sistema operativo che vorremmo nascondere la system tray e, dualmente, estendere la RootFrame fino al punto più alto, in modo da “coprire” la barra che non ci interessa. Dopodichè il gioco è fatto, abbiamo a disposizione tutta la superficie del telefono per fare la nostra applicazione fullscreen.

Quindi, sebbene come da figura (<=) abbiamo a disposizione tutta la client area per lavorare, è importante capire come interagire con le parti opzionali (sopra e sotto) che ci permettono di personalizzare al meglio l’aspetto.

Oltre alla System Tray in alto, possiamo avere la Application Bar in basso. Attenzione però che l’Application Bar ha un altro significato: non è qualcosa legato al sistema operativo (che quindi, di fatto, è comune a tutte la pagine della nostra applicazione), bensì è un componente di livello pagina, completamente opzionale, che funge da menù per azionare comandi.

Application Bar

L’Application Bar è una barra molto carina situata in basso e che di base contiene da una a 4 icone. Ogni icona può avere un comando. Oltre alle icone ci sono i MenuItem che non sono altro che voci di menù che, se presenti, risiedono in un menù a comparsa “sotto” le icone menzionate. L’effetto slide o l’opacità programmabile sono features out-of-the-box e anche i menù item hanno associato l’evento click a cui fare corrispondere il nostro custom code.

Questo per creare una Application Bar di livello pagina:

Di default questo è il frammento di codice compreso in ogni nuovo progetto WP7 ma commentato, per darci la scelta se abilitarlo o no. Penso che il motivo di questa scelta sia che il componente non esiste nella Toolbox e così facendo, aiutiamo lo sviluppatore ad implementare la barra velocemente.

Quello che forse non sanno ancora tutti sull’Application Bar è che si può anche crearne una unica per tutte le pagine dell’applicazione, direttamente nelle risorse statiche del file App.xaml:

per poi inserirlo in tutte le pagine che vogliamo nel tag PhoneApplicationPage:

Gli eventi relativi al click li gestiremo nell App.xaml.cs, in modo normale, ottenendo il navigatore tramite il RootFrame, così:

Il problema, attuale, degli item dell’application bar

Nonostante un coraggiosissimo Silverlight, all’aggiunta di un menù item dentro l’Application Bar, generi questo codice:

non c’è modo per far sì che l’oggetto (in questo caso selectRoaming, una voce di menù) sia diverso dal null. Infatti questo brandello di codice, messo insieme alle altre istruzioni di inizializzazione popolano i membri locali del code-behind mappandoli con gli oggetti SL. Funziona sempre tutto nell’InitializeComponent, tranne che gli assegnamenti per gli ApplicationBarMenuItem…. discriminazione?

Anatomia del progetto Windows Phone 7 in Silverlight

Iniziare a scrivere codice sperando che le skills SL3 si faccian da sè, da veterani dello sviluppo mobile, può portare via dai due a cinque giorni in più per capire cose che, partendo dall’inzio si capirebbero molto prima. Una cosa a caso è l’anatomia di una applicazione WP7 in SL.

Il progetto

Il template di progetto SL per WP7 è costituito da:

A questo possiamo aggiungere le cartelle che vogliamo con gli item che ci interessano, ad oggi questi:

Si consiglia sempre di dividere razionalmente il progetto in cartelle: intanto per la caratteristica di navigazione di SL, che su WP7 rende l’applicazione navigabile alla pari di un sito web (per cui razionalizzare all’interno di folders può essere utile), poi anche per una questione di naming e di leggibilità per lo sviluppatore (una applicazione con tante “view” avrà necessariamente tante PhoneApplicationPage e, se organizzate bene, saranno più facili da capire).

Se poi aggiungiamo al progetto degli item esterni, risorse e/o elementi multimediali, dobbiamo ricordarci di dire al builder cosa deve farne delle risorse appena importate. Possiamo scegliere tra:

• Embedded: risorse compilate nell’assembly
• Content: risorse impacchettate nello XAP
• Site of Origin: risorse semplicemente referenziate all’origine

L’entry point dell’applicazione

Il punto d’ingresso dell’applicazione, come recitato nelle properties di progetto, è il file App.xaml, che contiene le informazioni necessarie per avviare la “scatola” di SL per WP7:

Il file App.xaml rappresenta un oggetto Application, il quale ha degli eventi che si possono intercettare per scrivere il nostro custom code. Di default nello XAML c’è questa dichiarazione:

che crea già gli handler per gli eventi fondamentali del PhoneApplicationService. In realtà possiamo anche intercettare l’evento Exit e Startup dell’applicazione, ma attualmente non ci interessano.

WMAppManifest

Contiene le info su Silverlight per WP7 e collega le varie immagini all’applicazione Windows Phone per il deploy sul device. Nota: se modifichiamo il file direttamente le modifiche non vengono “viste” dalla pagina di proprietà del progetto, per cui in caso di salvataggio da quest’ultima posizione, si andrà a sovrascrivere il file xml.

Migrazione Windows Mobile to Windows Phone – HTML Scraping

Oggi cercheremo di migrare una applicazione di successo del vecchio Marketplace (per vecchio intendo quello con i software per WM 6.x) che non fa altro che fare HTML scraping su pagine web per ottenere dei dati e presentarli all’utente in una sola form. Detta così sembra decisamente semplice; sicuramente di interfaccia lo sarà e ci adopereremo per capire quali siano i limiti della codebase dell’applicativo.

Iniziamo con il vecchio progetto che si compone di:

• Client:
  • MainForm.cs: il form principale contenente tre textbox che conterranno i valori richiesti in remoto e un bottone per richiederli (più qualche label con del testo descrittivo).
  • Dettaglio.cs: la classe “wrapper” del dato remoto acquisito.
  • Program.cs: l’entry point dell’applicazione “old style”.
  • Icon.ico: l’icona dell’applicazione, ovvero l’icona dell’eseguibile che poi sarà anche quella presente nel menù programmi di WM 6.x.
  • Classes: cartella con alcune classi del “HtmlAgilityPack” di Simon Mourier (libreria disponibile su CodePlex e appositamente ritagliata per lo scopo).
• Setup: applicazione classica di setup di un CAB per windows mobile.

Partiamo dall’entry point. Definiamo una MainPage.xaml (di solito già pronta) nel nostro progetto WP7 e diciamo al Manifest che sarà la pagina in cui dovrà navigare all’avvio, di default.

A questo punto restiamo nel Manifest (WMAppManifest.xaml) e tagliamo qualche pezzo inutile che di default ci troviamo scritto, domandandoci:

• Cosa è consentito fare alla nostra applicazione? Sostanzialmente solo andare in internet. Perciò possiamo troncare dalle capabilities quelle “inutili” ovvero quelle che non ci sono necessarie. Per una spiegazione più dettagliata di cosa sia la capability list, potete leggere questo post.

Quindi mi sento libero di troncare quasi tutto lasciando la capability list come sotto:

A questo punto riproduciamo la form, che dovrà sembrare qualcosa del genere:

Per prima cosa per semplificarci la vita supponiamo che questa applicazione si possa “consumare” solo in modalità verticale (in fondo l’utente non fa nulla, quindi ci può anche stare). Perciò impostiamo a livello pagina e direttamente nello XAML l’orientamento supportato e l’orientamento di default nel tag PhoneApplicationPage:

Ora, partendo dal layout proposto, impostiamo il titolo dell’applicazione e il sottotitolo

e, per non saper nè leggere nè scrivere, trasciniamo tre TextBlock sotto di esso nelle posizioni desiderate: in ultimo il pulsante (nelle prossime demo vedremo invece come creare interfacce da XAML utilizzando i layout managers e le attached properties).

Ora che abbiamo la (vergognosamente brutta) interfaccia, non ci rimane che importare il codice di logica che avviene al click del pulsante (per ora ci disinteresseremo delle raffinatezze stilistiche). Perciò creiamo un event handler per il Click del bottone e importiamo la cartella Classes dal vecchio progetto, tentando la compilazione.

Una 30ina di errori di compilazione al momento attribuiti alla libreria HtmlAgilityPack che fa largo uso di ArrayList (non supportati in Silverlight), Hashtable e XPath. XPath non ci serve veramente, al limite andiamo di LINQ2XML perciò tagliamo le parti della libreria che utilizzano XPath. Poi arriva il problema degli ArrayList: molti di essi, verificando nel codice, contengono il tipo HtmlNode (definito dalla libreria stessa) perciò il nostro ArrayList diventa quasi ovunque un List<HtmlNode>. Un pò di refactor al costruttore e agli accessor methods e qualche errore sembra scomparire.

Poi agiamo sulla Hashtable: andiamo a vedere come vengono indicizzati i valori (=> con una stringa) e di che tipo sono (ArrayList di HtmlNode). Perciò anch’essi dopo la chirurgia diventano Dictionary<string,List<HtmlNode>>. Così via per tutti gli oggetti collection non generici che dovremo portare alla versione generica, come lo Stack semplice, che trasformeremo in Stack<HtmlNode>.

Problema: Dictionary al contrario di Hashtable, genera una eccezione per get la cui chiave non esiste, mentre Hashtable torna null. Da cui bisogna per forza passarsi il codice e sincerarsi che lo sviluppo non abbia permeato la sua logica su questo piccolo tip.

Infine la string.Compare(string,string,bool) non esiste più, perciò da sostituire con string.Compare(string,string,StringComparison).

A questo punto il programma è tornato a compilare, ora manca da incollare il frammento di codice “hot” che si interfaccia alla libreria e che svolge la logica di business. La classe Dettaglio.cs è ovviamente una passeggiata:

Primo problema: WebRequest

Il primo problema che si presenta è che la classe WebRequest in Silverlight non supporta i metodi sincroni, per cui ci dimentichiamo il GetResponse e utilizziamo il suo corrispettivo asincrono:

Tuttavia utilizzando la sola WebRequest il nostro applicativo andrà in eccezione per ProtocolViolationException, perchè per qualche motivo non gli basta che l’Uri sia un URL http, bisogna proprio utilizzare, a quanto sembra, la HttpWebRequest e, di conseguenza, il factory HttpWebRequest.CreateHttp(string url).

Secondo problema: Il FileSystem

Su WP7 non ho accesso al FileSystem per cui se voglio scrivere su file nel percorso di installazione del prodotto, no way. Fortunatamente era un scelta assolutamente casuale, nel progetto originale, poichè non c’era necessità alcuna di scrivere nella cartella del prodotto, in quanto era necessario solo un file su cui riscrivere più volte. Con un minimo effort possiamo utilizzare invece un file temporaneo, che mettiamo in pista in una riga:

Questa modifica però introduce un problema a runtime in quanto il metodo non è permesso in esecuzione su WP7, da cui bisogna cambiare strategia. Sarebbe il massimo redirigere questo metodo sull’IsolatedStorage (e mi sembra la scelta più ovvia); in ogni caso per scrivere un file temporaneo manualmente si può usare appunto l’Isolated Storage, lasciamo quindi lavorare la fantasia in proposito.

Terzo problema: Le query in XPath

Si lo so: chi è che usa ancora XPath?!? La ovvia conseguenza alla mancanza di XPath su WP7 è quella di usare LINQ2XML e quindi la mia query di HTML Scraping diventa questa:

Ok, abbiamo quasi finito. Ora, estrapolati i valori necessari, avremo una istanza di Dettaglio (con Val1,Val2,Val3,Val4 valorizzati) da mostrare sull’interfaccia. In realtà trascuriamo per il momento Val4 che serve per una funzionalità che non vedremo. Come collegare questi valori alla User Interface con i Binding di SL? Intando diciamo che l’istanza risultato è il nostro DataContext:

Poi nelle TextBlock del file XAML facciamo il binding diretto alle properties da associare, in questo modo:

Con il Client abbiamo finito, con il setup non dobbiamo neanche cominciare, visto che il Marketplace prende in pasto lo XAP generato dalla compilazione diretta del progetto in Visual Studio. Quindi abbiamo finito!

Migrazione Windows Mobile to Windows Phone – Intro

Un dilemma posto (e malposto) da molti, oggi è: come faccio a migrare le mie applicazioni da Windows Mobile a WP7?

Mi piacerebbe rispondere “non si può fare” e chiuderla lì, ma in alcuni casi non è necessario riscrivere proprio tutto il codice. Una cosa è sicura: l’interfaccia va riscritta in toto. Non essendoci più Windows Forms infatti bisogna ahimè piegarsi a Silverlight e XAML, con forte rammarico di chi nello sviluppo mobile, aveva visto uno spin off dello sviluppo client su Windows Forms.

Poco male, il “peggio” deve ancora venire . Una volta riscritta l’interfaccia, bisogna adoperarsi per comprendere cosa sia permesso o no sul nuovo dispositivo. Ad un programmatore esperto viene subito in mente… e non per uno studio mnemonico delle specifiche del device ma per semplici deduzioni fondate sugli assiomi:

• WP7 non è multitasking
• Le applicazioni di terze parti sono sviluppate in XNA o Silverlight

Dati questi apparentemente semplici assiomi, l’universo di possibilità che offriva un Windows Mobile si riduce drasticamente ad una manciata di cose possibili: giochi (e qui solo l’immaginazione può limitare lo scenario) e applicazioni device-unoriented.

Tutto ciò che rientrava/rientra nel settore Tools/Strumenti/Cose-carine-per-customizzare-il-dispositivo sono in buona parte troncate.

Solo dopo mesi di meditazione sono arrivato a constatare che questo approccio è migliore:

• Perchè riduce la possibilità delle cose plausibili, indirizzando meglio di fatto tutto il nuovo software sviluppabile verso un target molto più sensibile all’acquisto di applicazioni (vedesi Apple Store).
• Perchè evita che aziende di terze parti estendano il comportamento del dispositivo che, seppur può essere vista una mossa dittatoriale, è d’obbligo in un mercato così delicato come quello dei telefoni cellulari, dove la riservatezza e la confidenzialità devono essere preservate ad interim tra l’acquisto del dispositivo e il suo smaltimento, a prescindere da ogni eventuale utilizzo da parte del proprietario.
• Perchè incentiva l’innovazione tecnologica e, ripeto, seppure rammaricato, penso che WPF, Silverlight e XNA sia il futuro di Microsoft per quanto riguardo il pubblico e le masse (non a caso ultimamente si fanno enormi sforzi per concentrarsi sulla UX, quando una volta ci si concentrava solo sul dato).

A questo punto non rimane che prendere una vecchia applicazione, aprirla, sezionarla e verificare se è fattibile o no il porting sul nuovo dispositivo. Nel prossimo post.

A user’s perspective – Configurazione di account

Siccome i dettagli sul prototipo software inviatomi sono chiaramente riservati, anche perchè soggetti a cambiamenti prima della release finale del telefono, quello che intendo raccontarvi si può tranquillamente descrivere senza entrare nei particolari e senza screenshot, possibilmente spiegando meglio quello che, in alcune occasioni vicine (come il Remix) non tutti gli spettatori hanno colto.

Per chi di voi volesse provare a sporcarsi le mani con un software realistico (seppur limitato e differente da quello attuale e futuro) può dilettarsi con la versione exploitata dell’emulatore, che Dan Ardelean ben spiega come reperire in un suo post che ho linkato nel mio precedente articolo “Windows Phone 7 Recap - Giugno 2010”.

Ad ogni modo: l’obiettivo cruciale di WP7 è mettersi dalla parte dell’utente consumer. E l’utente consumer quando accende il telefono vuole fare tutto ciò che, paradossalmente, ha poco a che fare con un telefono in quanto tale.

Per esempio vorrebbe andare su Facebook: perciò su WP7 viene chiesto quasi subito di integrarsi a Facebook e questa apparentemente innocua operazione, porta ad un istantaneo merge dei contatti personali con quelli del social network (così facendo si integrano le classiche funzioni di consultazione contatti con le funzioni proprie di Facebook).

Viene altresì chiesto subito di integrarsi a Windows Live, per molteplici motivi: accedere alla propria posta Hotmail/Live, avere accesso all’Xbox live con il proprio account e, perchè no, sincronizzare anche i contatti di Live con il dispositivo ed accedere a Messenger.

Come dicevo anche in un post precedente, ad oggi il software prevede un merge tra i contatti del telefono e quelli di Facebook: per rimediare si può eliminare la connessione con l’account FB e tutto tornerà come prima.

Si possono configurare su WP7 tutti le tipologie di account email configurabili in passato su Windows Mobile e con estrema facilità. Per quasi tutti gli utenti consumer, basterà inserire mail e password e WP7 troverà da solo le informazioni sull’account. Esclusi gli utenti con custom domain che dovranno passare all’installazione ”personalizzata” dell’account, come sempre.

Ma tutto questo è possibile con una connessione dati: e se non ce la abbiamo? Ancora peggio: se non abbiamo proprio la SIM? Beh, WP7, come i suoi predecessori, funziona anche senza SIM e si appoggia, già dal post-installazione, a qualsiasi rete Wifi di cui forniate password.

Consiglio: Non aspettatevi un device che, come nel passato, vi chieda il permesso per qualsiasi cosa comporti una connessione dati. Ormai viaggia tutto “on the cloud” e WP7 è stato disegnato per supportare lo scenario in cui le applicazioni stesse del dispositivo sono fortemente distribuite, figuramoci il resto.
Tuttavia è giusto così: ormai internet viene dato per scontato e, una rete UMTS/HSDPA o WiFi è quasi sempre presente su un cellulare, perciò è doveroso che le applicazioni ci facciano affidamento. Quindi per i non-iPhonisti (i quali sono già abituati ad avere un piano dati) il consiglio è di farsi i conti per procurarselo o non si potrà gustare Windows Phone 7 come si deve.

Windows Phone 7 Recap – (fine) Agosto 2010

Nell’ultimo Recap abbiamo visto un pò l’universo che stava ruotando attorno alle incertezze sul dispositivo WP7 e sul software annesso. Abbiamo fatto un resoconto di quelli che sono i tre punti cardine del nuovo fenomeno (Il Device in sè, Il Software e quindi le possibilità di sviluppo e Il Marketplace) cercando di organizzare le notizie certe (all’epoca scarse) e le indiscrezioni del momento.

Oggi le cose sono un tantino diverse: a luglio è uscita la beta (Windows Phone 7 Beta SDK Tools) e RoB ha aggiornato tutti i suoi esempi (1,2,3,4,5) per le novità introdotte dal nuovo SDK. Tecnicamente parlando sono state consolidate alcune DLL e modificate, tagliate e aggiunte alcune classi relative all’API del dispositivo (per un elenco completo, qui). Inoltre, parallelamente è stato portato avanti il progetto di distribuzione dispositivi agli sviluppatori del Marketplace (come avevo annunciato) e quindi nei Beta tools sono anche disponibili i software per sbloccare i dispositivi e per fare il deploy diretto delle applicazioni in formato XAP.

Il prossimo, definitivo Recap avverrà nei giorni dopo il 16 Settembre, data in cui è annunciato che verranno rilasciati i tools definitivi di sviluppo promettendo (in questo post) che il passaggio sarà indolore e che le differenze saranno minime. Quello che ne segue è che (spero) verrà contemporaneamente rilasciato un update per i dispositivi reali altrimenti, al cambio di API paradossalmente le cose funzioneranno in Visual Studio e non sul dispositivo. Per cui, confido nel tempismo di questo ultimo rilascio.

Se quindi da un lato le specifiche del dispositivo rimarranno le stesse (e possiamo dire che il device è “pronto”) quello che ci aspettiamo è che venga leggermente limato l’SDK e le policy del marketplace (che già nella release di Luglio avevano subito alcune modifiche).