Widget Level Animation Using Flex Forms

Widget Level Animation feature enables you to animate widgets placed in a container (for example, Form). This feature supports 2D and 3D animations and transformations. The 2D animations are supported on iOS, Android, Windows, and SPA platforms and the 3D animations are supported on iOS, SPA and Android (limited support) for the applications created in JavaScript language using the Quantum Platform.

When the transformation matrix is identity, the 3D directions are as follows:

  • x-axis is towards the right of the widget
  • y-axis is towards bottom of the widget
  • z-axis is coming out of the screen

NOTE: 3D animations should be applied on widgets when they are in normal state. Otherwise it may have undefined behavior.

The animation is classified into the following sub classes:

Key Frame Animations

Key frame animations allows you to define animations by changing the widget level properties.

Key Frame Animation Definition

Key frame definition consists of one or more properties of the widget along with changes in their values and the steps (key frame) involved in changing the value from the initial value to final value. Each step from initial value to the final value can be configured with an animation behavior.

Key frame animation can be defined dictionary of steps with each step configured again using a JavaScript Object (Dictionary). Step-config is optional parameter. Following is the syntax:

NOTE: If the animation definition does not follow the above syntax then animate API throws Invalid Animation Definition exception.

{  
         
<step>: { 
 
<widget_property> : <value> , 

<widget_property> : <value> ,

 …

stepConfig : { … }
}

		,
<step>: { 

<widget_property>  : <value> , 

<widget_property>  : <value> ,  

…

stepConfig : { … }

}
,
       ….

}

References

APIs does not completely adhere to the CSS3 specifications but is influenced by CSS3 animations and transformations. 

The following URLs help as a reference:

Animation Properties Events and Methods

Following are the widget level properties, events, and methods that are allowed to be part of the animation definition.

Widget Skin Properties

Following widget skin properties can be animated: 

Animation Configurations

Animation configuration specifies the render behavior of an object during the animation. For example, you can specify how long an animation occur or the direction the animation should occur. The animation configurations are part of overall animation and not the step level configuration.

Following are the components of animation configuration:

Applying Animations

Every widget provides animate API to animate the widgets.

Following are the types of animations you can apply:

  1. Sequential and Parallel Animations
  2. Querying Widget Properties
  3. Layout Callbacks during Animation
  4. Flex Container and Child Widgets
  5. Multiple Parallel Animations
  6. Interactions on the Widget during Animation

Sequential and Parallel Animations

To sequence the animations one after the other, animation events have to be used. You can start a new animation at the end of the existing animation using animationEnd event.

All animations initiated by animate API gets executed asynchronously. Essentially calling animate API on widgets sequentially one after the other leads to parallel execution of the animations.

Querying Widget Properties

Following is the table showing the behavior of the animatable properties when queried during or at the end of the animation. Only when the model is updated (last column) then the values are available when queried.

Fill-mode In delay state Animation states Final state Model Update
Direction: None  
None Y RGB Y No update
Forwards Y RGB B A.E.A update with 100th step
Backwards R RGB Y A.B.A update with 0th step, A.E.A update with initial value
Both R RGB B A.B.A update with 0th step, A.E.A update with 100th step
Direction: Alternate,   Iteration Count = even  value  
None Y RGB => BGR Y No update
Forwards Y RGB => BGR R A.E.A update with 0th step
Backwards R RGB => BGR Y A.B.A update with 0th step, A.E.A update with initial value
Both R RGB => BGR R A.B.A update with 0th step, A.E.A update with 0th step
Direction: : Alternate,  Iteration Count = odd value  
None Y RGB => BGR => RGB Y No update
Forwards Y RGB => BGR => RGB B A.E.A update with 100th step
Backwards R RGB => BGR => RGB Y A.B.A update with 0th step, A.E.A update with initial value
Both R RGB => BGR => RGB B A.B.A update with 0th step, A.E.A update with 100th step

Layout Callbacks during Animation

doLayout callbacks are not guaranteed to be called in synchronization with steps configured in animation and may not get called in any determined fashion. It is suggested to unhook any layout events during the animations.

Flex Container and Child Widgets

When dimensional and positional properties of the flex container are animated then all child widgets sharing percentage (%) relationship with the parent also gets animated.Percentage (%) Relationship between parent and child can be established by specifying one or positional, dimensional properties of the widgets in percentage (%) units.

Actual animation that child widget goes through depends on the property that is animated on the container and the property of the child widget that shares the percentage (%) relationship with the parent.

If there is no percentage (%) relationship between the parent and child then child will not go through any animation as parent gets animated.

Multiple Parallel Animations

Parallel animations on widgets that do not have any dependencies on other widgets (for example, widgets can share dependency through parent and child widgets with percentage % relationship or the widgets inside HORIZONTAL_FLOW, VERTICAL_FLOW share dependency on siblings) will work across platforms consistently without any issues.

  • Parallel animations on multiple widgets, that do not share any relationship, must not have any issues, and must work consistently.
  • Parallel animations on widgets, that share dependency, may lead to inconsistent results and should be avoided.
  • Parallel animations on the same widget, for example, calling animate method on the same widget, and then the first animation gets canceled due to the second animation.
  • Parallel animations cancellation may lead to undefined behavior and animation-fill-mode property may not work as expected.

NOTE: Any implicit animations due to widget dependency are not treated as parallel animations.

Interactions on the Widget during Animation

Interacting with the widget during animation may also lead to undefined behaviors. Behavior depends on underlying platform.

As a guideline, developers must avoid writing code that changes the widget properties if they are being animated.

NOTE: For example, changing properties of the widget immediately after widget.animate() may lead to undefined behaviors. Ideally, any changes on the widget must happen after animation, in animationEnd() event.