.NET

Reactive Extensions (Rx) e Weak events

Dario Santarelli — Sun, 25 Mar 2012 17:15:31 GMT

Come molti sanno, il classico uso degli eventi in C# ha un effetto collaterale: se non viene gestita correttamente la strong reference che si forma tra l’oggetto che espone l’evento (EventSource) e gli oggetti che registrano gli event handlers (EventListeners), si rischia di generare dei memory leak. Infatti, se l’ EventSource ha un ciclo di vita più lungo rispetto agli EventListeners, questi ultimi, se non si deregistrano correttamente dall’evento, vengono tenuti in vita in memoria anche quando non ci sono più riferimenti attivi verso di essi e quindi non vengono reclamati dalla garbage collection fintantoché l’EventSource è attivo.
Nella letteratura esistono diverse tecniche per evitare questa tipologia di memory leak: questo articolo (“Weak Events in C#”) in particolare ne parla in maniera molto chiara e presenta vari approcci per implementare degli “weak event” (listener-side o source-side), ovvero degli eventi a cui un EventListener può registrarsi senza incorrere nel rischio di diventare un memory leak. Le soluzioni ormai più diffuse sfruttano la classe WeakReference , che permette di referenziare un oggetto in modo “debole”, ovvero mantenendolo comunque reclamabile dalla garbage collection.
Giusto per citare un caso noto, WPF introduce un design pattern chiamato “Weak Event”. Esso fondalmente si basa sull’implementazione concreta di un WeakEventManager, ovvero un “dispatcher” centralizzato per ogni evento che vogliamo gestire in modalità weak (molti degli aspetti del data binding di WPF sono implementati tramite weak event). In questo pattern, poi, tutti i listener del weak event devono implementare l’interfaccia IWeakEventListener e quindi registrarsi/deregistrarsi all’evento passando per i metodi statici AddListener() e RemoveLister() che il WeakEventManager mette a disposizione. Come si può intuire, questa soluzione introduce dell’infrastruttura che non sempre è semplice gestire, soprattutto in applicazioni esistenti che fanno un uso complesso e massivo di eventi.
Pochi giorni fa ho provato quindi ad affrontare la questione attraverso il Reactive Extensions (Rx) framework e devo dire che le soluzioni che si possono trovare sono alquanto iteressanti e flessibili. Vorrei mostrarne una in particolare.

Supponiamo di avere una classe EventSource che espone un evento pubblico Event.

public class EventSource 
{ 
    public event EventHandler Event;

    public void FireEvent()     
    {         
       EventHandler handler = Event;         
       if (handler != null) handler(this, EventArgs.Empty);     
    }  

    public int GetEventListenersCount()     
    {         
      return Event.GetInvocationList().Count();     
    } 
}

Per fini di test esponiamo anche un metodo FireEvent() che scatena l’evento ed un metodo GetEventListenersCount() che ci restituisce il numero di listener correntemente registrati all’evento. Creiamo quindi uno StrongEventListener, ovvero un listener che crea una strong reference all’EventSource tramite la classica sintassi di registrazione ad un evento. Poichè questo oggetto non effettua esplicitamente la deregistrazione, diventa un potenziale memory leak.

public class StrongEventListener 
{             
  public StrongEventListener(EventSource eventSource)     
  {        
     eventSource.Event += HandleEvent;     
  }

  private void HandleEvent(object sender, EventArgs eventArgs)     
  {        
    Console.WriteLine("StrongEventListener> Event Received!");     
  } 
}

Per riuscire a implementare la corrispettiva versione weak (WeakEventListener) in modo semplice e veloce è possibile sfruttare le Reactive Extensions (Rx).
Anzitutto partiamo dal risultato che vorremmo ottenere, ovvero un oggetto che possa registrarsi all’evento del nostro EventSource in modalità weak, ovvero senza correre il rischio di diventare un potenziale memory leak:

public class WeakEventListener 
{             
  public WeakEventListener(EventSource eventSource)     
  {                                                                         
    eventSource.ObservableEvent()                    
               .WeakSubscribe(this, (me, e) => me.HandleEvent(e.Sender, e.EventArgs));     
  }      

  private void HandleEvent(object sender, EventArgs eventArgs)     
  {         
    Console.WriteLine("WeakEventListener> Event Received!");    
  }    
}

Per ottenere questo risultato le fasi da seguire sono due:

1) Anzitutto, per leggibilità creiamo un extension method di EventSource che ne converte l’evento in un IObservable grazie al classico metodo Observable.FromEventPattern(...) di Rx. Dietro le quinte viene creato e restituito un oggetto che sarà in grado di gestire la registrazione e la deregistrazione all’evento, aggiungendo e rimuovendo gli event handlers (strong references) verso l’istanza di EventSource in esame.

public static IObservable<EventPattern<EventArgs>> ObservableEvent(this EventSource eventSource) 
{    
  return Observable.FromEventPattern<EventHandler, EventArgs>(h => (s, e) => h(s, e),
                                                              h => eventSource.Event += h,
                                                              h => eventSource.Event -= h); 
}

2) Creiamo un extension method di IObservable<T> che chiamiamo WeakSubscribe. Esso ci permette di passare come argomento un oggetto subscriber ed una action da eseguire a fronte di una notifica (onNext) da parte della sequenza osservabile, in modo tale che il subscriber possa essere notificato tramite l’action in modalità “weak”, ovvero senza mantenere degli strong reference con la sequenza osservabile.

public static IDisposable WeakSubscribe<T, TSubscriber>(this IObservable<T> observable,
                                                        TSubscriber subscriber, Action<TSubscriber, T> action) 
                                                        where TSubscriber : class 
{     
   if (action.Target != null) throw new ArgumentException("action target must NOT refer a class instance, " +
                                                          "in order to avoid a strong reference to target");       
   var subscriberWeakReference = new WeakReference(subscriber);      
   IDisposable subscription = null;     
   Action<T> onNext = item =>                         
                      {                             
                         var subscriberObj = subscriberWeakReference.Target as TSubscriber;
                         if (subscriberObj != null) action(subscriberObj, item);
                         else subscription.Dispose();
                      };
   subscription = observable.Subscribe(onNext);
   return subscription; 
}

