This article gives the bullet points on Custom Activities and Dependency Properties.
Windows Workflow allows developers to extend the functionality of the base activity library by creating custom activities to solve problems in their specific domain.All custom activities will also ultimately derive from the base Activity class.
How Do I Build Custom Activities?
There are two approaches to building a custom activity. One approach uses composition and the second approach uses derivation.
The composition approach is a similar experience to authoring a workflow. We use the designer to drag, drop, and configure activities inside a new custom activity, and then package the custom activity into an assembly for use in other workflow projects. The composition approach is a quick and easy path to reusable workflow components.
In the derivation approach, we derive a new activity from the Activity class. We can also derive from descendants of the Activity class to inherit more functionality. We can customize the design view, validation, serialization, and code-generation pieces of the activity. The derivation approach gives us the highest level of control and offers a path to extending Windows Workflow with custom code.
Below figure shows the Custom Activity workflow:
The ultimate goal of a dependency property is to manage state. The dependency property is not unique to Windows Workflow; it is also present in WF’s XAML sibling-Windows Presentation Foundation. A dependency property enables a handful of critical features in WF:
- Activity property binding
- Attached properties
Every class that uses a dependency property will ultimately derive from the abstract DependencyObject class.
There are certainly times when we won’t be able to set the value of a property at design time. The values for some properties will only be known at run time.
Activity binding is a powerful mechanism we can use to wire together run time data with activity properties. This is similar to how data binding in .NET wires together data from a data source with user interface elements in a Windows form or web form. A common use of activity binding is to bind the output parameter of one activity to an input parameter of a later activity. This technique means we don’t have the burden of shuffling data from one activity to the next.
Binding actually takes place with the ActivityBind class. The class has a Name and a Path property that allow the SetValue and GetValue methods to find the activity and activity member to bind against.
We can pass this ActivityBind object to the SetBinding method of a DependencyObject.
We can attach a dependency property to any other object derived from DependencyObject. This means we can extend any activity in Windows Workflow with additional, custom properties at run time. One scenario where attached properties are commonly used is when a parent activity needs to append information to each of its child activities. A concrete example is the ConditionedActivityGroup.
There are two types of dependency properties. There are meta-based properties and instance-based properties. The value of a meta-based property must be set at design time and can never change during run time. This means we cannot bind a meta-property, since binding would set a value at run time. Instance-based properties can be set at design time or at run time, and take advantage of activity binding.