Feeds:
Posts
Comments

Archive for October, 2010

Yes, Microsoft Press and Charles Petzold are giving this great book for free.

This book is great, since covers both Silverlight and XNA development on the WP7 platform.

You may want to buy the paper book at the stores.

Read Full Post »

I’ve found the following best practices watching some videos on Channel9. Thanks to Leon Welicki for sharing these tips:

endpoint.tv – Workflow and Custom Activities – Best Practices

Base Classes:

  1. DO use the designer to declaratively author an activity when you want to define it  visually composing other activities
  2. DO derive from Activity to declaratively author an activity in code when requiring non-designer-supported concepts
    1. ActivityDelegate, child activities, and validation
  1. DO derive from CodeActivity when you want to write imperative code that…
    1. Executes in a single pulse of execution
    2. Does not need to schedule other activities
    3. Does not need advanced WF Runtime features
    4. Does not need to execute async

      4. DO derive from AsyncCodeActivity if the work has to be done asynchronously

  1. DO derive from NativeActivity when you want to write imperative code that…
    1. Executes in multiple pulses – Bookmarks
    2. Schedules other activities
    3. Needs advanced WF Runtime features
  1. DO NOT use NativeActivity to author activities that do not require capabilities of the WF Runtime (use CodeActivity instead)
  2. PREFER using activity composition
  3. Use Code/NativeActivity only when the activity can’t be more easily defined in terms of existing Activities
  4. DO use the derivatives of Activity<TResult> to author activities with a return value

During Runtime:

  1. DO NOT make blocking calls in an activity
  2. DO perform I/O operations off the scheduler thread
    1. Use the asynchronous activity pattern

i. DO NOT do your own thread spawning in your activity (e.g. don’t do Thread.Start)

  1. DO ENSURE that the types of all your arguments and variables are serializable
    1. Exception: type only used in a NoPersistZone
  2. If implementing custom cancelation logic…
    1. DO make sure the instance is left in a consistent state.
    2. DO NOT cancel the activity if the associated work cannot be canceled.
  1. If the operation you are performing is cancelable, DO support cancelation with your activity.

Performance:

  1. CONSIDER overriding CacheMetadata to avoid reflection
  2. CONSIDER caching callback delegates if will be used more than once
  3. CONSIDER limiting variable access (invoke Get only once)
  4. CONSIDER declaring variables as tightly scoped as possible

Activity Design: Properties vs. Arguments vs. Activities

  1. DO use Arguments for expressions that are evaluated once before executing the activity
    1. e.g. If.Condition; WriteLine.Text
  2. DO use Activity<TResult> for expressions that may be evaluated more than once
    1. e.g. While.Condition
    2. DO use CLR Property for things that don’t change for all instances of an activity

i. e.g. InvokeMethod.MethodName

Activity Design: Body vs Children

  1. DO use a Body activity in an activity that schedules a single child (e.g. While, CancellationScope, TransactionScope)
    1. DO add Children-like property if the activity coordinates the execution of its children (e.g. Sequence, Parallel)

i. If it can have one child, it should have one child

Activity Design: Variables

  1. DO add a Variables collection to an activity that needs to enable sharing data between its children (e.g. Sequence, Pick)
  2. DO NOT add a Variables collection in composite activities that do not share data between children (e.g. ForEach)
  3. DO use ImplementationVariables to store internal state in an activity

Activity Design: CacheMetadata

  1. DO override CacheMetadata for…
    1. Adding validation
    2. Registering dynamic arguments / variables
    3. Registering implementation variables
    4. Avoiding reflection

Activity Design – Parallel work

  1. DO schedule several AsyncCodeActivity simultaneously if you need thread parallelism (WF Parallel)
    1. DO NOT do your own thread spawning in your activity (e.g. don’t do Thread.Start)
    2. CONSIDER using an AsyncActivity that leverages TaskParallel (TaskParallel Parallel)

Activity Design:

  1. AVOID Swiss Army knife activity
    1. Simple activities
    2. KISS
    3. E.g. ForEach and ParallelForEach / Sequence and Parallel could be the same with a knob?
  2. DO favor composition over inheritance
  3. DO seal your activities

XAML  Serialization

  1. DO use the Create / Set / Use Pattern for your activity types
  2. CONSIDER using [DefaultValue(null)] to avoid serializing unnecessary properties
  3. CONSIDER using [DependsOn] to control the order of the properties serialization
  4. XAML Serialization
  5. Use [ContentProperty] in composite activity
    1. If it has a Body property, CONSIDER making it the ContentProperty
    2. If it has Child/Children collection, CONSIDER making it the ContentProperty
  6. DO use the Create / Set / Use Pattern for your activity types
  7. CONSIDER use [DefaultValue(null)] to avoid serializing unnecessary properties
  8. CONSIDER use [DependsOn] to control the order of the properties serialization
  9. Use [ContentProperty] in composite activity
    1. If it has a Body property, CONSIDER making it the ContentProperty
    2. If it has Child/Children collection, CONSIDER making it the ContentProperty

Naming

  1. DO NOT add the postfix Activity
  2. DO NOT add the postfix Argument or Arg to Arguments
  3. DO NOT add the postfix Variable or Var to Variables
  4. CONSIDER use the suffix “Scope“ for activities which are designed to decorate other activities and add execution semantics

Execution Properties

  1. CONSIDER using execution properties to share data between ancestor / descendant activities
  2. CONSIDER using execution properties to set ambient properties
  3. DO use well-known constant for execution properties
    1. DO use a name that looks like a fully qualified type name

Validation

  1. DO use RequiredArguments
  2. CONSIDER using OverloadGroups for set of arguments that need to be set together
  3. TIP: DO not assume that a required argument that is required does not yield a null in Execute

Validation – Rules

  1. DO return ERROR when there is no reasonable interpretation for the activity given the settings on the activity or the environment
  2. CONSIDER return a WARNING when there is a reasonable way to interpret the activity but we are not fully confident that the interpretation chosen would be obvious
  3. DO NOT return errors or warning if there is a reasonable interpretation for the activity, e.g. “helpful” usage errors like empty sequences

Hope this helps.

Read Full Post »