Qui il gioco si fa interessante ed anche abbastanza complicato: come si osserva, anzitutto il prerequisito è che venga mantenuta una weak reference sul subscriber tramite una WeakReference. Dopodiché, con una lambda definiamo l’onNext di un AnonymousObserver della sequenza osservabile, il quale ad ogni notifica controlla se il subscriber è ancora vivo (subscriberWeakReference.Target != null). In caso positivo, viene eseguita l’action che fa da “passacarte” tra l’observer ed il subscriber, altrimenti viene chiamata la Dispose() sulla subscription dell’observer (il che nel nostro esempio si traduce nella deregistrazione dall’evento dell’EventSource (eventSource.Event -= h)).

Ora arriva il trucco: per evitare che il subscriber diventi un potenziale memory leak, action.Target non deve riferire direttamente l’istanza del subscriber, altrimenti significherebbe che il chiamante del nostro metodo sta passando il puntatore this su action.Target (in altre parole, action.Target == null significa che il delegato action invoca un metodo statico e non di istanza). La action quindi deve essere una lambda che chiama metodi di istanza del subscriber tramite il riferimento che essa stessa fornisce come parametro, piuttosto che catturare il riferimento implicito a this:

.WeakSubscribe(this, (me, e) => this.HandleEvent(e.Sender, e.EventArgs)); // –> FAIL (ArgumentException)
.WeakSubscribe(this, (me, e) => me.HandleEvent(e.Sender, e.EventArgs)); // –> OK

Questo controllo ci garantisce che la lambda che poi specifichiamo sull’onNext non generi una strong reference verso il subscriber tramite l’action. Ciò renderebbe il subscriber un potenziale memory leak. Capiamo meglio il perché: nel nostro esempio, avendo usato un Observable.FromEventPattern, quando chiamiamo la observable.Subscribe(onNext) scateniamo internamente la registrazione all’evento dell’EventSource (h => eventSource.Event += h). h è un EventHandler che tramite una closure interna di Rx crea una strong reference tra l’EventSource e la onNext. La onNext a sua volta mantiene uno strong reference verso la action. Quindi, a cascata, se l’action che usiamo nella lambda fosse un metodo di istanza del subscriber, l’istanza stessa del subscriber diventerebbe un potenziale memory leak poiché manterrebbe uno strong reference attivo nella subscription.

Conclusioni

Il grande vantaggio di questa soluzione è che può introdurre in progetti esistenti una semplice gestione thread-safe di weak events al costo di una banale AddReference a System.Reactive.dll. Infatti, a differenza del “Weak Event Pattern”, questo approccio ha praticamente impatto zero sull’ infrastruttura.
L’unico svantaggio invece è che la subscription.Dispose() avviene eventualmente sull’ onNext della sequenza osservabile, il che tradotto nel nostro esempio significa che la deregistrazione dei delegati dall’evento dell’EventSource avviene eventualmente SOLO a fronte dello scatenare tale evento. Di conseguenza, la onNext che usiamo per fare observable.Subscribe(onNext) potrebbe confluire in dei memory leak fintantoché l’evento non viene scatenato dall’EventSource (come ho provato a dimostrare con lo Unit test qua sotto). I nostri WeakEventListener invece vivono felicemente il loro ciclo di vita sicuri di non diventare dei memory leak, poiché ovviamente non sono loro a registrasi direttamente all’evento dell’EventSource.
In conclusione, prima di considerare questa implementazione e comunque in generale, cerchiamo sempre di valutare attentamente qual’è il ciclo di vita degli EventListener rispetto agli EventSource :).

[TestMethod] 
public void WeakEvent_With_Rx() 
{    
   var eventSource = new EventSource();     
   var strongListener = new StrongEventListener(eventSource);     
   var weakListener = new WeakEventListener(eventSource);      

   Assert.AreEqual(2, eventSource.GetEventListenersCount());      

   eventSource.FireEvent();     
   // OUTPUT:
   // StrongEventListener> EventReceived!     
   // WeakEventListener> EventReceived!                 

   strongListener = null;     
   weakListener = null;      

   GC.Collect();     
   GC.Collect();     
   GC.WaitForPendingFinalizers();     
   GC.Collect();

   Assert.AreEqual(2, eventSource.GetEventListenersCount()); 
   // 2 Memory Leak 
   // - StrongEventListener has NOT been garbage collected (Obviously)
   // - WeakEventListener has been garbage collected! 
   // – onNext action delegate is still a memory leak
   

   eventSource.FireEvent();     
   // OUTPUT: 
   // StrongEventListener> EventReceived!      

   Assert.AreEqual(1, eventSource.GetEventListenersCount()); 
   // 1 Memory Leak (StrongEventListener (Obviously)) 
}

HTH

Spring.NET REST Client

Dario Santarelli — Sat, 10 Dec 2011 23:29:37 GMT

