May 2010 - Posts
Il servizio “Location Service”, come indica il nome stesso, consente di notificare alle applicazioni che lo utilizzano la posizione corrente del device.
Il servizio ottiene i dati da fonti diverse in base alle impostazioni (effettuabili da codice) che l’applicazione che lo utilizza fornisce. Chi ha lavorato con servizi simili sa bene che l’utilizzo di risorse hardware comporta inevitabilmente l’utilizzo della batteria e che molto spesso più le risorse sono “buone” più consumano batteria e viceversa. Occorre quindi trovare sempre il giusto bilanciamento fra il consumo della batteria e l’utilizzo di hardware: nel caso del servizio “Location Service” la regola, oltre al consumo di batteria, deve tener conto anche dell’accuratezza delle rilevazioni.
In pratica per rintracciare la posizione del device è possibile usare
1) Wi-Fi: meno accurato di un GPS, ma consuma meno batteria
2) GPS: più accurato ma maggior consumo di batteria
In pochi sanno che anche la rete “cellulare” fornisce informazioni sulla location, sicuramente meno accurate di un GPS e del Wi-Fi, ma che, ovviamente, meno drenanti per la batteria: inoltre l’antenna “cellular” è probabilmente già accesa per altri ovvi motivi :-)
Le classi che consentono di usare il servizio dispongono di un livello di accuratezza impostabile dall’applicazione che le usa: è possibile quindi gestire dall’applicazione, a seconda del suo utilizzo, la tipologia di sensore da utilizzare.
Se l’applicazione può lavorare con dati più o meno accurati potrebbe essere un’ottima idea chiedere all’utente (con messaggi chiari e semplice) come vuole ottenere i dati in modo che, come accade per molte altre funzionalità native di un telefono moderno, sia lui a scegliere come comportarsi. Un’ulteriore buona idea potrebbe essere informare l’utente quando la batteria scende sotto una soglia (ad esempio un 30%) con un messaggio che lo informa che “sarebbe bene abbassare il livello di accuratezza” per evitare di rimanere a piedi.
Oltre all’impostazione Low/High della classe GeoCoordinateWatcher, è possibile impostare anche MovementThreshold: questa proprietà consente di filtrare i movimenti entro un certo numero di metri prima di segnalare all’applicazione all’avvenuto spostamento dell’utente; nel caso di utilizzo di un livello di accuratezza alto è molto probabile infatti che vengano captati anche piccoli movimenti che rischiano di inviare troppi eventinon significativi all’applicazione: ad esempio se l’applicazione ricerca gli immobili in vendita nelle vicinanze non è importante modificare i dati effettuando una nuova ricerca se l’utente si è spostato di 2 metri :-)
E’ necessario preparare l’applicazione in modo da gestire la mancanza di “segnale”.
Ecco un esempio per capire come si utilizzano le classi e prendere la mano con i sensori; seguirà poi un articolo di approfondimento.
Il form come sempre è molto semplice e presenta i due pulsanti per avviare e fermare il servizio.
Alla ricezione dell’evento di notifica della posizione valorizzeremo i due TextBlock Lat e Long, mentre l’ultimo TextBlock rappresenta lo stato del servizio.
Il codice della parte Silverlight, senza nessuna pretesa grafica o “pretesa in generale” :-) è la seguente:
Ho tagliato la parte iniziale e le parti non significative.
Veniamo al codice di gestione del servizio:
La classe GeoCoordinateWatcher consente di impostare l’accuratezza direttamente nel costruttore. La seconda riga imposta invece il filtro sul movimento entro i 20 metri.
L'evento di gestione del cambio di stato (che avviene da un thread secondario e quindi richiede una Invoke) è il seguente:
MyStatusChanged controlla l’enum GeoPositionStatus per capire se il servizio funziona o meno. Nel caso di Disabled il codice cerca di capire se l’utente ha disabilitato il servizio oppure il servizio stesso non funziona.
Il codice di recupero posizione è sempre gestito da un event handler che viene invocato da un thread separato.
Oltre al metodo MyPositionChanged che recupera Latitudine e Longitudine, il metodo StopTrackButton_Click non fa altro che fermare il servizio.
In questo esempio non è stato usato un try/catch per semplificare il codice, ma ovviamente è necessario prevedere, come accennato all’inizio dell'articolo, i casi di eccezione.
Oltre alle due informazioni recupare nell’esempio è possibile conoscere anche l’altitudine, la velocità come dimostra il debug sulla proprietà Position di GeoCoordinate
Nel mio caso non sto simulando nessun dato sull’emulatore quindi tutti i valori risultano NaN.
Nella nuova sezione Windows Phone 7 di ThinkMobile.it ho postato gli esempi relativi ai mini-articoli pubblicati su questo blog.
http://thinkmobile.it/media/g/sviluppo/default.aspx
Un file nascosto, si fa per dire, ma molto importante per lo sviluppo di applicazioni per Windows Phone 7 è WMAppManifest.xml.
Questo file è presente nella directory Properties di una progett Silverlight per Windows Phone 7 e inserito per default da Visual Studio 2010 Express for Windows Phone se si utilizza il template relativo.
Questo il file di un mio esempio di location, su cui arriverà l’articolo a brevessimo.
La proprietà Title per default riflette il nome del progetto scelto dal wizard di creazione. Il device utilizza questa proprietà per visualizzare l’applicazione.
Il tag
<IconPath IsRelative="true" IsResource="false">ApplicationIcon.png</IconPath>
indica invece il nome dell’immagine da utilizzare l’icona dell’applicazione. Tale file viene inserito in automatico nella root del progetto se si utilizza il template di default di Visual Studio.
Rispetto ad una applicazione Silverlight tradizionale che usa il file AppManifest.xml, l’applicazione Windows Phone 7 utilizzerà questo file.
Come per le applicazioni Silverlight tradizionali, anche sui nuovi Windows Phone 7 sarà possibile utilizzare l’Isoltated Storage per memorizzare informazioni applicative.
Vista la natura a Page dell’applicazione è quasi indispensabile salvare lo stato dell’applicazione sull’Isolated Storage, soprattutto per tenere le informazioni fra una sospensione e il ripristino dell’applicazione se l’utente attiva un’altra applicazione in foreground.
L’Isolated Storage può quindi servirci per
1) Inserire dati applicativi: è possibile definire una gerarchia di folder per accogliere questi dati
2) Tenere i settaggi dell’applicazione: in questo caso si utilizza un dictionary in modo simile a quanto si fa per le applicazioni Silverlight tradizionali
Dalla documentazione attuale su MSDN si evince che:
The default application size for applications is 2 GB. Quota management can be enforced to block applications from growing their data storage beyond their specified limit. However, Windows Phone applications will not be restricted to a particular quota. They should make careful use of space based on their application scenario requirements.
Per accompagnare questa mini-teoria con un esempio ecco il codice di una applicazione che salva il valore digitato dall’utente in un textbox all’interno di un file in un folder dell’Isolated Storage; da un secondo pulsante il codice per rileggere il valore: oltre questo semplice esempio, libera fantasia :-)
A parte i nomi dei controlli e i relativi event handler, il codice associato ai pulsanti è il seguente:
A parte il fatto che il nome del folder sarebbe bene inserirlo in configurazione, il codice si spiega da solo.
La User Interface risultante…mi vergogno a farvela vedere :-)
Seguendo l’esempio su MSDN ecco una semplice applicazione che fa uso dlel’application bar di Windows Phone 7.
Aggiungere una reference a Microsoft.Phone.Shell e creare un folder contentente le immagini da mostrare nell’application bar.
Prima di iniziare è bene tenere presente che
1) La Application Bar viene visualizzata come riga contenente da una a quattro immagini sulla parte inferiore dello schermo.
2) Non è un menù gerarchico
3) Le icone devono essere bianche su sfondo traparente utilizzando il canale alpha.
4) La colorazione e l’orientamento vengono gestiti in modo automatico in base alle impostazioni correnti
5) Le immagini devono essere 48x48 pixel e la grafica bianca di foreground deve rientrare nello spazio quadrato ad essa dedicata (26x26 pixel)
Ci sono molto altre regole ma non voglio annoiarvi con questi dettagli prima di aver visto e costruito insieme l’esempio.
Il progetto si dovrebbe presentare così:
Le immagini vanno gestite come “Content” e non come “Resources”: se importate le immagini da Visual Studio vengono marcate come Resource quindi occorre cambiarne la “Build Action”.
Per includere le immagini nell’Application Bar occorre agire ovviamente sull’XAML aggiungendo prima il namespace per presentare (come dice sempre il nostro Luca) all’applicazione il namespace da cui attingeremo per creare i controlli.
La proprietà da impostare è ApplicationBar del controllo PhoneApplicationPage: a tale proprietà occorre indicare la sua visibilità e la visualizzazione del menù tramite il controllo ApplicationBar del namespace Microsoft.Phone.Shell.
Aggiungiamo quindi il namespace:
xmlns:shell="clr-namespace:Microsoft.Phone.Shell;assembly=Microsoft.Phone.Shell"
e poi valorizziamo la proprietà del controllo:
<phoneNavigation:PhoneApplicationPage.ApplicationBar>
<shell:ApplicationBar IsVisible="True" IsMenuEnabled="True">
</shell:ApplicationBar>
</phoneNavigation:PhoneApplicationPage.ApplicationBar>
All’interno dell’application bar dovremmo definire i vari button e le relative operazioni:
Ho inserito due immagini di prova Expang e MenuEnabled con relativo event handler.
Il designer non visualizza l’application bar.
Il risultato nell’emulatore è il seguente:
E’ possibile aggiungere anche voci di menù:
<shell:ApplicationBar.MenuItems>
<shell:ApplicationBarMenuItem
x:Name="ThinkAhead"
Click="Test_Click"
Text="ThinkAhead" />
<shell:ApplicationBarMenuItem
x:Name="PiaSys"
Click="Test_Click"
Text="PiaSys" />
</shell:ApplicationBar.MenuItems>
Le voci di meù consentono di avere più opzioni di menù oppure semplicemente descrivere con del testo quello che non può essere rappresentato con le icone. Nel caso seguente ho aggiunto le aziende tecnihe del gruppo DevLeap come voci di menù. Notare che le voci di menù appaiono in minuscolo per default.
La visualizzazione dell’Application Bar prevede tre punti “…” per rappresentare il menù che si aprirà ad effetto :
Se le voci di menù devono essere create in modo dinamico è possibile agire sugli oggetti da codice:
ApplicationBar = new ApplicationBar();
ApplicationBar.IsVisible = true;
ApplicationBar.IsMenuEnabled = true;
ApplicationBarIconButton button1 = new ApplicationBarIconButton(new Uri("/Images/Expand.png", UriKind.Relative));
button1.Click += new EventHandler(button1_Click);
ApplicationBarIconButton button2 = new ApplicationBarIconButton(new Uri("/Images/MenuEnabled.png", UriKind.Relative));
button2.Click += new EventHandler(button2_Click);
ApplicationBar.Buttons.Add(button1);
ApplicationBar.Buttons.Add(button2);
Alla prossima
Riprendendo una parte di workshop direttamente da MSDN ho ricreato questo piccolo esempio di applicazione client che sfrutta il controllo web browser presente su Windows Phone 7
Si faccia riferimento Windows Phone 7 Intro per una introduzione alla creazione di progetti con Visual Studio 2010 Express for Windows Phone.
Creato il progetto e modificato il classico Title e SubTitle, è stato inserito un campo TextBox e un Button. Molto importante, com’è in Windows Mobile attuale, la necessità di disegnare la User Interface in modo che si adatti alla risoluzione video: dalle specifiche hardware, i nuovi telefoni avranno una risoluzione di 800x480, ma sicuramente nel futuro queste specifiche potranno adattarsi a nuove tipologie di schermi e device. Inoltre è prevista la possibilità (come in WM) di orientare lo schermo in orizzontale e verticale.
In interfacce relativamente semplici come quella di questo esempio si può sfruttare quello che in Windows Form per Windows Mobile si chiama Docking ovvero la possibilità di agganciare i controlli ai bordi.
In Silverlight, una delle tecniche per ottenere questo risultato, è impostare i margini rispetto al controllo contenitore. Ad esempio per ottenere questo risultato
il campo TextBox, il Button e il controllo web browser sono allineati rispetto alla griglia che li contiene. La griglia viene proposta di default
Ruotando l’emulatore non ottengo però l’effetto desiderato:
Modificando lo XAML come segue si ottiene l’effetto desiderato
Ecco il risultato
Questo è solo un esempio: in applicazioni più complesse dove si ricerca una UX elevata dovremmo creare XAML diversi per essere più precisi possibili. Si potrà poi condividere il code-behind oppure creare un modellino OOP dietro le quinte per evitare di “spalmare” la gestione degli eventi e le righe di codice dei form in più punti.
Per iniziare, a parte avere experienza in XAML e nel disegno di user interface, i documenti “UI Design e Interaction Guide” e “Windows Phone Design System – Metro” sono una buona base di partenza: si trovano a partire da quì: http://msdn.microsoft.com/en-us/library/ff637515(VS.92).aspx
Dopo DevCon 2010 riprendiamo il filo del discorso con altri esempi.
A proposito di DevCon, vediamo come si vede il sito nel browser di Windows Phone 7
Una nota: se si commette un errore nel XAML e l’errore viene segnalato da VS durante il debug, come ad esempio l’errore mostrato di seguito, occorre chiudere il file .g.cs aperto in automatico da Visual Studio prima di poter ripartire con una successiva sessione di debug
Altrimenti sembra che VS tenga lockato il file che quindi non può essere aggiornato dal generatore e resta “vecchio“ durante il deploy sul device.
Preso dall’entusiamo pre-conferenza ho provato a portare l’interfaccia delle sessioni della conferenza dello scorso anno (DevCon 2009: http://devcon2009.devleap.com/SessionsSilverlight.aspx) visto che era fatta in Silverlight, dentro il nuovo ambiente.
A parte un tag non supportato dal Visual State Manager e un paio di informazioni sulle definizioni dei colori, che, visto che non sono un esperto di Silverlight ho semplicemente rimosso dalla definizione delle risorse, questo il risultato:
Ovviamente questa interfaccia dovrebbe, vedi discorso precedente, essere riadattata alla risoluzione , ma è quasi incredibile vedere una applicazione Silverlight nata nel dicembre 2008 per il sito della conferenza DevCon 2009, girare dopo 18 mesi su un SDK per un telefono che arriverà fra un po’.
Queste le specifiche hardware della nuova piattaforma:
A large WVGA (800 x 480) format display capable of rendering most web content in full-page width and displaying movies in a cinematic aspect ratio.
Capacitive 4-point multi-touch screens for quick, simple control of the phone and its features.
DirectX 9 hardware acceleration for crisp graphics and exciting audio and video.
A standard suite of sensors - A-GPS, accelerometer, compass, light, proximity - for interacting with the phone’s location, orientation, and environment.
A digital camera.
A common set of hardware controls and buttons that include the Start, Search, and Back buttons.
Support for data connectivity using cellular networks and Wi-Fi.
256 MB (or more) of RAM and 8 GB (or more) of flash storage.
Fonte: http://msdn.microsoft.com/en-us/library/ff637514(VS.92).aspx
E’ disponibile da mercoledì l’aggiornamento a Office 2010 per tutti che i device che hanno la versione precedente.
Il tutto si scarica dal MarketPlace http://marketplace.windowsphone.com/Default.aspx dal PC o direttamente dal device.
La novità più interessante è probabilmente l’integrazione con SharePoint e la conseguente possibilità di lavorare (anche offline) con i documenti aziendali/personali.