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.
Dopo una fase CTP che durava da Novembre 2009, i tempi sono ormai maturi per far uscire e, giustamente, far pagare il servizio di Content Delivery Network di Windows Azure.
L’obiettivo del servizio è fornire varie location nel mondo per portare i dati vicino agli utenti che ne usufruiscono. Ad esempio, una applicazione potrebbe memorizzare dei video o dei documenti all’interno dello storage di Windows Azure: dalla versione 1 di Azure è possibile indicare come affinity group dove devono risiedere i dati; ad esempio potrei piazzare i dati in Europa.
Se la mia applicazione fa largo uso dei dati nello storage potrebbe essere molto furbo replicare tali dati su server più vicini all’utente. Ad esempio se i miei utenti sono italiani potrebbe aver senso ridurre la latenza portando una copia dei dati su server italiani. Se ho clienti internazionali sarebbe furbo portare i dati nei vari paesi.
Il servizio CDN si occupa proprio di questo: replicare copie dei dati nei vari punti della rete in modo da avvicinarli agli utenti che ne fruiscono.
I prezzi sono stati resi pubblici sabato e li riporto come li ho ricevuti:
To date, this service has been available at no charge. Today, we’re announcing pricing for the Windows Azure CDN for all billing periods that begin after June 30, 2010. The following three billing meters and rates will apply for the CDN:
- $0.15 per GB for data transfers from European and North American locations
- $0.20 per GB for data transfers from other locations
- $0.01 per 10,000 transactions
With 19 locations globally (United States, Europe, Asia, Australia and South America), the Windows Azure CDN offers developers a global solution for delivering high-bandwidth content. The Windows Azure CDN caches your Windows Azure blobs at strategically placed locations to provide maximum bandwidth for delivering your content to users. You can enable CDN delivery for any storage account via the Windows Azure Developer Portal.
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 contenente 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 Expand 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
Ecco un semplice esempio di utilizzo dell’accelerometro. L’applicazione legge e visualizza i dati X, Y, Z forniti dall’accelerometro.
Il codice si commenta da solo.
Aggiungere al progetto una reference verso Microsoft.Devices.Sensors ad un progetto creato con il template di default.
Creare giusto due elementi informativi sulla user interface:
Margini e impostazioni a parte questo il codice Silverlight
I 3 TextBlock finali accoglieranno i risultati e sono stati denominati XText, YText, ZText
La prima parte di codice del code-behind inizializza l’oggetto e si abbona all’evento alla pressione del tasto Start:
Quando l’accelerometro (in un prossimo appuntamento vedremo le Rx Extension per simulare i dati in attesa dei device) invia dati, tramite la classica chiamata al Dispatcher chiediamo al thread principale di eseguire il nostro metodo ReadChanged ripassando gli EventArgs ricevuti.
Il metodo ReadChanged visualizza semplicemente le informazioni X, Y, Z a video. Per completezza inserisco nell’estratto di codice anche il metodo di Stop.
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’.
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.
Con molto piacere vi segnalo che il 9 giugno, a Bologna, si terrà il primo meeting di IASA Chapter Italy.
Il piacere sarà trovarsi dopo 12 anni esatti dall’ultima conferenza tenuta insieme con Andrea Provaglio per ben due appuntamenti consecutivi (Andrea già la prossima settimana sarà sul palco alla nostra DevCon 2010).
Andrea terrà una sessione su Aspect-oriented programming mentre personalmente introdurrò lo sviluppo su Windows Azure Platform. In mezzo alle due sessioni tecniche avremo un intervento di orientamento sul cloud computing.
Al termine delle sessioni possiamo rimanere a parlare davanti ad una buona birra e qualche snack.
La partecipazione è gratuita e rivolta a architetti e sviluppatori.
Non vi resta che dare un’occhiata all’agenda e iscrivervi se siete in zona: http://iasahome.org/web/italy/news/-/blogs/360699?_33_redirect=%2Fweb%2Fitaly%2Fnews.
Portando alcune demo per DevCon 2010 alla versione 4.0 del .NET Framework ho riscontrato questo problema…
L’errore si verifica utilizzato l’SDK 1.0 per AppFabric Service Bus con .NET 4.0.
{"Invalid element in configuration. The extension name 'transportClientEndpointBehavior' is not registered in the collection at system.serviceModel/extensions/behaviorExtensions.
(D:\\Applications\\EstatesManagement\\Current\\DevLeap.EstatesManagement.UI.WPF.SmartClient
\\bin\\Debug\\DevLeap.EstatesManagement.UI.WPF.SmartClient.vshost.exe.Config line 101)"}
Sulla stessa macchina una applicazione .NET 3.5 con Visual Studio 2008 gira benissimo con il service bus, mentre la stessa applicazione con Visual Studio 2010 non gira.
Il problema (e la soluzione) è molto semplice: installando l’SDK per il Service Bus vengono aggiunti nel machine.config nuovi binding e nuovi behavior per supportare la comunicazione WCF con il service bus. L’SDK però aggiorna solo il machine.config della versione 3.5.
Se usate la versione 4.0 occorre prendere dalla versione 2.0 (ricordo che la 3.0 e la 3.5 sono aggiunte alle 2.0 come runtime quindi il machine.config della 2.0 è il nostro riferimento) behaviorExtension, bindingElementExtension e bindingExtension, nonchè i metadati aggiunti dall’installazione dell’sdk.
Il “problema” ovviamente si presenta anche durante il deploy, ma in questo caso non è ovviamente un problema in quanto è normale dover aggiungere elementi esterni alla configurazione di una applicazione (web.config o app.config) quando si usano l’sdk esterni al framework stesso.
Vi riporto per completezza l’elenco delle aggiunte da fare alla sezione <system.serviceModel>
<system.serviceModel>
<extensions>
<behaviorExtensions>
<add name="connectionStatusBehavior" type="Microsoft.ServiceBus.Configuration.ConnectionStatusElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</behaviorExtensions>
<bindingElementExtensions>
<add name="tcpRelayTransport" type="Microsoft.ServiceBus.Configuration.TcpRelayTransportElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="httpRelayTransport" type="Microsoft.ServiceBus.Configuration.HttpRelayTransportElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="httpsRelayTransport" type="Microsoft.ServiceBus.Configuration.HttpsRelayTransportElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="onewayRelayTransport" type="Microsoft.ServiceBus.Configuration.RelayedOnewayTransportElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</bindingElementExtensions>
<bindingExtensions>
<add name="basicHttpRelayBinding" type="Microsoft.ServiceBus.Configuration.BasicHttpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="webHttpRelayBinding" type="Microsoft.ServiceBus.Configuration.WebHttpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="ws2007HttpRelayBinding" type="Microsoft.ServiceBus.Configuration.WS2007HttpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="netTcpRelayBinding" type="Microsoft.ServiceBus.Configuration.NetTcpRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="netOnewayRelayBinding" type="Microsoft.ServiceBus.Configuration.NetOnewayRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="netEventRelayBinding" type="Microsoft.ServiceBus.Configuration.NetEventRelayBindingCollectionElement, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</bindingExtensions>
</extensions>
<client>
<endpoint address="" binding="netTcpRelayBinding" contract="IMetadataExchange" name="sb"/>
<metadata>
<policyImporters>
<extension type="Microsoft.ServiceBus.Description.TcpRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<extension type="Microsoft.ServiceBus.Description.HttpRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<extension type="Microsoft.ServiceBus.Description.OnewayRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</policyImporters>
<wsdlImporters>
<extension type="Microsoft.ServiceBus.Description.StandardRelayBindingImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<extension type="Microsoft.ServiceBus.Description.TcpRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<extension type="Microsoft.ServiceBus.Description.HttpRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<extension type="Microsoft.ServiceBus.Description.OnewayRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</wsdlImporters>
</metadata>
</client>
hope useful
Mancano ormai pochi giorni alla nostra settima DevCon: sembra incredibile quanto poco tempo sia passato dal 2004, quando abbiamo “provato” a fare la prima edizione.
Anche quest’anno Estates Management ci servirà come guida per analizzare insieme l’architettura di una applicazione reale. Lo spirito è quello di sempre: introdurre le novità e i cambiamenti (ad esempio Entity Framework 4, Workflow 4, Windows Azure) per poi calare da subito il prodotto nella “sua posizione corretta” dal punto di vista architetturale.
Quest’anno abbiamo anche deciso di affiancare all’applicazione demo, alcune applicazioni reali che abbiamo sviluppato in questi anni per clienti come Dompè, Fabbrica Digitale, Microgame, Edisoftware e altri due “famosi” che non ci interessa citare pubblicamente.
I posti rimasti sono ancora pochi: se sei intenzionato ad iscriverti ti consiglio di farlo velocemente.
Ci vediamo a DevCon.