![]() ![]() Imported ActivityDelegates and Activities are declared as public children of the activity, but cannot be directly scheduled by the activity. An activity deriving from Activity can define public arguments, public variables, imported ActivityDelegates, and imported Activities. The Activity class has one implementation child activity, obtained by the runtime using Implementation. ActivityĪctivities created by using Activity have behavior that is designed strictly through composing other activities. ![]() Members of classes derived from NativeActivity are declared to the runtime using the NativeActivityMetadata struct passed to the CacheMetadata method. Any member of such an activity can be defined by using either public or private visibility, except arguments, which can only be declared as public. Deriving activities from NativeActivity grants access to all of the features exposed by the runtime. NativeActivityĪctivities that derive from NativeActivity have behavior that is written in imperative code, and can optionally be defined by using existing activities. Activities that derive from these classes can expose different member types with different visibilities. Authoring ModelsĬustom activities are defined by using NativeActivity, Activity, CodeActivity, or AsyncCodeActivity. Private members and the public members of public child activities can reference arguments and private variables.Ī member that can be set by the consumer of an activity should never be made private. Public members and the public members of public child activities can reference public variables. The visibility rules for data scoping are as follows: Public members are configured by the consumer of the activity, whereas private members use an implementation fixed by the author of the activity. Each of these members can be declared as public or private. The activity model defines the arguments, variables, delegates, and child activities that the activity makes available to consumers. In order to use an activity, the activity author must configure the visibility of each component of its definition. Definition and usageĪ workflow is written by authoring new activities by inheriting from base activity classes, and by using activities from the Built-In Activity Library. Secondary roots use visibility and scoping to constrain the state captured by a CompensableActivity to the scope of definition in which the compensable activities are used. Execution properties use visibility and scoping for constraining execution characteristics to a particular scope of definition. In addition to data scoping, activity model visibility can restrict access to other aspects of the activity, such as validation, debugging, tracking, or tracing. This visibility governs aspects of member usage, such as data scoping. Similar to type definition, the activity model allows an author to qualify the visibility of an activity member regarding the definition of the activity being defined. ![]() The implementation may involve members that are not exposed to consumers of the activity, but are rather details of the implementation. Implementing the execution logic of the activity ![]() Activity definition is performed by the following implementations:ĭetermining the members ( Argument, Variable, and ActivityDelegate objects, and child activities) an activity exposes to its users. Activity definition scoping and visibility, just like scoping and visibility of an object, is the ability of other objects or activities to access members of the activity. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |