Da un post di ieri ecco l'annuncio atteso da molti. Silverlight 2.0 RTW sarà rilasciato nella giornata di oggi. (considerato che il post è di ieri...)

I'm very pleased to confirm that we'll be releasing Silverlight 2 tomorrow.

http://silverlight.net/blogs/jesseliberty/archive/2008/10/13/silverlight-2-releases-tomorrow.aspx

Technorati Tags: ,,

Ieri ho trovato qualche minuto da dedicare alla mia Silverlight Library. Ho pubblicato la nuova versione ricompilata per porter funzionare con la Release Candidate 0 di Silverlight 2.0. In realtà la libreria non ha subito sostanziali modifiche se non la rimozione di un paio di attributi TextAlignment nelle pagine di esempio che con il nuovo runtime non funzionavano.

Link: http://www.codeplex.com/silverlight


Sono reduce di una di quelle giornate altamente improduttive, anche se in effetti ho lavorato più (e più intensamente) del solito… Quest’oggi in azienda abbiamo scoperto che un PC su cui abbiamo recentemente installato Visual Studio 2008 (e non ancora la SP1) improvvisamente non riusciva più a connettersi ad un processo in debug su un Device Windows CE.

Partendo con il classico F5 il problema non si pone, il processo viene agganciato e il debug va a buon fine. Invece, dal menù di Debug>Attach to a process... si ottiene un errore criptico per quanto stringato e inutile: "Unable to attach to the process". Io e i colleghi Andrea e Mirco abbiamo perso l'intera giornata cercando di capire cosa non funzionasse e alla fine ci siamo resi conto che il problema non affliggeva solo una macchina ma anche altre nella rete. Alla fine, stremato dagli inutili tentativi la soluzione si è presentata così inattesa da risultare inverosimile.

La chiave che accomuna le macchine che presentavano il problema è la presenza dei "Silverlight 2.0 Tools for Visual Studio 2008" e l'aver notato questa peculiarità è stata la chiave per risolvere il problema. Il fatto è che questi Tools (che sono tuttora in beta) installano una patch per Visual Studio 2008 (KB950630). Tale patch è così fantomatica che non se ne trova nemmeno traccia sul sito Microsoft. Il link alla Knowledge base che si trova nell'About box di VS2008 è semplicemente bucato. Inoltre il disinstallare i tools non è sufficiente a risolvere il problema; infatti la patch rimane installata.

Immagine3

Disinstallate a mano la KB950630 e tutto magicamente tornerà a funzionare.

Morale? Se sviluppate con Silverlight 2.0 non potete fare l'attach dei processi con Windows CE e naturalmente se sviluppate con Windows CE non potete installare i necessari tools di Silverlight.


Date uno sguardo a cosa si riesce ad ottenere con lo deep zoom di Silverlight 2.0. L'immagine di Obama è composta da più di 12000 piccole foto dei supporters di Barack Obama.

http://www.deepzoomobama.com/

e qui trovate qualche chiarimento:

http://blog.donavon.com/2008/06/deep-zoom-obama.html

Ecco cosa dice l'autore:

Deep Zoom McCain was tried, but there were problems finding enough photos of McCain supporters. We did manage to find a few and if you really squint really hard, you can make out the image of John McCain’s face in the 20 image mosaic below.

Se volete un consiglio, provate a zoomare nelle pupille...

Technorati Tag: ,

Il che ho tenuto l'anno scorso a proposito di Silverlight 1.0 è stato recentemente aggiornato da che ha prodotto alcuni tutorial su Silverlight 2.0.

  • Silverlight 2 (beta 2) – Iniziare a sviluppare
  • Silverlight 2 (beta 2) – Costruire la User Interface
  • Silverlight 2 (beta 2) – La User Interface e il DataBinding
  • Silverlight 2 (beta 2) - Il Networking
  • Silverlight 2 (beta 2) – Expression Blend 2.5 per “developer”

Ne trovate notizia nel post di oggi sul blog di MSDN Italia

http://blogs.msdn.com/italy/archive/2008/06/25/tutorial-su-silverlight-2-beta-2.aspx

Technorati Tags: ,

La Beta 2 di Silverlight 2.0 ha visto la scomparsa di un controllo WatermarkedTextBox. In questo post di Brad Abrams trovate le motivazioni della scomparsa:

http://blogs.msdn.com/brada/archive/2008/06/24/watermarkedtextbox-for-silverlight-2-beta-2.aspx