Sono sempre stato un appassionato di soluzioni REST-ful e la nuova versione di Spring.NET REST Client costituisce a mio avviso un ottimo strumento per implementare il client di un qualunque servizio REST in maniera molto semplice e potente, non solo su framework 2.0/3.5/4.0, ma anche su Silverlight 3 e 4, Compact Framework 2.0/3.5 e Windows Phone 7.
Queste API client fanno capo ad una classe di riferimento chiamata RestTemplate. Si tratta a tutti gli effetti di un helper che astrae in maniera molto semplice ognuno dei sei principali metodi HTTP che possono essere supportati da un servizio REST (GET, POST, HEAD, OPTIONS, PUT, DELETE). I metodi di questa classe infatti seguono una “naming convention” in cui la prima parte del metodo indica il verbo HTTP della richiesta e la seconda parte esplicita la rappresentazione della risposta, la quale può essere ad esempio un oggetto deserializzato o l'Uri di una risorsa.
Ecco un esempio:

 var newCustomer = new Customer { FirstName = "Dario", LastName = "Santarelli" };

 RestTemplate restTemplate = new RestTemplate("http://localhost");

 // POST (Creates) the Customer resource  
 Uri newCustomerUri = restTemplate.PostForLocation("/myRestService/Customers", newCustomer);

 // GET the Customer resource 
 Customer customerObj = restTemplate.GetForObject<Customer>(newCustomerUri);  
 HttpResponseMessage<Customer> customerMsg = restTemplate.GetForMessage<Customer>(newCustomerUri);
 string customerBodyString = restTemplate.GetForObject<string>(newCustomerUri); 
 byte[] customerBodyBytes = restTemplate.GetForObject<byte[]>(newCustomerUri);

 // DELETE the Customer resource
 restTemplate.Delete(newCustomerUri);

Anzitutto si chiede al servizio REST di creare una risorsa Customer tramite il metodo PostForLocation(), il quale restituisce la Uri della risorsa appena creata, che possiamo quindi accedere con una GET in varie forme: tramite il metodo GetForObject<T>() potremmo cercare di deserializzare la risposta HTTP direttamente in un oggetto Customer oppure potremmo ottenerne la rappresentazione raw (es. XML, JSON etc.) specificando il tipo T come string. Infine, cancelliamo la risorsa tramite una DELETE. Da notare come GetForObject<T>() e GetForMessage<T>() dietro le quinte eseguano entrambi due GET HTTP ma ritornano nel primo caso un oggetto mentre nel secondo caso un message-wrapper di tipo HttpResponseMessage che espone informazioni aggiuntive come StatusCode e Header. Per questi metodi esistono anche degli overload con il suffisso “Async” per gestire appunto pattern di invocazione asincrona (indispensabili su Silverlight e Windows Phone).

Per completezza, c’è da dire che per effettuare le chiamate REST si può utilizzare anche un metodo alternativo Exchange() che permette di interagire direttamente con i verbi HTTP ed oggetti di tipo HttpEntity (da specifica HTTP 1.1, section 7) eventualmente per impostare degli header custom nella richiesta. Ad esempio...

HttpEntity requestEntity = new HttpEntity(); 
requestEntity.Headers["headerKey"] = "headerValue";

HttpResponseMessage<Customer> response = restTemplate.Exchange<Customer>("/myRestService/Customers/{id}", 
                                                                         HttpMethod.GET, requestEntity, 1);

string responseHeader = response.Headers["responseHeaderKey"]; 
Customer customer = response.Body; 
HttpStatusCode statusCode = response.StatusCode; 
string statusDescription = response.StatusDescription;

Per deserializzare correttamente il tipo T specificato ad esempio nei metodi GetForObject<T>() e GetForMessage<T>(), il RestTemplate usa internamente una classe chiamata MessageConverterResponseExtractor<T> che è in grado di convertire una risposta HTTP in un'istanza di tipo T tramite dei MessageConverters. A mio avviso la vera potenza di RestTemplate sta proprio in questa parte, ovvero nel fatto che può essere facilmente configurato per supportare diversi MessageConverters, delle classi il cui ruolo è convertire oggetti in messaggi HTTP e viceversa in base al media type. Le strategie di conversione sono veramente tante e possono sfruttare sia serializer “standard” del framework come XmlSerializer, DataContractSerialier, DataContractJsonSerializer piuttosto che altre strategie di conversione custom (es. basate su SyndacationFeed e SyndicationItem per feed ATOM e RSS piuttosto che su Json.NET per accedere ai valori JSON in modo diretto etc.). Ad esempio, possiamo fare in modo che i messaggi HTTP con media type application/json vengano gestiti dal DataContractJsonSerializer del framework semplicemente scrivendo…

RestTemplate restTemplate = new RestTemplate("http://localhost");
restTemplate.MessageConverters.Add(new JsonHttpMessageConverter());

N.B.: i MessageConverters caricati per default cambiano in base al target framework di compilazione. Tuttavia, tutti i converter devono implementare l’interfaccia IHttpMessageConverters, quindi possiamo facilmente implementarcene uno custom e renderlo operativo in modo molto semplice ed intuitivo.

Oltre ai MessageConverters , Spring.NET REST Client supporta anche altre features molto interessanti:

RestTemplate espone una proprietà RequestFactory che offre la possibilità di personalizzare il meccanismo di generazione delle richieste HTTP. Per default questa proprietà viene valorizzata con un’ istanza della classe WebClientHttpRequestFactory, che a sua volta internamente usa la classe HttpWebRequest del framework. Ciò offre gratuitamente la possibilità di supportare proxy HTTP ad esempio.
Altra proprietà interessante di RestTemplate è RequestInterceptors, ovvero una collezione di interceptors che ci permette di inserirci sia in modo sincorno che in modo asincrono in un qualunque punto della pipeline di crezione ed esecuzione della richiesta HTTP, magari per modificare la richiesta al volo piuttosto che per iniettare gestioni custom di error management, logging, etc.

Technorati tags: Spring.NET,REST

[AOP] UI e dintorni con PostSharp

Dario Santarelli — Sun, 16 Oct 2011 21:29:26 GMT

L’AOP ormai sta diventando un paradigma di programmazione sempre più diffuso specialmente nel mondo .NET dove strumenti come PostSharp, DotSpect (Compile-time static injection) e Spring.NET, Castle Windsor, Enterprise Library Policy Injection Application Block (Dynamic Proxy) rendono sempre più semplice la gestione dei “cross-cutting concerns” che provengono dal mondo Object-Oriented. Personalmente sono stato sempre un entusiasta di PostSharp e in questo post vorrei citare un paio di aspect che ho sempre valutato positivamente nella gestione di codice “vicino” alla UI, specialmente nel mondo Windows Forms e WPF.

