Archive for category Silverlight

Asynchronous Programming Now and in the Future

Hello everyone!

I recently spoke at an MSDN geekSpeak on Asynchronous Programming techniques and how they have evolved over time.  I wanted to give just the highlights of the different techniques and post the code.  So here is a list of the different techniques I showed around making WCF calls in WPF and Silverlight asynchronously and some pros and cons about them!

  1. Event based – This technique was probably one of the first ways to write code that can be notified when an asynchronous process is complete.  This technique helped in that it was a solution to the problem, but the code can be very disjointed and hard to read.  Sometimes you only ever want to be notified through one chain of operations but with eventing it reads like it could happen multiple times
  2. Lambda Callbacks – Lambdas definitely helped to make the code more readable and took away the need for cleaner management of events.  We still have certain ways we have to execute our operations and are never guaranteed that code will fire in order so we have to work around it.  However this was a very big step towards making asynchronous coding more manageable and readable.
  3. WorkerQueue – A friend and co-worker of mine Nathan Allen wrote a tool that takes the idea of lambdas and really organizes the underlying processes to make it even easier to manage code.  With the WorkerQueue you actually write synchronous code but you choose which lines you want to execute on a background thread versus lines you want to push to the ui thread and wait for them.  This helps us to write synchronous code while still yielding the ui thread so we don’t lock up on longer running processes.  You can get the code for this tool on his blog here.
  4. Visual Studio Async CTP (await/async) – With the new Visual Studio Async CTP Microsoft has really “straightened” out asynchronous programming by abstracting the complexity with threading and the like.  With this new concept you truly write synchronous code without hardly any extra effort.  In fact when you write code like this you can almost completely write in the way that synchronous code is written with a few extra keywords.  Basically this implements some compiler sugar that for an async/await method creates a little mini state-machine.  It will execute the lines until it hits an await then executes that on a Task, when the Task is completed it updates the state and executes the next step of the state machine.  This is definitely my favorite technique next to using the WorkerQueue and I am eagerly awaiting the release of this extension.

I have posted the code samples here.  You will probably need to install the Visual Studio Async CTP and you can get it and more information here.  I don’t believe that this changes any core .net, just the compiler and visual studio.

I will be speaking on this topic at various events and will post each event I am speaking at on my blog.  If you are in the area and would like to learn more about asynchronous programming then please come!

I hope you enjoy this and happy coding!

6 Comments

CodeStock 2010 Sessions

Hello everyone!

I have a few sessions submitted to CodeStock 2010 this year!  These sessions are on the multi-touch and Silverlight 4 Validation topics I have been looking into recently.  If you enjoyed the blogs and want more detail and guidance on the topics please vote for my sessions!

You can find them at

http://www.codestock.org/Sessions/intro-to-touch-and-multitouch-in-wpf-and-silverlight.aspx

http://www.codestock.org/Sessions/model-validation-in-silverlight-4.aspx

Thanks again and have a good day!

No Comments

Silverlight 4 INotifyDataErrorInfo

Hello everyone!

So recently I have been looking into Silverlight 4’s new INotifyDataErrorInfo interface for a solution to validation.  I have to say that I really like how this works.

I have built a sample validation framework that models can use to build a simple and easy-to-use system for adding validation that is supported by Silverlight.

You can download the sample code here, but let’s look at a few things.

First let’s take a look at the basics of the Interface.  INotifyDataErrorInfo has three primary items:

  • event ErrorsChanged
  • IEnumerable GetErrors(string propertyName)
  • bool HasErrors

The ErrorsChanged event is the key to validation notification in this system.  When ErrorsChanged is fired, a binding that specifies ValidatesOnNotifyDataErrors=True will then call the GetErrors() method with the property name of the property for which the validation rule exists, or null if you want to specify the object as a whole.  So when you create your custom validation engine and you want to notify Silverlight that the validation state for a property (or object) has changed, you will raise this event.

One cool thing to note about the fact ErrorsChanged is an event, is that it can now support async validation rules.  Imagine in your validation system you make an async call back to the server; when it returns, you can raise this event!