Eventualmente potete scaricare il sorgente del controllo qui:

WatermarkedTextBox source code and unit test

Inoltre ne parla Kathy Kam nel sul blog:

http://blogs.msdn.com/kathykam/archive/2008/06/23/watermarkedtextbox-for-silverlight-2-beta-2.aspx


In questi giorni, sono cominciati ad apparire alcuni post che mostrano come utilizzare il WSDualHttpBinding con la Beta 2 di Silverlight. Tale binding infatti è supportato a partire dall'ultima release, grazie alla presenza di due assembly, System.ServiceModel.PollingDuplex.dll, uno per la parte client e l'altro per la parte server.

Ma la domanda che mi sono posto, subito dopo i primi esercizi per vedere come trarne vantaggio è la seguente:

Assodato che questa tecnica fa uso di (e tutti voi sapete quanto dannosa può essere per il webserver) per quale motivo dovrei ricorrere a tale binding anzichè implementare manualmente (e molto più semplicemente...) la medesima tecnica?

In effetti un reale vantaggio esiste ed è insito nella modalità con cui il polling viene effettuato. A differenza di quello che accade con un polling manuale, nel quale il client rimane sostanzialmente disconnesso per la maggior parte del tempo, e si accorge della presenza di informazioni solo allo scadere di un timeout, con il Polling di WCF quello che avviene è che il client si connette al server e rimane in questo stato per tutta la durata del timeout salvo eventualmente disconnettersi nel momento in cui arrivano informazioni utili.

La differenza che a prima vista pare banale è invece sostanziale. Infatti in questo modo si aggira il problema tipico del polling e cioè la latenza dei messaggi che costringono spesso a ridurre il più possibile l'intervallo tra due diverse chiamate. Con WCF potremmo avere un intervallo di poll anche molto ampio, ma continueremo ad ottenere in tempo reale i risultati dal server che si occuperà di chiudere la nostra connessione e notificarci l'arrivo nello stesso istante in cui i dati divengono disponibili.

A giudicare dal formato del messaggio SOAP, questa tecnica rispetta lo standard OASIS WS-MakeConnection, descritto ampiamente in questo documento. Quello che non mi è dato sapere è il livello di compatibilità dell'implementazione di Silverlight 2.0 con questo standard.

La tecnica quindi appare davvero interessante e apre la strada ad applicazioni in vero realtime anche per il web. Attenzione però che la licenza Go-Live di Silverlight 2.0 non si applica a questo assembly perciò dovremmo aspettare la RTM per poterlo portare in produzione (evidentemente si attendono modifiche importanti).


Se si costruisce un controllo di Layout, come già detto in precedenza, è necessario fare l'override dei metodi MeasureOverride e ArrangeOverride per mezzo dei quali determineremo lo spazio occupato dai controlli figlio e il relativo posizionamento rispetto ad una o più Attached Property che avremmo definito.

Tuttavia uan semplice implementazione di questo tipo è carente di un aspetto. Il controllo infatti sarà perfetto fintanto chè la sua configurazione non cambia ma non appena una delle Attached Properties cambia ci renderemo conto che il controllo non cambia il suo aspetto di conseguenza. Per fare in modo che un controllo di layout mantenga coerenza con i valori delle Attached Properties occorre fare uso di InvalidateMeasure() e InvalidateArrange(). Questi due metodi fanno in modo che il motore di layout ricalcoli ingombro e posizionamento dei controlli rispetto al pannello sul quale sono invocati.

Per fare in modo che al variare di una proprietà automaticamente si aggiorni il pannello dovremmo intercettare la notifica della Attached Property e chiamare uno dei due metodi in base al fatto che la proprietà coinvolga o meno la fase di Measure o solo quella di Arrange:

   1: public static void Property_Changed(DependencyObject sender, DependencyPropertyChangedEventArgs e)
   2: {
   3:     FrameworkElement element = sender as FrameworkElement;
   4:  
   5:     if (element != null)
   6:     {
   7:         DockPanel panel = element.Parent as DockPanel;
   8:  
   9:         if (panel != null)
  10:             panel.InvalidateArrange();
  11:     }
  12: }