Il primo aspect ha a che vedere con il DataBinding. Sappiamo tutti come implementare l’interfaccia INotifyPropertyChanged sia noioso ed anche a fronte di snippet per velocizzare il processo di scrittura il risultato che otteniamo si allontana dall’idea di avere codice (almeno) esteticamente “impeccabile”. Per questo l’aspect che PostSharp introduce a riguardo è tanto semplice quanto geniale in quanto permette, tramite un banale attributo, di agganciare l’implementazione dell’interfaccia INotifyPropertyChanged ad un oggetto ed eventualmente alle sue specializzazioni. Ad esempio, se definissimo un oggetto Customer nel seguente modo…

[NotifyPropertyChanged] 
public class Customer 
{

   public string Name { get; set; }   
   public string Surname { get; set; }   
   public string Email { get; set; }
   ...

…tramite l’attributo [NotifyPropertyChanged] impostato a livello di classe otteniamo nell’assembly di output una injection della solita implementazione dell’interfaccia INotifyPropertyChanged. L’ implementazione dell’aspect, riportata anche nel sito di PostSharp, è la seguente…

[Serializable] 
[IntroduceInterface(typeof(INotifyPropertyChanged),OverrideAction = InterfaceOverrideAction.Ignore)] 
[MulticastAttributeUsage(MulticastTargets.Class, Inheritance = MulticastInheritance.Strict)] 
public class NotifyPropertyChangedAttribute : InstanceLevelAspect, INotifyPropertyChanged 
{           
  [ImportMember("OnPropertyChanged", IsRequired = false)]    
   public Action<string> OnPropertyChangedMethod;           

  [IntroduceMember(Visibility = Visibility.Family, 
                   IsVirtual = true, 
                   OverrideAction = MemberOverrideAction.Ignore)]    
  public void OnPropertyChanged(string propertyName)    
  {      
    if (this.PropertyChanged != null)       
    {          
      this.PropertyChanged(this.Instance, new PropertyChangedEventArgs(propertyName));       
    }    
  }           

  [IntroduceMember(OverrideAction = MemberOverrideAction.Ignore)]    
  public event PropertyChangedEventHandler PropertyChanged;            

  [OnLocationSetValueAdvice]    
  [MulticastPointcut(Targets = MulticastTargets.Property, Attributes = MulticastAttributes.Instance)]    
  public void OnPropertySet(LocationInterceptionArgs args)    
  {                   
    if (args.Value == args.GetCurrentValue()) return;       
    args.ProceedSetValue();       
    this.OnPropertyChangedMethod.Invoke(args.Location.Name);    
  } 
}

Il codice è abbastanza autoesplicativo. La feature degna di nota in particolare è la possibilità di estendere automaticamente questo aspect anche alle classi ereditate semplicemente impostando a livello di classe MulticastAttributeUsage.Inheritance = MulticastInheritance.Strict.

Un altro aspect che ho sempre ritenuto molto utile ha a che vedere con il thread dispatching, ovvero con la gestione dell’esecuzione di un metodo sul thread dell’interfaccia piuttosto che su un worker thread (es. in WPF controllando il thread associato al DispatcherSynchronizationContext corrente). Anche in questo ambito PostSharp permette di definire due attributi [OnGuiThread] e [OnWorkerThread] a livello di metodo, che iniettano la comune logica di controllo del SynchronizationContext in modo da forzare l’esecuzione del metodo rispettivamente sul thread dell’interfaccia o su un thread secondario (link al codice sorgente).
Come risultato, diventa molto semplice applicare questi aspect anche su codice legacy.

[OnWorkerThread] 
void SaveCustomer() 
{    
  Customer.Save();    
  ShowMessage("Customer Saved!");

}  

[OnGuiThread] 
void ShowMessage(string message) 
{ 
  MessageBox.Show(message); 
}

Il pacchetto di istallazione di PostSharp (disponibile anche su NuGet) aggiunge a Visual Studio due toolbox veramente utili: l’Aspect Browser che ci permette navigare su quelli che sono gli aspect utilizzati nell’intera solutione e l’ Affected code toolbox che ci riassume tutte le classi e i metodi che sono soggetti ad aspects. Inoltre, l’intellisense viene esteso in modo da visualizzare dei summary sulle static injections che gli aspect introducono nell’assembly. Ad esempio, per quanto riguarda il precedente aspect NotifyPropertyChanged, i tooltip che otteniamo sono i seguenti:

Technorati tags: AOP,WPF,GUI

[WPF] Drag and Drop con Rx

Dario Santarelli — Thu, 25 Aug 2011 17:27:33 GMT

Le Reactive Extensions (Rx) del framework .NET sono un set di API dedicate a ciò che nella letteratura prende il nome di “reactive programming”. Rx nasce dalla distinzione di due scenari:

pull: un programma agisce estraendo dati dall’ambiente in modo interattivo (es. un’iterazione su una sequenza di dati prelevati dall’ambiente).
push: un programma reagisce ai dati che l’ambiente “spinge” verso di esso (es. un event-handler è un esempio di reazione in uno scenario push)

Data questa distinzione, Rx si basa sulla dualità tra il pattern Iterator e il pattern Observer. In breve, il pattern Observer in uno scenario push è analogo al pattern Iterator in uno scenario pull. Nel pattern Iterator, infatti, l’Iterator è l’attore che accede all'insieme degli elementi di un contenitore in modo interattivo. Il pattern Observer può essere interpretato in modo equivalente se si considera che l’ambiente genera spontaneamente i singoli elementi e li spinge verso il programma, ad esempio attraverso eventi. Quando uno stesso evento viene scatenato più volte, di fatto viene prodotta una sequenza di elementi di tipo “evento”, il che rende ovvia a questo punto la relazione con il pattern Iterator. Rx è stato introdotto quindi per mettere a disposizione degli sviluppatori un modello di programmazione push-based, duale rispetto al ben più conosciuto pull-based, pur non aggiungendo nulla di nuovo rispetto a quest’ultimo. Semplicemente, il modello push-based offre modi diversi se non più semplici per approcciare problemi comuni legati alla programmazione asincrona ed alla composizione di eventi.

Rx implementa il pattern Observer tramite le due interfacce IObserver<T> e IObservable<T>, corrispondenti a IEnumerator/IEnumerable del pattern Iterator. IObservable<T> costituisce una sorta di “collezione asincrona” di elementi (generati in momenti diversi quando si parla di eventi). La relazione tra IObservable<T> e IObserver<T> si trova nel fatto che ad un IObservable<T> è possibile registrare uno o più IObserver<T> (tramite il metodo IObservable<T>.Subscribe(IObserver<T> observer) ). IObserver<T> possiede tre metodi: OnNext(…), OnCompleted() e OnError(…). Essi vengono invocati dall’ IObservable<T> rispettivamente quando possiede nuovi dati, completa un’operazione e si verifica un errore.

Drag and Drop e LINQ-to-events

Nella pratica, uno dei (classici) casi in cui Rx mostra la sua potenza è nell’implementazione del Drag and Drop di un oggetto grafico. Infatti, a differenza delle comuni soluzioni event-based che intercettano eventi e sincronizzano variabili di stato con lo scopo di aggiornare correttamente la posizione dell’oggetto grafico, le Reactive Extensions consentono di convertire gli eventi .NET di interesse in sequenze osservabili che possiamo interrogare tramite query LINQ. Vediamo un esempio concreto. Uno dei classici approcci per implementare il drag and drop in WPF (come in Windows Froms o Silverlight) si basa sostanzialmente sulla sincronizzazione di tre eventi logici di un oggetto grafico: MouseDown, MouseUp e MouseMove. Nello specifico, in WPF, supponendo di avere il seguente XAML…

<Window x:Class="WebRequestWithRxSample.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="MainWindow" Loaded="Window_Loaded">

