Jose Fajardo

Monday April 20, 2009

It took me under 5 minutes to realize the power of behaviors!

 

Developers take note, there is a new way of coding and it’s called Behaviors.

Let me walk you through a very simple example of how powerful this new feature is…

lets begin …

Over the last couple of days playing with the SL3 OOB features, I found that if you want to take a Silverlight App out-of-browser you would need to do the following via code…

 

OLD WAY OF DOING THINGS (designer creates the UI / developer wires up the UI)

Designer creates a button that when clicked will take the application out-of-browser

Developer wires up the buttons click event to the actual code that takes the app out-of-browser

 

 

NEW WAY OF DONIG THINGS (using Behaviors)

Developer creates reusable snippets of code as behavior actions. (think a library of reusable code)

In the example below I create an “Action” called “GoOfflineAction”. And the code contained within is exactly the same from the butInstall_Click from above “old way of doing things”

These “actions” are available to a designer via the Blend 3 design surface

All a designer needs to do is drag this “action” onto a control (in our example the button “butInstall”).

Then set the properties of the “action” to trigger when the button is “clicked”

The designer has full control of wiring up the “action” to the button. The developer no longer needs to do this mundane task!

 

CONCLUSION 

In this new world a UI developer (divigner) needs to think about writing code that can easily be consumed by a designer (thru the behavior framework – behaviors, actions, triggers)

Overtime a set of common behavior components (behaviors, actions, triggers) will be created and these can be taken with you from project to project.

Here is a quick list of other behaviors that come to mind:

1. Drag Drop Behavior

2. Key listener action

3. Collision detection behavior

4. Panel Pin-to-wall behavior

5. Many different Actions and/or behaviors relating to the media element.

6. Many different actions and/or behaviors relating to the deepzoom feature.

7. Many different actions and/or behaviors relating to the new Virtual Earth Silverlight control.

As mentioned above the ultimate goal of the new behavior architecture is to surface all those cool code bits developers build to a designer. Then let the designer use them when he/she sees fit.

So the question I now ask myself is what wouldn’t you turn into a behavior. That’s something I’ve been asking myself over the last couple of days and honestly I can’t find many code scenarios that I wouldn’t turn into behaviors.

The example I showed you is a very simple use of behavior “actions”, there are more complex scenarios that involve handling multiple events and persisting state between events, I’ll blog about those in the near future.

For now get your hands dirty and whenever you write code that wires up the UI take a step back and consider doing it as a behavior component (action, trigger or behavior).