private void HandleRuleResult(string propertyName, RuleKey<T> ruleKey, RuleArgs args)
        {
            if (args.IsValid)
            {
                var foundRule = (from re in ErrorMessages
                                 where re.PropertyName == propertyName
                                 && re.RuleIdentifier == ruleKey.RuleIdentifier
                                 select re).FirstOrDefault();

                if (foundRule != null)
                {
                    ErrorMessages.Remove(foundRule);
                    OnErrorsChanged(propertyName);
                }
            }
            else
            {
                var foundRule = (from re in ErrorMessages
                                 where re.PropertyName == propertyName
                                 && re.RuleIdentifier == ruleKey.RuleIdentifier
                                 select re).FirstOrDefault();

                if (foundRule == null)
                {
                    RuleError error = new RuleError() { RuleIdentifier = ruleKey.RuleIdentifier, ErrorMessage = args.Message, PropertyName = propertyName };
                    ErrorMessages.Add(error);
                    OnErrorsChanged(propertyName);
                }
            }
        }

        protected void OnErrorsChanged(string propertyName)
        {
            if (ErrorsChanged != null)
                ErrorsChanged(this, new DataErrorsChangedEventArgs(propertyName));
        }

 

The method of GetErrors() is what the system uses in order retrieve the validation errors when it is notified that the validation rules have changed.  The propertyName parameter will be passed either a single property name, for which you will retrieve your rules, or null, which is your key to retrieve all rules for the entire object.  This is helpful for controls like my custom ValidationSummary control.

It is important to note here that this method needs to be able to get the validation messages after the ErrorsChanged event fires. This means in your custom system, you must have stored your broken validation rules in a way where this can be coded to retrieve before you fire the event.

public System.Collections.IEnumerable GetErrors(string propertyName)
        {
            List<string> errors = null;

            if (propertyName == null)
            {
                if (ErrorMessages.Count > 0)
                {
                    errors = new List<string>();

                    foreach (var re in ErrorMessages)
                    {
                        errors.Add(re.ErrorMessage);
                    }
                }
            }
            else
            {
                var foundRules = (from re in ErrorMessages
                                  where re.PropertyName == propertyName
                                  select re).ToList();

                if (foundRules != null && foundRules.Count > 0)
                {
                    errors = new List<string>();
                    foreach (var re in foundRules)
                        errors.Add(re.ErrorMessage);
                }
            }

            return errors;
        }

 

The last piece is the HasErrors property: this is how to notify your objects that the resulting object has errors.  Every time a rule changes you may want to raise OnPropertyChanged for this property and implement its getter in a way where it knows how to count your broken rules.

public bool HasErrors
        {
            get { return ErrorMessages.Count > 0; }
        }

 

So far what we should now realize is that the interface provides us a way to tie our own validation engine directly into Silverlight.  It does not provide a validation engine in itself, but gives you everything you need to notify Silverlight that states have changed.

The sample code posted above provides a sample implementation of how a validation rules engine might be created around this interface.  I was very inspired by CSLA’s (http://www.lhotka.net/) validation rule entry interface so I modeled it somewhat after its pattern.  We have the ability to add rules to our objects via static methods and property names.  These rules are only added once per type and stored statically.  The engine also allows for the creation of async rules and also provides a bindable collection that is populated with broken rules when they are added.

Once again if you would like to download the sample framework and code you can get it here.

I hope you enjoy it and have a good day!

8 Comments

Multi-Touch in WPF and Silverlight

Hello Everyone!

We had a great time at the Columbia Code Camp this year.  A lot of great speakers and volunteers to help with the event.  We had I think around 150 people show up which was amazing since it was snowing, raining and freezing temperatures :) .

I did my multi-touch presentation for the first time and I think it went very well.  Had some great feedback and questions afterwards.

So as promised I am posting  up the materials and a quick explanation of what is available to use for Multi-Touch in WPF and Silverlight.  In the demo code for WPF you will need to change the App.xaml to point to the different demo windows.  You can download the demo code here.