    <Canvas>

        <StackPanel Name="myPanel">

            <Rectangle Fill="Maroon" Width="100" Height="100" />

        </StackPanel>

    </Canvas>

</Window>

… per gestire il drag and drop dello StackPanel “myPanel” potremmo sincronizzarne i tre eventi MouseLeftButtonDown, MouseLeftButtonUp e MouseMove in modo da gestirne il riposizionamento nel Canvas per ogni evento MouseMove compreso temporalmente tra un MouseLeftButtonDown ed un MouseLeftButtonUp. Quindi, ogni volta che si verifica l’evento MouseLeftButtonDown, per ogni successivo evento MouseMove aggiorniamo la posizione dello StackPanel all’interno del Canvas, tenendo conto della posizione del cursore relativa all’angolo in alto a sinistra dello StackPanel. Il tutto finché non viene scatenato l’evento MouseLeftButtonUp.

Point relativeMouseDownPosition = new Point();

myPanel.MouseLeftButtonDown += (s, e) =>

{

if (myPanel.CaptureMouse())

{

relativeMouseDownPosition = e.GetPosition(myPanel);

}

};

myPanel.MouseLeftButtonUp += (s, e) => { myPanel.ReleaseMouseCapture(); };

myPanel.MouseMove += (s, e) =>

{

if (myPanel.IsMouseCaptured)

{

Point absoluteMousePosition = e.GetPosition(this);

Point newPanelPosition = new Point(absoluteMousePosition.X - relativeMouseDownPosition.X,

absoluteMousePosition.Y - relativeMouseDownPosition.Y);

Canvas.SetLeft(myPanel, newPanelPosition.X);

Canvas.SetTop(myPanel, newPanelPosition.Y);

}

};

Il codice qua sotto implementa la stessa cosa tramite Rx. All’inizio la sintassi può sembrare un po’ meno chiara, ma con il tempo ci si accorge di come in realtà sia molto più leggibile e soprattutto manutenibile rispetto al codice precedente, in quanto si basa su un modello “push” query-based.

 var relativeMouseDownPositions = Observable.FromEventPattern<MouseButtonEventArgs>(myPanel, "MouseLeftButtonDown")

                                      .Do(evt => myPanel.CaptureMouse())

                                             .Select(evt => evt.EventArgs.GetPosition(myPanel));

 var mouseUpEvents = Observable.FromEventPattern<MouseButtonEventArgs>(myPanel, "MouseLeftButtonUp")

                           .Do(evt => myPanel.ReleaseMouseCapture());

 var absoluteMousePositions = Observable.FromEventPattern<MouseEventArgs>(myPanel, "MouseMove") 
                                        .Select(evt => evt.EventArgs.GetPosition(this));

 IObservable<Point> dragPoints = from relativeMouseDownPosition in relativeMouseDownPositions

                                 from absoluteMousePosition in absoluteMousePositions.TakeUntil(mouseUpEvents)

                                 select new Point(absoluteMousePosition.X - relativeMouseDownPosition.X,

                                                  absoluteMousePosition.Y - relativeMouseDownPosition.Y);

 

 dragPoints.ObserveOn(SynchronizationContext.Current).Subscribe(point =>

    Canvas.SetLeft(myPanel, point.X);

    Canvas.SetTop(myPanel, point.Y);

});

Alcune considerazioni

