4. Working with Behaviors
Although most of our discussion about design has focused on
structure, some parts of a design should focus on performing actions.
This is where behaviors come into play. A behavior is
an object that can be activated based on an event in the design to
perform some action. For example, you could have an animation fire when
an item is acted upon. Figure 24 shows the various behaviors that ship with Blend.
Figure 24. Behaviors in the Assets panel
Table 2 explains the built-in behaviors.
Table 2. Blend Behaviors
To use behaviors, you simply drag them onto an object in the Objects
and Timeline panel or onto the artboard. For example, if you drag a ControlStoryboardAction object onto the ellipse, it creates the new behavior on the ellipse, as shown in Figure 25.
Figure 25. Applying a behavior
After the behavior is created, you’ll see the behavior properties in
the Properties panel. The top half (the trigger) is where you can select
the event that causes the behavior to fire. In this case we are
executing it when the Tapped event is fired, which also
happens when a user presses the screen of Windows Phone. The top half is
the same for most behaviors.
The bottom half is different for different behaviors. In this case we
are choosing what to do to a storyboard (for example, play, pause, and
so on) and whichh storyboard to affect. The drop-down will show you all
the animations you’ve created (as shown in Figure 26).
Figure 26. Changing behavior properties
You can have multiple behaviors on objects in the Objects and
Timeline panel. In fact, you can have multiple behaviors with the same
trigger. You can see the behaviors directly in the object tree, as shown
in Figure 27.
Figure 27. Multiple behaviors
Behaviors do not replace the need for typical code, but they
do represent a way to perform UI-specific operations (for example,
actions). For instance, you might have a fly-out panel that is shown
when a button is pressed. It is not necessary to get code involved to
show and hide the panel because there is no logic in this operation.
It’s purely a UI operation. Behaviors allow you to have XAML that
represents a unit of the UI. Anytime you put real logic (for example,
validation or other behavior) in the design, you’re probably making a
mistake and should do that sort of work in code.