Raw Touch

In both WPF and Silverlight there is a concept called Raw Touch.  These events are close to the mouse events in that they work with a device and a point (position) on the visual.   Here are the events:

WPF

  • TouchDown – Occurs when a touch device touches the visual
  • TouchMove – Occurs when a touch device is down and starts to move across the visual
  • TouchUp – Occurs when the touch device is lifted off the visual
  • TouchEnter – Occurs when the touch device is down and while moving enters a new visual
  • TouchLeave – Occurs when the touch device is down and while moving leaves a visual

Silverlight

  • Touch.TouchFrameReported – Static Event that is fired any time a touch device activates on a visual

In WPF we can attach handlers to the above events to an individual element and they will only fire when touch is activated on that visual.  For Silverlight however we do not have this.  The TouchFrameReported event will fire no matter what visual has had touch activated.  It is constantly looking for this event on a frame draw.  Even if you touch your finger down and hold it without moving the TouchFrameReported event is still firing with a Move action.

The key to these events (even the Silverlight one) is the GetTouchPoint or GetTouchPoints methods.  With these methods you can pass in an element and get the point that you are currently touching.  What’s cool about this is that if we have 2 elements one of top of the other, but the element underneath is larger than the we actually touched, we can pass in the element underneath and get the touch point relative to that element instead of the one on top.  So we have a lot of power behind where we can get these touch points in relation to which elements we have defined.

Another key to RawTouch is the Device’s Device Id.  Each unique finger that touches the screen will get a unique device ID.  By utilizing this device ID we can accurately keep track of which finger is performing what action and act appropriately.  By doing this we can now truly write something in Multi-Touch :) .

To see more detail please look at the RawTouch and Gesture demos.  The Gesture demos show how we can write one common library in WPF and Silverlight that can recognize straight line gesture activations and abstractly report them to a handler or command.

Manipulations

One other cool thing that we do have in WPF that we don’t have in Silverlight is Manipulations.  These events take alot of the guess work out of raw touch and simplifies the data passed into the handlers.

The events to take note of are:

  • ManipulationStarting – occurs when a manipulation is triggered and about to start
  • ManipulationStarted – occurs when a manipulation has started
  • ManipulationDelta – occurs when a manipulation has changed its data based on movement
  • ManipulationInertiaStarting – occurs when inertia is about to kick in for a manipulation.

Lets say we want to handle the pinching resize functionality that seems to be common in multi-touch.  Well with RawTouch that would be very difficult as we have to calculate that 2 touch points are moving in opposite directions away from each other.  Then we have to calculate the difference between them and provide a scale vector.  This could be a real pain to do in RawTouch.

With Manipulations all of that hard work is done for us.  When the ManipulationDelta event fires the args provide a DeltaManipulation with a Scale property.  This Scale is the vector difference of our resize.  If Scale is not populated then we know we did not do a resize.  We are also provided with a Rotate that is a decimal in the degree change and a Translate which handles straight movement.  Manipulations make it very easy to get started with multi-touch.

Inertia is a cool way to provide smooth deceleration transitions from a manipulation to a stopping point.  Lets say you move a rectangle across the screen but you don’t want it to stop immediately when you lift your finger, but instead you want it to keep going and slow down to a stopping point.  Inertia is an easy way to allow this.

When the ManipulationInertiaStarting event fires it has already calculated your velocity for you!  It has determined how much distance was crossed and how fast your manipulation occured to give you this initial velocity.  From this you just provide it a deceleration rate to tell it how fast it needs to slow down.  A deceleration rate of 10 inches per second every second could look like this “10.0 * 96 / (1000 * 1000)”.  With this we can control how it slows down when continuing a manipulation.

For more detail on the code please see the demos provided.

 

Well thats the basics of what multi-touch capabilities are provided in WPF and Silverlight.  I hope you enjoyed this topic and enjoy the code!

I will be presenting on this topic in Atlanta at the Atlanta MS Pros user group on March 1st.  I hope to see you there!

1 Comment