La prima cosa che salta all’occhio è come sia possibile convertire un evento .NET in una sequenza osservabile tramite il metodo Observable.FromEventPattern(…) , il quale permette di specificare il tipo di EventArgs dell’evento, l’oggetto che espone l’evento da convertire ed il nome dell’evento. In particolare, la seconda riga di codice denota come sia possibile convertire l’evento MouseLeftButtonUp dello StackPanel in una sequenza osservabile di tipo IObservable<EventPattern<MouseButtonEventArgs>>.
Rx definisce un suo set di extension methods per comporre sequenze osservabili nello stesso modo in cui LINQ to Objects compone sequenze enumerabili. Ad esempio, il metodo Observable.TakeUntil<TSource, TOther>(…) ritorna tutti gli elementi della sequenza osservabile sorgente finché l’altra sequenza osservabile non produce un valore. Nel nostro esempio, questo extension method è stato usato per filtrare gli eventi MouseMove tra un evento MouseLeftButtonDown ed un MouseLeftButtonUp.
Il metodo Observable.ObserveOn<TSource>(…) permette di fare in modo che le notifiche asincrone agli observer vengano effettuate su un thread o uno scheduler specificato. Nel mondo WPF, come in altre piattaforme che supportano un SynchronizationContext, per evitare eccezioni cross-thread quando si interagisce con la UI di solito si interagisce con il contesto di sincronizzazione tramite la chiamata ObserveOn(SynchronizationContext.Current) che in WPF in particolare è costituito da un oggetto di tipo DispatcherSynchronizationContext.

Note di installazione: se stiamo lavorando su Visual Studio 2010, il modo più veloce per integrare Rx nel nostro progetto è NuGet. Digitando “Rx” sulla textbox di ricerca dovremmo ottenere la seguente schermata. In particolare, il package Rx-Main referenzia l’assembly System.Reactive.dll mentre il package Rx-Testing referenzia l’assembly Microsoft.Reactive.Testing.dll.

System.Collections.Concurrent: via tutti i lock!

Dario Santarelli — Sun, 03 Jul 2011 15:31:01 GMT

Per garantire la thread-safety nell’accesso a collezioni di oggetti in contesti multi-thread, fino ad oggi siamo stati abituati ad utilizzare i più svariati meccanismi di lock, magari prevedendo diversi livelli di granularità.
In questo ambito il framework 4.0 fornisce il namespace System.Collections.Concurrent che offre un set di classi thread-safe che si possono usare al posto di quelle di System.Collections e System.Collections.Generic.

Anzitutto, salutiamo con una certa soddisfazione la classe ConcurrentDictionary<TKey, TValue>, versione thread-safe della classe Dictionary.

Vengono forniti poi tre oggetti che implementano IProducerConsumerCollection<T>, un’interfaccia che definisce due metodi TryAdd e TryTake per scenari “producer/consumer”, ovvero scenari in cui più thread aggiungono o rimuovono elementi dalla stessa collection in modo concorrente. Gli oggetti in questione sono:

ConcurrentBag<T>: implementazione thread-safe di una collezione non ordinata di elementi (eventualmente duplicabili). Questo oggetto è particolarmente ottimizzato per scenari in cui lo stesso thread produce e consuma gli elementi del bag.
ConcurrentQueue<T>: versione concorrente di una coda FIFO. A differenza di quanto si sente dire spesso erroneamente, questa classe non costituisce un semplice wrapper della classe Queue ( tipo Queue.Synchronized() ), bensì qualcosa di più potente e performante che internamente fa uso di meccanismi di sincronizzazione e validazione più ottimizzati basati sulle classi SpinWait e Interlocked.
ConcurrentStack<T>: versione concorrente di uno stack LIFO.

Infine abbiamo l’oggetto BlockingCollection<T>, che di fatto costituisce una classe di più alto livello. Una BlockingCollection è a tutti gli effetti un wrapper di un oggetto che implementa l’interfaccia IProducerConsumerCollection<T> (come i sopra citati ConcurrentBag<T>, ConcurrentQueue<T> e ConcurrentStack<T>). Ciò significa che di suo non implementa un meccanismo di storage interno, bensì introduce soltanto la logica di gestione thread-safe per scenari producer/consumer. Infatti, se non forniamo al costruttore un IProducerConsumerCollection, per default viene istanziata internamente una ConcurrentQueue (FIFO). Poiché la BlockingCollection è utile come buffer di scambio condiviso tra più thread, essa fornisce gratis anche dei meccanismi di blocco (metodi Add() e Take()) grazie ai quali possiamo fare in modo che i thread “producer” si blocchino se la collezione è piena (aspettando quindi che almeno un elemento venga rimosso dalla collezione) oppure viceversa che i thread “consumer” si blocchino quando cercano di rimuovere un elemento dalla collection interna vuota.

Validare documenti XHTML con XmlPreloadedResolver

Dario Santarelli — Wed, 20 Apr 2011 21:56:22 GMT

Una classe molto interessante che ci fornisce il Framework 4.0 è XmlPreloadedResolver. Come si intuisce dal nome, il suo scopo è quello di risolvere risorse pre-caricate che possono essere referenziate da un’istanza XML. Questa funzionalità è veramente comoda quando non è desiderabile creare chiamate di rete per reperire risorse esterne (es. un DTD) o quando si lavora offline, ricevendo evidenti benefici anche sulle performance.
Il plus risiede nel fatto che nell’assembly System.Xml.Utils sono già “embeddati” i DTD relativi allo standard XHTML 1.0 Transitional, Strict e Frameset (incluse le entities speciali), nonché allo standard RSS 0.91...

Continua >>

Validare documenti XHTML con XmlPreloadedResolver

Dario Santarelli — Wed, 20 Apr 2011 21:23:22 GMT