Nel riquadro ho mostrato come arrivare al controllo di layout relativo una AttachedProperty. Non va dimenticato infatti che il DependencyObject passato come argomento non è il controllo di layout stesso, ma bensì il controllo a cui la proprietà si applica. Occorre quindi fare un cast su "FrameworkElement" e cercare nella proprietà Parent il controllo di layout che contiene il controllo che stiamo aggiornando.

La scelta del metodo, sia esso InvalidateArrange o InvalidateMeasure è importante. Infatti il metodo InvalidateMeasure implica anche che venga nuovamente effettuato l'Arrange perciò è molto più pesante in termini di elaborazione. Spesso e volentieri chiamare l'uno o l'altro ha il medesimo effetto perciò la scelta in tal caso dovrebbe ricadere su InvalidateArrange che ha un minor impatto.


Ho appena fatto l'upload della nuova release della mia che aggiunge un nuovo controllo di layout. Il controllo in questione è il DockPanel, mutuato da WPF. Del suo omonimo acquisisce la medesima funzionalità tanto che è possibile incollare un dockpanel da un progetto WPF (o viceversa) e tutto funziona a dovere con l'unico onere di dover aggiornare i namespace.

Ecco un esempio di uso del mio DockPanel:

   1: <UserControl x:Class="Silverlight.DockPanelSample"
   2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
   4:     xmlns:ec="clr-namespace:Elite.Silverlight.Controls;assembly=Elite.Silverlight"
   5:     Width="Auto" Height="Auto">
   6:     <ec:DockPanel x:Name="LayoutRoot" Background="White" LastChildFill="True">
   7:         <Rectangle x:Name="rect1" ec:DockPanel.Dock="Top" Height="50" Fill="Red" Margin="3" />
   8:         <Rectangle x:Name="rect2" ec:DockPanel.Dock="Left" Width="180" Fill="Green" Margin="3" />
   9:         <Rectangle x:Name="rect3" ec:DockPanel.Dock="Right" Width="100" Fill="Blue" Margin="3" />
  10:         <Grid x:Name="fillGrid" ec:DockPanel.Dock="Bottom" Background="Transparent" Margin="3">
  11:             <Button Width="100" Height="50" Content="Click to Change" Click="Button_Click" />
  12:         </Grid>
  13:     </ec:DockPanel>
  14: </UserControl>

Il risultato lo potete vedere a questo se avete Silverlight 2.0 beta 2 installato

Il codice di Windows Presentation Foundation è esattamente lo stesso tranne che per il namespace "ec:" che in silverlight deve essere obbligatoriamente espresso perchè il controllo si trova in una libreria esterna.

Progetto su codeplex: http://www.codeplex.com/silverlight

Area di test: http://silverlight.boschin.it/library


Ho giusto ora trovato il tempo di testare e modificare la mia library per silverlight in modo che funzioni anche con la beta 2. Le modifiche apportate non sono moltissime e il funzionamento finale dei controlli non ha subito alcuna perdita o guadagno. La cosa che mi ha fatto perdere più tempo è che ora le proprietà annidate dei controlli richiedono che venga specificato il namespace così quello che prima era:

   1: <ed:CollectionViewSource x:Name="rssView" Source="{Binding Items, Source={StaticResource dataSource}}" Filter="rssView_Filter">
   2:     <CollectionViewSource.SortDescriptions>
   3:         <ed:SortDescription PropertyName="PublishDate" Direction="Ascending" />
   4:     </CollectionViewSource.SortDescriptions>            
   5: </ed:CollectionViewSource>

ora è diventato

   1: <ed:CollectionViewSource x:Name="rssView" Source="{Binding Items, Source={StaticResource dataSource}}" Filter="rssView_Filter">
   2:     <ed:CollectionViewSource.SortDescriptions>
   3:         <ed:SortDescription PropertyName="PublishDate" Direction="Ascending" />
   4:     </ed:CollectionViewSource.SortDescriptions>            
   5: </ed:CollectionViewSource>

Altra cosa interessante, che promette bene il fatto che la dichiarazione di una DependencyProperty ora non richiede più solamente il callback per la notifica delle modifiche (PropertyChagedCallback) ma invece necessita di una classe PropertyMetadata (come in WPF). Questo apre la strada in futuro all'implementazione piena delle DependencyProperty.

Il progetto su Codeplex ora è aggiornato e contiene anche il MouseDoubleClick manager che avevo tempo fa rilasciato separatamente. Qui trovate l'articolo che ne parla (inglese): Creating a MouseClickManager to handle single and double mouse clicks