Data Binding
Connect your code to bound editor elements using View Models
Overview
Before engaging with the runtime data binding APIs, it is important to familiarize yourself with the core concepts presented in the Overview.
Data Binding Concepts
An overview of core data binding concepts.
View Models
View models describe a set of properties, but cannot themselves be used to get or set values - that is the role of view model instances.
To begin, we need to get a reference to a particular view model. This can be done either by index, by name, or the default for a given artboard, and is done from the Rive file. The default option refers to the view model assigned to an artboard by the dropdown in the editor.
Access a View Model from the created Rive object in the onLoad
callback:
Once Rive is loaded, you can access the view models using the following methods:
Alternatively, if you have access to the underlying Rive File object you can access the above methods on the file.
Access a View Model from the created Rive object in the onLoad
callback:
Once Rive is loaded, you can access the view models using the following methods:
Alternatively, if you have access to the underlying Rive File object you can access the above methods on the file.
These APIs are only needed when the Data Binding Mode
on the RiveWidget is set to Manual
.
Otherwise, you can configure view model binding directly in the Unity Inspector under the Data section.
View Model Instances
Once we have a reference to a view model, it can be used to create an instance. When creating an instance, you have four options:
-
Create a blank instance - Fill the properties of the created instance with default values as follows:
Type Value Number 0 String Empty string Boolean False Color #000000FF Trigger Untriggered Enum The first value Nested view model Null -
Create the default instance - Use the instance labelled “Default” in the editor. Usually this is the one a designer intends as the primary one to be used at runtime.
-
Create by index - Using the order returned when iterating over all available instances. Useful when creating multiple instances by iteration.
-
Create by name - Use the editor’s instance name. Useful when creating a specific instance.
These APIs are only needed when the Data Binding Mode
on the RiveWidget is set to Manual
.
Otherwise, you can configure view model binding directly in the Unity Inspector under the Data section.
The created instance can then be assigned to a state machine or artboard. This establishes the bindings set up at edit time.
It is preferred to assign to a state machine, as this will automatically apply the instance to the artboard as well. Only assign to an artboard if you are not using a state machine, i.e. your file is static or uses linear animations.
Auto-Binding
Alternatively, you may prefer to use auto-binding. This will automatically bind the default view model of the artboard using the default instance to both the state machine and the artboard. The default view model is the one selected on the artboard in the editor dropdown. The default instance is the one marked “Default” in the editor.
Flutter (rive_native) does not support auto-binding at this time. Higher level widgets will expose this functionality in the future.
See the RivePlayer.dart
file in the example app for a demo of how this will be presented.
Rive Widget provides both visual and programmatic ways to configure auto-binding. In the Inspector, you can easily set up binding through the Data Binding Mode dropdown:
To enable auto-binding programmatically, use the following APIs:
Properties
A property is a value that can be read, set, or observed on a view model instance. Properties can be of the following types:
Type | Supported |
---|---|
Floating point numbers | ✅ |
Booleans | ✅ |
Triggers | ✅ |
Strings | ✅ |
Enumerations | ✅ |
Colors | ✅ |
Nesting | ✅ |
Lists | 🚧 Coming soon |
Images | 🚧 Coming soon |
Property descriptors can be inspected on a view model to discover at runtime which are available. These are not the mutable properties themselves though - once again those are on instances. These descriptors have a type and name.
Mutable Properties
View model instances have mutable properties. References to these properties can be retrieved by name. They have get, set, and observe operations. Getting or observing the value will retrieve the latest value set on that properties binding, as of the last state machine or artboard advance. Setting the value will update the value and all of its bound elements.
Observability
You can observe changes over time to property values, either by using listeners or a platform equivalent method. Once observed, you will be notified when the property changes are applied by a state machine advance, whether that is a new value that has been explicitly set or if the value was updated as a result of a binding. Observing trigger properties is an alternative method to receive events from the editor, as compared to Rive Events.
Adding an observer to a property is done by calling the on
method on the property.
The observer can be removed by calling the off
method on the property and passing the callback function. Alternatively, you can call off()
without any arguments to remove all observers.
Example:
Adding an observer to a property is done by calling the on
method on the property.
The observer can be removed by calling the off
method on the property and passing the callback function. Alternatively, you can call off()
without any arguments to remove all observers.
Example:
Enums
Enums properties come in two flavors: system and user-defined. In practice, you will not need to worry about the distinction, but just be aware that system enums are available in any Rive file that binds to an editor-defined enum set, representing options from the editor’s dropdowns, where user-defined enums are those defined by a designer in the editor.
Enums are string typed. The Rive file contains a list of enums. Each enum in turn has a name and a list of strings.
Nested Property Paths
View models can have properties of type view model, allowing for arbitrary nesting. We could chain property calls on each instance starting from the root until we get to the property of interest. Alternatively we can do this through a path parameter, which is similar to a URI in that it is a forward slash delimited list of property names ending in the name of the property of interest.
Examples
See this video for an intro to data binding using the Web runtime along with this CodeSandbox example.
See this video for an intro to data binding using the Web runtime along with this CodeSandbox example.
See the Data Binding view in the Example app for a demo.
See the examples/data_binding.dart
file in the example app on Pub for a demo.
Was this page helpful?