Una classe molto interessante che ci fornisce il Framework 4.0 è XmlPreloadedResolver. Come si intuisce dal nome, il suo scopo è quello di risolvere risorse pre-caricate che possono essere referenziate da un’istanza XML. Questa funzionalità è veramente comoda quando non è desiderabile creare chiamate di rete per reperire risorse esterne (es. un DTD) o quando si lavora offline, con evidenti benefici sulle performance. Un esempio concreto di utilizzo di questa classe potrebbe intervenire nella validazione di contenuti XHTML 1.x, magari all’interno di un HttpModule ASP.NET… tipo questo.
Il plus risiede nel fatto che nell’assembly System.Xml.Utils sono già “embeddati” i DTD dello standard XHTML 1.0 Transitional, Strict e Frameset (incluse le entities speciali), nonché dello standard RSS 0.91.

Insistendo sul discorso della validazione di contenuti XHTML precaricati, a titolo esemplificativo ho provato a realizzare una semplice classe XhtmlValidator, che espone un metodo Validate() (la validazione del contenuto) ed il relativo Resolver (che deve reperire l’eventuale DOCTYPE esterno da processare nella validazione).
N.B.: Per versioni del Framework precedenti alla 4.0, possiamo ovviamente decidere di svilupparci in casa un Resolver custom (ereditando la classe XmlResolver) che sostanzialmente assolva lo stesso compito.

public class XhtmlValidator

