I my last post I showed that creating a custom composite activity (one that can have one or more children) requires deriving from NativeActivity. The Retry activity that I showed was fairly simple and in particular didn’t try to share data with its child. There appears to be a catch-22 in this situation when it comes to overriding CacheMetadata: if I add a Variable to the metadata (AddVariable) then it can be used exclusively by its children – i.e. the activity itself can’t manipulate the state; if I add a variable as implementation data to the metadata (AddImplementationVariable) then the children cant see it as its seen as purely used for this activities implementation. How then do we create data that can be both manipulated by the activity and accessed by the parent?
The secret to achieving this is a feature called ActivityAction - Matt Winkler talks about it here. The idea is that I can bind an activity to one or more parent defined pieces of data then schedule the activity where it will have access to the data. Its probably best to show this with an example so I have written a ForEachFile activity that you give a directory and then it passes its child the file name of each file in the directory in turn. I’ll show the code in its entirety and then walk through each piece in turn
1: [ContentProperty("Body")] 2: [Designer(typeof(ForEachFileDesigner))]
3: public class ForEachFile : NativeActivity, IActivityTemplateFactory
4: { 5: public InArgument<string> Directory { get; set; } 6:
7: [Browsable(false)]
8: public ActivityAction<string> Body { get; set; } 9:
10: private Variable<IEnumerator<FileInfo>> files = new Variable<IEnumerator<FileInfo>>("files"); 11:
12: protected override void CacheMetadata(NativeActivityMetadata metadata)
13: { 14: metadata.AddDelegate(Body);
15:
16: RuntimeArgument arg = new RuntimeArgument("Directory", typeof(string), ArgumentDirection.In); 17: metadata.AddArgument(arg);
18:
19: metadata.AddImplementationVariable(files);
20: }
21: protected override void Execute(NativeActivityContext context)
22: { 23: DirectoryInfo dir = new DirectoryInfo(Directory.Get(context));
24:
25: IEnumerable<FileInfo> fileEnum = dir.GetFiles();
26: IEnumerator<FileInfo> fileList = fileEnum.GetEnumerator();
27: files.Set(context, fileList);
28:
29: bool more = fileList.MoveNext();
30:
31: if (more)
32: { 33: context.ScheduleAction<string>(Body, fileList.Current.FullName, OnBodyComplete);
34: }
35: }
36:
37: private void OnBodyComplete( NativeActivityContext context, ActivityInstance completedInstance)
38: { 39: IEnumerator<FileInfo> fileList = files.Get(context);
40: bool more = fileList.MoveNext();
41:
42: if (more)
43: { 44: context.ScheduleAction<string>(Body, fileList.Current.FullName, OnBodyComplete);
45: }
46:
47: }
48:
49: #region IActivityTemplateFactory Members
50: public Activity Create(DependencyObject target)
51: { 52: var fef = new ForEachFile();
53: var aa = new ActivityAction<string>();
54: var da = new DelegateInArgument<string>();
55: da.Name = "item";
56:
57: fef.Body = aa;
58: aa.Argument = da;
59:
60: return fef;
61: }
62: #endregion
63: }
Ok lets start with the core functionality then we’ll look at each of the pieces that help make this fully usable. As you can see the class derives from NativeActivity and overrides CacheMetadata and Execute – we’ll look at their implementations in a minute. There are three member variables in the class: the InArgument<string> for the directory; an implementation variable to hold the iterator as we move through the files in the directory; the all important ActivityAction<string> which we will use to pass the current file name to the child activity.
Lets look at CacheMetadata more closely. Because we want to do interesting things with some of the state the default implementation won’t work so we override it. As we don’t call the base class version we need to specify how we use all of the state. We add the ActivityAction as a delegate, we bind the Directory argument to a RuntimeArgument and specify the iterator as an implementation variable – we don’t want the child activity to have access to that directly.
Next lets look at Execute. The first couple of lines are nothing unusual – we get the directory and get hold of the list of files. Now we have to store the retrieved iterator in the implementation variable, fileList. We move to the first file in the iteration, if it returns false the list was empty so as long as MoveNext returned true we want to schedule the child activity passing the current file. To do this we use the ScheduleAction<T> member on the context. However, because we’re going to process each one sequentially, we also need to know when the child is finished so we pass a completion callback, OnBodyComplete.
Now in OnBodyComplete we simply get the iterator, move to the next item in the iteration and as long as we’re not finished iterating re-schedule the child again passing the new item in the iteration.
That really is the “functional” part of the activity – everything else is there to support the designer. So why does the designer need help? Well lets look at what we would have to do to build this activity correctly if we were going to execute it from main
1: Activity workflow = new ForEachFile
2: { 3: Body = new ActivityAction<string>
4: { 5: Argument = new DelegateInArgument<string>
6: { 7: Name = "item",
8: },
9: Handler = new WriteLine
10: { 11: Text = new VisualBasicValue<string>("item") 12: }
13: },
14: Directory = @"c:\windows"
15: };
As you can see, its not a matter of simply creating the ForEachFile, we have to build the internal structure too – something needs to create that structure for the designer - this is the point of IActivityTemplateFactory. When you drag an activity on to the design surface normally it just creates the XAML for that activity. However, before it does that it does a speculative cast for IActivityTemplateFactory and if the activity supports that it calls the interface’s Create method instead and serializes the resulting activity to XAML.
So going back to the ForEachFile activity, you can see it implements IActivityTemplateFactory and therefore, as far as the designer is concerned, this is the interesting functionality – lets take a look at the Create method.We create the ForEachFile and wire an ActivityAction<string> to its Body property. ActivityAction<string> needs a slot to store the data to be presented to the child activity. This is modelled by DelegateArgument<string> and this gets wired to the Argument member of the ActvityAction. We also name the argument as we want a default name for the state so the child activity can use it. Notice, however, we don’t specify the child activity itself (it would be a pretty useless composite if we hard coded this). The child will be placed on the Handler property of the ActivityAction but that will be done in the ActivityDesigner using data binding.
Before we look at the designer lets highlight a couple of “polishing” features of the code: the class declared a ContentProperty via an attribute – that just makes the XAML parsing cleaner as the child doesn’t need to be specified using property element syntax; the Body is set to non-browsable – we don’t want the activities user to try to set this value in the property grid.
OK on to the designer. If you read my previous article there are a couple of new things here. Lets look at the markup – again there is no special code in the code behind file, everything is achieved using data binding
1: <sap:ActivityDesigner x:Class="ActivityLib.ForEachFileDesigner"
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
4: xmlns:s="clr-namespace:System;assembly=mscorlib"
5: xmlns:conv="clr-namespace:System.Activities.Presentation.Converters;assembly=System.Activities.Presentation"
6: xmlns:sap="clr-namespace:System.Activities.Presentation;assembly=System.Activities.Presentation"
7: xmlns:sapv="clr-namespace:System.Activities.Presentation.View;assembly=System.Activities.Presentation"
8: xmlns:me="clr-namespace:ActivityLib">
9: <sap:ActivityDesigner.Resources>
10: <conv:ArgumentToExpressionConverter x:Key="expressionConverter"/>
11: </sap:ActivityDesigner.Resources>
12:
13: <Grid>
14: <Grid.RowDefinitions>
15: <RowDefinition Height="Auto"/>
16: <RowDefinition Height="*"/>
17: </Grid.RowDefinitions>
18:
19: <StackPanel Orientation="Horizontal" Margin="2">
20: <TextBlock Text="For each file "/>
21: <TextBox Text="{Binding ModelItem.Body.Argument.Name}" MinWidth="50"/> 22: <TextBlock Text=" in "/>
23: <sapv:ExpressionTextBox Expression="{Binding Path=ModelItem.Directory, Converter={StaticResource expressionConverter}}" 24: ExpressionType="s:String"
25: OwnerActivity="{Binding ModelItem}"/> 26: </StackPanel>
27: <sap:WorkflowItemPresenter Item="{Binding ModelItem.Body.Handler}" 28: HintText="Drop activity"
29: Grid.Row="1" Margin="6"/>
30:
31: </Grid>
32:
33: </sap:ActivityDesigner>
Here’s what this looks like in the designer
So the TextBox at line 21 displays the argument name that our IActivityTemplateFactory implementation set up. The ExpressionTextBox is bound to the directory name but allows VB.NET expressions to be used. The WorkflowItemPresenter is bound to the Handler property of the Body ActivityAction, This designer is then associated with the activity using the [Designer] attribute.
So as you can see, ActivityAction and IActivityTemplateFactory work together to allow us to build rich composite activities with design time support