{

public XmlResolver Resolver { get; set; }

public XhtmlValidator() { }

public XhtmlValidator(XmlResolver resolver) { Resolver = resolver; }

public bool Validate(string xhtml, out List<XmlValidationError> errors)

{

List<XmlValidationError> validationErrors = new List<XmlValidationError>();

XmlReaderSettings settings = new XmlReaderSettings();

settings.ValidationType = ValidationType.DTD;

settings.ValidationFlags = XmlSchemaValidationFlags.ReportValidationWarnings;

settings.DtdProcessing = DtdProcessing.Parse;

if (Resolver != null) settings.XmlResolver = Resolver;

settings.ValidationEventHandler += (s, e) => validationErrors.Add(new XmlValidationError(e.Message,e.Severity));

Stream xhtmlStream = new MemoryStream(UTF8Encoding.UTF8.GetBytes(xhtml));

using (XmlReader xmlReader = XmlReader.Create(xhtmlStream, settings))

{

try { while (xmlReader.Read()) ; }

catch (Exception ex) { validationErrors.Add(new XmlValidationError(ex.Message, XmlSeverityType.Error)); }

}

errors = validationErrors;

return (validationErrors.Count == 0);

}

public class XmlValidationError

{

public string Message { get; private set; }

public XmlSeverityType Severity { get; private set; }

public XmlValidationError(string message, XmlSeverityType severity)

{

Message = message;

Severity = severity;

}

La classe XmlValidationError è stata introdotta semplicemente come “astrazione” rispetto a due tipologie di notifiche: quelle derivanti dal parsing della struttura del documento (le Read() dell’XmlReader) e quelle derivanti dal processo di validazione (i ValidationEvent scatenati dalla classe XmlReaderSettings).
Vediamo quindi come possiamo sfruttare XmlPreloadedResolver in questo contesto tramite una banale applicazione Console…

static void Main(string[] args)

{

////GOOD XHTML 1.0 (conformant)

//string xhtml = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">" +

// "<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"it\" lang=\"it\">" +

// "<head><title>GOOD XHTML 1.0 Document</title></head><body><p>A paragraph here is OK</p></body></html>";

//// BAD XHTML 1.0 (non conformant)

string xhtml = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">" +

"<html xmlns=\"http://www.w3.org/1999/xhtml\" xml:lang=\"it\" lang=\"it\">" +

"<head><title>BAD XHTML 1.0 Document</title></head><body><span>A span here is NOT OK</span></body></html>";

XmlPreloadedResolver resolver = new XmlPreloadedResolver(XmlKnownDtds.Xhtml10);

XhtmlValidator validator = new XhtmlValidator(resolver);

List<XmlValidationError> validationErrors = new List<XmlValidationError>();

bool success = validator.Validate(xhtml, out validationErrors);

if (success) Console.WriteLine("Success");

else

{

Console.WriteLine("Errors: " + validationErrors.Count.ToString());

foreach (XmlValidationError error in validationErrors) Console.WriteLine(string.Format("- Message: {0} (Severity: {1})", error.Message, error.Severity));

}

Eseguendo il codice precedente senza essere connessi alla rete, si osserva come il XmlPreloadedResolver faccia il suo lavoro e ci permetta di validare il contenuto XHTML 1.0 Strict di esempio tramite il relativo DTD embeddato nell’assembly System.Xml.Utils.

Domanda: E se volessimo usare XmlPreloadedResolver su documenti XHTML 1.1?
Ebbene, sembra che la strada dello standard XHTML 1.1 non sia stata battuta, forse per la forte modularizzazione della specifica o forse per l'effettiva scarsa adozione dello standard nel web. Fatto sta che in questo contesto non abbiamo "known" DTD pre-caricati (neanche quelli “core” definiti nel DTD principale), quindi dobbiamo pre-caricarceli “a mano” in questo modo…

XmlPreloadedResolver xmlPreloadedResolver = new XmlPreloadedResolver(XmlKnownDtds.Xhtml10);
xmlPreloadedResolver.Add(new Uri("http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"), File.ReadAllBytes("C:\\...\\xhtml11.dtd"));
xmlPreloadedResolver.Add(new Uri("http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-inlstyle-1.mod"), File.ReadAllBytes("C:\\...\\xhtml-inlstyle-1.mod"));
xmlPreloadedResolver.Add(new Uri("http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-text-1.mod"), File.ReadAllBytes("C:\\...\\xhtml-text-1.mod"));
xmlPreloadedResolver.Add(new Uri("http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-hypertext-1.mod"), File.ReadAllBytes("C:\\...\\xhtml-hypertext-1.mod"));
xmlPreloadedResolver.Add(new Uri("http://www.w3.org/TR/xhtml-modularization/DTD/xhtml-list-1.mod"), File.ReadAllBytes("C:\\...\\xhtml-list-1.mod"));
etc...

Tag di Technorati: XHTML,.NET,C#,DTD

Dictionary persistenti

Dario Santarelli — Sat, 23 Oct 2010 01:14:42 GMT

In questo post ho cercato di riportare la mia esperienza nella modellizzazione di dictionary persistenti in un progetto reale. In particolare, viene descritta una soluzione in cui è stato ritenuto necessario definire un livello di astrazione che permettesse di derivare implementazioni concrete di dictionary persistenti su file system.

Leggi il post

Dictionary persistenti

Dario Santarelli — Sat, 23 Oct 2010 00:37:20 GMT

In un mio progetto avevo bisogno di rendere persistenti dei Dictionary al fine di recuperarne lo stato al riavvio dell’applicazione. Poiché avevo bisogno di gestire un livello di astrazione rispetto allo storage utilizzato, ho anzitutto definito una classe astratta PersistentDictionary<TKey,TValue> derivando Dictionary<TKey,TValue> nel seguente modo:

public abstract class PersistentDictionary<TKey, TValue> : Dictionary<TKey, TValue>
{
public abstract void Load();
public abstract void Save();

}

Come è facile intuire, i metodi Load() e Save() servono per leggere/scrivere i dati del dictionary dallo/sullo storage.
Nella mia soluzione avevo la necessità di persistere su file system le coppie chiave/valore supportando diversi formati. Ho quindi creato un altro livello di astrazione per rappresentare i dictionary persistenti su file system.

public abstract class FileDictionary<TKey, TValue> : PersistentDictionary<TKey, TValue>

{

public string FileName { get; private set; }

public FileDictionary(string fileName)

{

if (string.IsNullOrWhiteSpace(fileName)) throw new ArgumentException("filename can't be null or empty");

FileName = fileName;

}

Questo tipo di approccio mi ha permesso di lasciare la porta aperta a diverse personalizzazioni. Ad esempio, la seguente classe XmlFileDictionary<TKey,TValue> può essere utilizzata per serializzare/deserializzare in modo generico le coppie chiave/valore di qualunque tipo su un file XML sfruttando la classe XmlSerializer (scelta per rimanere retrocompatibile con il framework 2.0).

public class XmlFileDictionary<TKey, TValue> : FileDictionary<TKey, TValue>

{

private XmlSerializer keySerializer;

private XmlSerializer valueSerializer;

public XmlFileDictionary(string fileName) : base(fileName)

{

keySerializer = new XmlSerializer(typeof(TKey));

valueSerializer = new XmlSerializer(typeof(TValue));

}

public override void Load()

{

if (File.Exists(this.FileName))

{

this.Clear();

using (XmlReader reader = XmlReader.Create(this.FileName))

{

reader.ReadToFollowing("dictionary");

if (!reader.IsEmptyElement)

{

reader.ReadToFollowing("item");

while (reader.NodeType != XmlNodeType.EndElement)

{

reader.ReadStartElement("item");

reader.ReadStartElement("key");

TKey key = (TKey)keySerializer.Deserialize(reader);

reader.ReadEndElement();

reader.ReadStartElement("value");

TValue value = (TValue)valueSerializer.Deserialize(reader);

reader.ReadEndElement();

this.Add(key, value);

}

public override void Save()

{

using (XmlWriter writer = XmlWriter.Create(this.FileName))

{

writer.WriteStartDocument();

writer.WriteStartElement("dictionary", string.Empty);

foreach (TKey key in this.Keys)

{

writer.WriteStartElement("item");

writer.WriteStartElement("key");

keySerializer.Serialize(writer, key);

writer.WriteEndElement();

writer.WriteStartElement("value");

valueSerializer.Serialize(writer, this[key]);

writer.WriteEndElement();

}

writer.WriteEndElement();

}

Nel mio progetto inoltre ho dovuto gestire vari manifest per memorizzare degli indici di cache, sempre su file system. In ciascun file, sia le chiavi che i valori sono sempre di tipo stringa ed ogni coppia è memorizzata su una linea terminata da CRLF. Ho potuto quindi riutilizzare l’astrazione FileDictionary<TKey, TValue> sopra citata per definire una classe concreta che rappresenta un manifest file.

public class ManifestFile : FileDictionary<string, string>

{

private const char DEFAULT_SEPARATOR = '|';

private char _separator;

private Encoding _encoding;

public ManifestFile(string fileName) : this(fileName, DEFAULT_SEPARATOR, Encoding.Default) { }

public ManifestFile(string fileName, char separator) : this(fileName, separator, Encoding.Default) { }

public ManifestFile(string fileName, char separator, Encoding encoding) : base(fileName)

{

if (encoding == null) throw new ArgumentNullException("encoding can't be null");

_separator = separator;

_encoding = encoding;

}

public override void Load()

{

if (File.Exists(this.FileName))

{

this.Clear();

string[] lines = File.ReadAllLines(this.FileName, _encoding);

foreach (string line in lines)

{

string[] parts = line.Split(new char[] { _separator }, StringSplitOptions.RemoveEmptyEntries);

this.Add(parts[0], parts[1]);

}

public override void Save()

{

if (this.Count > 0)

{

List<string> lines = new List<string>();

foreach (string key in this.Keys) lines.Add(key + _separator + this[key]);

File.WriteAllLines(this.FileName, lines.ToArray(), _encoding);

}

else File.WriteAllText(this.FileName, string.Empty, _encoding);

}

Osservazioni e consigli sono ovviamente ben accetti!!! :)

Tag di Technorati: Dictionary,C#

LINQ to CSV

Dario Santarelli — Mon, 27 Apr 2009 17:35:37 GMT

Veramente utile!!! :D

http://www.codeproject.com/KB/linq/LINQtoCSV.aspx

Technorati Tag: LINQ,CSV