This package provides a mechanism for rendering widgets based on declarative UI descriptions that can be obtained at runtime.
This package is relatively stable.
We plan to keep the format and supported widget set backwards compatible, so that once a file works, it will keep working. However, this is best-effort only. To guarantee that files keep working as you expect, submit tests to this package (e.g. the binary file and the corresponding screenshot, as a golden test).
The set of widgets supported by this package is somewhat arbitrary.
PRs that add new widgets from Flutter's default widget libraries
(widgets, material, and'cupertino) are welcome.
There are some known theoretical performance limitations with the package's current implementation, but so far nobody has reported experiencing them in production. Please file issues if you run into them.
We would love to hear your experiences using this package, whether positive or negative. In particular, stories of uses of this package in production would be very interesting. Please add comments to issue 90218.
Once you realize that you can ship UI (and maybe logic, e.g. using Wasm; see the example below) you will slowly be tempted to move your whole application to this model.
This won't work.
Flutter proper lets you create widgets for compelling UIs with gestures and animations and so forth. With RFW you can use those widgets, but it doesn't let you create those widgets.
For example, you don't want to use RFW to create a UI that involves page transitions. You don't want to use RFW to create new widgets that involve drag and drop. You don't want to use RFW to create widgets that involve custom painters.
Rather, RFW is best suited for interfaces made out of prebuilt components. For example, a database front-end could use this to describe bespoke UIs for editing different types of objects in the database. Message-of-the-day announcements could be built using this mechanism. Search interfaces could use this mechanism for rich result cards.
RFW is well-suited for describing custom UIs from a potentially infinite set of UIs that could not possibly have been known when the application was created. On the other hand, updating the application's look and feel, changing how navigation works in an application, or adding new features, are all changes that are best made in Flutter itself, creating a new application and shipping that through normal update channels.
The Remote Flutter Widgets (RFW) package combines widget descriptions obtained at runtime, data obtained at runtime, some predefined widgets provided at compile time, and some app logic provided at compile time (possibly combined with other packages to enable new logic to be obtained at runtime), to generate arbitrary widget trees at runtime.
The widget descriptions obtained at runtime (e.g. over the network)
are called remote widget libraries. These are normally transported
in a binary format with the file extension .rfw. They can be written
in a text format (file extension .rfwtxt), and either used directly
or converted into the binary format for transport. The rfw package
provides APIs for parsing and encoding these formats. The
parts of the package
that only deal with these formats can be imported directly and have no
dependency on Flutter's dart:ui library, which means they can be
used on the server or in command-line applications.
The data obtained at runtime is known as configuration data and is
represented by DynamicContent objects. It uses a data structure
similar to JSON (but it distinguishes int and double and does not
support null). The rfw package provides both binary and text
formats to carry this data; JSON can also be used directly (with some
caution), and the data can be created directly in Dart. This is
discussed in more detail in the
DynamicContent
API documentation.
Remote widget libraries can use the configuration data to define how the widgets are built.
Remote widget libraries all eventually bottom out in the predefined
widgets that are compiled into the application. These are called
local widget libraries. The rfw package ships with two local
widget libraries, the core
widgets
from the widgets library (such as Text, Center, Row, etc), and
some of the material
widgets.
Programs can define their own local widget libraries, to provide more widgets for remote widget libraries to use.
These components are combined using a
RemoteWidget
widget and a
Runtime
object.
The remote widget libraries can specify events that trigger in
response to callbacks. For example, the OutlinedButton widget
defined in the
Material
local widget library has an onPressed property which the remote
widget library can define as triggering an event. Events can contain
data (either hardcoded or obtained from the configuration data).
These events result in a callback on the RemoteWidget being invoked.
Events can either have hardcoded results, or the rfw package can be
combined with other packages such as
wasm_run_flutter so
that events trigger code obtained at runtime. That code typically
changes the configuration data, resulting in an update to the rendered
widgets.
See also: API documentation
A Flutter application can render remote widgets using the
RemoteWidget widget, as in the following snippet:
class Example extends StatefulWidget {
const Example({super.key});
@override
State<Example> createState() => _ExampleState();
}
class _ExampleState extends State<Example> {
final Runtime _runtime = Runtime();
final DynamicContent _data = DynamicContent();
// Normally this would be obtained dynamically, but for this example
// we hard-code the "remote" widgets into the app.
//
// Also, normally we would decode this with [decodeLibraryBlob] rather than
// parsing the text version using [parseLibraryFile]. However, to make it
// easier to demo, this uses the slower text format.
static final RemoteWidgetLibrary _remoteWidgets = parseLibraryFile('''
// The "import" keyword is used to specify dependencies, in this case,
// the built-in widgets that are added by initState below.
import core.widgets;
// The "widget" keyword is used to define a new widget constructor.
// The "root" widget is specified as the one to render in the build
// method below.
widget root = Container(
color: 0xFF002211,
child: Center(
child: Text(text: ["Hello, ", data.greet.name, "!"], textDirection: "ltr"),
),
);
''');
static const LibraryName coreName = LibraryName(<String>['core', 'widgets']);
static const LibraryName mainName = LibraryName(<String>['main']);
@override
void initState() {
super.initState();
// Local widget library:
_runtime.update(coreName, createCoreWidgets());
// Remote widget library:
_runtime.update(mainName, _remoteWidgets);
// Configuration data:
_data.update('greet', <String, Object>{'name': 'World'});
}
@override
Widget build(BuildContext context) {
return RemoteWidget(
runtime: _runtime,
data: _data,
widget: const FullyQualifiedWidgetName(mainName, 'root'),
onEvent: (String name, DynamicMap arguments) {
// The example above does not have any way to trigger events, but if it
// did, they would result in this callback being invoked.
debugPrint('user triggered event "$name" with data: $arguments');
},
);
}
}In this example, the "remote" widgets are hardcoded into the
application (_remoteWidgets), the configuration data is hardcoded
and unchanging (_data), and the event handler merely prints a
message to the console.
In typical usage, the remote widgets come from a server at runtime,
either through HTTP or some other network transport. Separately, the
DynamicContent data would be updated, either from the server or
based on local data.
Similarly, events that are signalled by the user's interactions with
the remote widgets (RemoteWidget.onEvent) would typically be sent to
the server for the server to update the data, or would cause the data
to be updated directly, on the user's device, according to some
predefined logic.
It is recommended that servers send binary data, decoded using
decodeLibraryBlob and decodeDataBlob, when providing updates for
the remote widget libraries and data.
When rfw is used for displaying content that is largely static in
presentation and updated only occasionally, the simplest approach is
to encode everything into the remote widget library, download that to
the client, and render it, with only minimal data provided in the
configuration data (e.g. the user's dark mode preference, their
username, the current date or time) and with a few predefined events
(such as one to signal the message should be closed and another to
signal the user checking a "do not show this again" checkbox, or
similar).
A more elaborate use case might involve remote widget libraries being used to describe the UI for editing structured data in a database. In this case, the data may be more important, containing the current data being edited, and the events may signal to the application how to update the data on the backend.
A general search engine could have dedicated remote widgets defined for different kinds of results, allowing the data to be formatted and made interactive in ways that are specific to the query and in ways that could not have been predicted when the application was created. For example, new kinds of search results for current events could be created on the fly and sent to the client without needing to update the client application.
A "local" widget library is one that describes the built-in widgets that your "remote" widgets are built out of. The RFW package comes with some preprepared libraries, available through createCoreWidgets and createMaterialWidgets. You can also create your own.
When developing new local widget libraries, it is convenient to hook
into the reassemble method to update the local widgets. That way,
changes can be seen in real time when hot reloading.
class Example extends StatefulWidget {
const Example({super.key});
@override
State<Example> createState() => _ExampleState();
}
class _ExampleState extends State<Example> {
final Runtime _runtime = Runtime();
final DynamicContent _data = DynamicContent();
@override
void initState() {
super.initState();
_update();
}
@override
void reassemble() {
// This function causes the Runtime to be updated any time the app is
// hot reloaded, so that changes to _createLocalWidgets can be seen
// during development. This function has no effect in production.
super.reassemble();
_update();
}
static WidgetLibrary _createLocalWidgets() {
return LocalWidgetLibrary(<String, LocalWidgetBuilder>{
'GreenBox': (BuildContext context, DataSource source) {
return ColoredBox(
color: const Color(0xFF002211),
child: source.child(<Object>['child']),
);
},
'Hello': (BuildContext context, DataSource source) {
return Center(
child: Text(
'Hello, ${source.v<String>(<Object>["name"])}!',
textDirection: TextDirection.ltr,
),
);
},
});
}
static const LibraryName localName = LibraryName(<String>['local']);
static const LibraryName remoteName = LibraryName(<String>['remote']);
void _update() {
_runtime.update(localName, _createLocalWidgets());
// Normally we would obtain the remote widget library in binary form from a
// server, and decode it with [decodeLibraryBlob] rather than parsing the
// text version using [parseLibraryFile]. However, to make it easier to
// play with this sample, this uses the slower text format.
_runtime.update(remoteName, parseLibraryFile('''
import local;
widget root = GreenBox(
child: Hello(name: "World"),
);
'''));
}
@override
Widget build(BuildContext context) {
return RemoteWidget(
runtime: _runtime,
data: _data,
widget: const FullyQualifiedWidgetName(remoteName, 'root'),
onEvent: (String name, DynamicMap arguments) {
debugPrint('user triggered event "$name" with data: $arguments');
},
);
}
}Widgets in local widget libraries are represented by closures that are invoked by the runtime whenever a local widget is referenced.
The closure uses the
LocalWidgetBuilder
signature. Like any builder in Flutter, it takes a
BuildContext,
which can be used to look up inherited widgets.
For example, widgets that need the current text direction might defer to
Directionality.of(context), with the givenBuildContextas the context argument.
The other argument is a DataSource.
This gives access to the arguments that were provided to the widget in
the remote widget library.
For example, consider the example above, where the remote widget library is:
import local;
widget root = GreenBox(
child: Hello(name: "World"),
);
The GreenBox widget is invoked with one argument (child), and the
Hello widget is invoked with one argument (name).
In the definitions of GreenBox and Hello, the data source is used
to pull out these arguments.
The arguments are a tree of maps and lists with leaves that are Dart
scalar values (int, double, bool, or String), further widgets,
or event handlers.
Here is an example of a more elaborate widget argument:
widget fruit = Foo(
bar: { quux: [ 'apple', 'banana', 'cherry' ] },
);
To obtain a scalar value from the arguments, the
DataSource.v
method is used. This method takes a list of keys (strings or integers)
that denote the path to scalar in question. For instance, to obtain
"cherry" from the example above, the keys would be bar, quux, and
2, as in:
'Foo': (BuildContext context, DataSource source) {
return Text(source.v<String>(<Object>['bar', 'quux', 2])!);
},The v method is generic, with a type argument that specifies the
expected type (one of int, double, bool, or String). When the
value of the argument in the remote widget library does not match the
specified (or inferred) type given to v, or if the specified keys
don't lead to a value at all, it returns null instead.
The LocalWidgetBuilder callback can inspect keys to see if they are
maps or lists before attempting to use them. For example, before
accessing a dozen fields from a map, one might use isMap to check if
the map is present at all. If it is not, then all the fields will be
null, and it is inefficient to fetch each one individually.
The
DataSource.isMap
method is takes a list of keys (like v) and reports if the key
identifies a map.
For example, in this case the bar argument can be treated either as
a map with a name subkey, or a scalar String:
'Foo': (BuildContext context, DataSource source) {
if (source.isMap(<Object>['bar'])) {
return Text('${source.v<String>(<Object>['bar', 'name'])}', textDirection: TextDirection.ltr);
}
return Text('${source.v<String>(<Object>['bar'])}', textDirection: TextDirection.ltr);
},Thus either of the following would have the same result:
widget example1 = GreenBox(
child: Foo(
bar: 'Jean',
),
);
widget example2 = GreenBox(
child: Foo(
bar: { name: 'Jean' },
),
);
The
DataSource.isList
method is similar but reports on whether the specified key identifies a list:
'Foo': (BuildContext context, DataSource source) {
if (source.isList(<Object>['bar', 'quux'])) {
return Text('${source.v<String>(<Object>['bar', 'quux', 2])}', textDirection: TextDirection.ltr);
}
return Text('${source.v<String>(<Object>['baz'])}', textDirection: TextDirection.ltr);
},For lists, a LocalWidgetBuilder callback can iterate over the items
in the list using the
length
method, which returns the length of the list (or zero if the key does
not identify a list):
'Foo': (BuildContext context, DataSource source) {
final int length = source.length(<Object>['text']);
if (length > 0) {
final StringBuffer text = StringBuffer();
for (int index = 0; index < length; index += 1) {
text.write(source.v<String>(<Object>['text', index]));
}
return Text(text.toString(), textDirection: TextDirection.ltr);
}
return const Text('<empty>', textDirection: TextDirection.ltr);
},This could be used like this:
widget example3 = GreenBox(
child: Foo(
text: ['apple', 'banana']
),
);
The GreenBox widget has a child widget, which is itself specified by
the remote widget. This is common, for example, Row and Column
widgets have children, Center has a child, and so on. Indeed, most
widgets have children, except for those like Text, Image, and
Spacer.
The GreenBox definition uses
DataSource.child
to obtain the widget, in a manner similar to the v method:
'GreenBox': (BuildContext context, DataSource source) {
return ColoredBox(color: const Color(0xFF002211), child: source.child(<Object>['child']));
},
Rather than returning null when the specified key points to an
argument that isn't a widget, the child method returns an
ErrorWidget. For cases where having null is acceptable, the
optionalChild method can be used:
'GreenBox': (BuildContext context, DataSource source) {
return ColoredBox(color: const Color(0xFF002211), child: source.optionalChild(<Object>['child']));
},
It returns null when the specified key does not point to a widget.
For widgets that take lists of children, the
childList
method can be used. For example, this is how Row is defined in
createCoreWidgets (see in particular the children line):
'Row': (BuildContext context, DataSource source) {
return Row(
mainAxisAlignment: ArgumentDecoders.enumValue<MainAxisAlignment>(MainAxisAlignment.values, source, ['mainAxisAlignment']) ?? MainAxisAlignment.start,
mainAxisSize: ArgumentDecoders.enumValue<MainAxisSize>(MainAxisSize.values, source, ['mainAxisSize']) ?? MainAxisSize.max,
crossAxisAlignment: ArgumentDecoders.enumValue<CrossAxisAlignment>(CrossAxisAlignment.values, source, ['crossAxisAlignment']) ?? CrossAxisAlignment.center,
textDirection: ArgumentDecoders.enumValue<TextDirection>(TextDirection.values, source, ['textDirection']),
verticalDirection: ArgumentDecoders.enumValue<VerticalDirection>(VerticalDirection.values, source, ['verticalDirection']) ?? VerticalDirection.down,
textBaseline: ArgumentDecoders.enumValue<TextBaseline>(TextBaseline.values, source, ['textBaseline']),
children: source.childList(['children']),
);
},
It is common to need to decode types that are more structured than
merely int, double, bool, or String scalars, for example,
enums, Colors, or Paints.
The
ArgumentDecoders
namespace offers some utility functions to make the decoding of such
values consistent.
For example, the Row definition above has some cases of enums. To
decode them, it uses the
ArgumentDecoders.enumValue
method.
The last kind of argument that widgets can have is callbacks.
Since remote widget libraries are declarative and not code, they cannot represent executable closures. Instead, they are represented as events. For example, here is how the "7" button from the calculator example is represented:
CalculatorButton(label: "7", onPressed: event "digit" { arguments: [7] }),
This creates a CalculatorButton widget with two arguments, label,
a string, and onPressed, an event, whose name is "digit" and whose
arguments are a map with one key, "arguments", whose value is a list
with one value 7.
In that example, CalculatorButton is itself a remote widget that is
defined in terms of a Button, and the onPressed argument
is passed to the onPressed of the Button, like this:
widget CalculatorButton = Padding(
padding: [8.0],
child: SizedBox(
width: 100.0,
height: 100.0,
child: Button(
child: FittedBox(child: Text(text: args.label)),
onPressed: args.onPressed,
),
),
);
Subsequently, Button is defined in terms of a GestureDetector
local widget (which is defined in terms of the GestureDetector
widget from the Flutter framework), and the args.onPressed is passed
to the onTap argument of that GestureDetector local widget (and
from there subsequently to the Flutter framework widget).
When all is said and done, and the button is pressed, an event with
the name "digit" and the given arguments is reported to the
RemoteWidget's onEvent callback. That callback takes two
arguments, the event name and the event arguments.
On the implementation side, in local widget libraries, arguments like
the onTap of the GestureDetector local widget must be turned into
a Dart closure that is passed to the actual Flutter widget called
GestureDetector as the value of its onTap callback.
The simplest kind of callback closure is a VoidCallback (no
arguments, no return value). To turn an event value in a local
widget's arguments in the local widget library into a VoidCallback
in Dart that reports the event as described above, the
DataSource.voidHandler method is used. For example, here is a
simplified GestureDetector local widget that just implements onTap
(when implementing similar local widgets, you may use a similar
technique):
return <WidgetLibrary>[
LocalWidgetLibrary(<String, LocalWidgetBuilder>{
// The local widget is called `GestureDetector`...
'GestureDetector': (BuildContext context, DataSource source) {
// The local widget is implemented using the `GestureDetector`
// widget from the Flutter framework.
return GestureDetector(
onTap: source.voidHandler(<Object>['onTap']),
// A full implementation of a `GestureDetector` local widget
// would have more arguments here, like `onTapDown`, etc.
child: source.optionalChild(<Object>['child']),
);
},
}),
];Sometimes, a callback has a different signature, in particular, it may
provide arguments. To convert the event value into a Dart callback
closure that reports an event as described above, the
DataSource.handler method is used.
In addition to the list of keys that identify the event value, the
method itself takes a callback closure. That callback's purpose is to
convert the given trigger (a function which, when called, reports
the event) into the kind of callback closure the Widget expects.
This is usually written something like the following:
return GestureDetector(
onTapDown: source.handler(<Object>['onTapDown'], (HandlerTrigger trigger) => (TapDownDetails details) => trigger()),
child: source.optionalChild(<Object>['child']),
);To break this down more clearly:
return GestureDetector(
// onTapDown expects a function that takes a TapDownDetails
onTapDown: source.handler<GestureTapDownCallback>( // this returns a function that takes a TapDownDetails
<Object>['onTapDown'],
(HandlerTrigger trigger) { // "trigger" is the function that will send the event to RemoteWidget.onEvent
return (TapDownDetails details) { // this is the function that is returned by handler() above
trigger(); // the function calls "trigger"
};
},
),
child: source.optionalChild(<Object>['child']),
);In some cases, the arguments sent to the callback (the
TapDownDetails in this case) are useful and should be passed to the
RemoteWidget.onEvent as part of its arguments. This can be done by
passing some values to the trigger method, as in:
return GestureDetector(
onTapDown: source.handler(<Object>['onTapDown'], (HandlerTrigger trigger) {
return (TapDownDetails details) => trigger(<String, Object>{
'x': details.globalPosition.dx,
'y': details.globalPosition.dy,
});
}),
child: source.optionalChild(<Object>['child']),
);Any arguments in the event get merged with the arguments passed to
the trigger.
The rfw package introduces a new Flutter widget called
AnimationDefaults.
This widget is exposed by createCoreWidgets under the same name, and
can be exposed in other local widget libraries as desired. This allows
remote widget libraries to configure the animation speed and curves of
entire subtrees more conveniently than repeating the details for each
widget.
To support this widget, implement curve arguments using
ArgumentDecoders.curve
and duration arguments using
ArgumentDecoders.duration.
This automatically defers to the defaults provided by
AnimationDefaults. Alternatively, the
AnimationDefaults.curveOf
and
AnimationDefaults.durationOf
methods can be used with a BuildContext directly to get curve and
duration settings for animations.
The settings default to 200ms and the
Curves.fastOutSlowIn
curve.
Remote widget libraries are usually defined using a Remote Flutter
Widgets text library file (rfwtxt extension), which is then compiled
into a binary library file (rfw extension) on the server before
being sent to the client.
The format of text library files is defined in detail in the API
documentation of the
parseLibraryFile
function.
Compiling a text rfwtxt file to the binary rfw format can be done
by calling
encodeLibraryBlob
on the results of calling parseLibraryFile.
The example in example/wasm has some elaborate remote
widgets,
including some that manipulate state (Button).
The canonical example of a state-manipulating widget is a button. Buttons must react immediately (in milliseconds) and cannot wait for logic that's possibly running on a remote server (maybe many hundreds of milliseconds away).
The aforementioned Button widget in the wasm example tracks a
local "down" state, manipulates it in reaction to
onTapDown/onTapUp events, and changes the shadow and margins of
the button based on its state:
widget Button { down: false } = GestureDetector(
onTap: args.onPressed,
onTapDown: set state.down = true,
onTapUp: set state.down = false,
onTapCancel: set state.down = false,
child: Container(
duration: 50,
margin: switch state.down {
false: [ 0.0, 0.0, 2.0, 2.0 ],
true: [ 2.0, 2.0, 0.0, 0.0 ],
},
padding: [ 12.0, 8.0 ],
decoration: {
type: "shape",
shape: {
type: "stadium",
side: { width: 1.0 },
},
gradient: {
type: "linear",
begin: { x: -0.5, y: -0.25 },
end: { x: 0.0, y: 0.5 },
colors: [ 0xFFFFFF99, 0xFFEEDD00 ],
stops: [ 0.0, 1.0 ],
tileMode: "mirror",
},
shadows: switch state.down {
false: [ { blurRadius: 4.0, spreadRadius: 0.5, offset: { x: 1.0, y: 1.0, } } ],
default: [],
},
},
child: DefaultTextStyle(
style: {
color: 0xFF000000,
fontSize: 32.0,
},
child: args.child,
),
),
);
Because Container is implemented in createCoreWidgets using the
AnimatedContainer widget, changing the fields causes the button to
animate. The duration: 50 argument sets the animation speed to 50ms.
Let us consider a remote widget library that is used to render data in this form:
{ "games": [
{"rating": 8.219, "users-rated": 16860, "name": "Twilight Struggle", "rank": 1, "link": "/boardgame/12333/twilight-struggle", "id": 12333},
{"rating": 8.093, "users-rated": 11750, "name": "Through the Ages: A Story of Civilization", "rank": 2, "link": "/boardgame/25613/through-ages-story-civilization", "id": 25613},
{"rating": 8.088, "users-rated": 34745, "name": "Agricola", "rank": 3, "link": "/boardgame/31260/agricola", "id": 31260},
{"rating": 8.082, "users-rated": 8913, "name": "Terra Mystica", "rank": 4, "link": "/boardgame/120677/terra-mystica", "id": 120677},
// ···For the sake of this example, let us assume this data is registered
with the DynamicContent under the name server.
This configuration data is both valid JSON and a valid RFW data file, which shows how similar the two syntaxes are.
This data is parsed by calling
parseDataFile, which turns it intoDynamicMap. That object is then passed to aDynamicContent, usingDynamicContent.update(this is where the nameserverwould be specified) which is passed to aRemoteWidgetvia thedataproperty.Ideally, rather than dealing with this text form on the client, the data would be turned into a binary form using
encodeDataBlobon the server, and then parsed on the client usingdecodeDataBlob.
First, let's render a plain Flutter ListView with the name of each
product. The Shop widget below achieves this:
import core;
widget Shop = ListView(
children: [
Text(text: "Products:"),
...for product in data.server.games:
Product(product: product)
],
);
widget Product = Text(text: args.product.name, softWrap: false, overflow: "fade");
The Product widget here is not strictly necessary, it could be
inlined into the Shop. However, as with Flutter itself, it can be
easier to develop widgets when logically separate components are
separated into separate widgets.
We can elaborate on this example, introducing a Material AppBar,
using a ListTile for the list items, and making them interactive (at
least in principle; the logic in the app would need to know how to
handle the "shop.productSelect" event):
import core;
import material;
widget MaterialShop = Scaffold(
appBar: AppBar(
title: Text(text: ['Products']),
),
body: ListView(
children: [
...for product in data.server.games:
Product(product: product)
],
),
);
widget Product = ListTile(
title: Text(text: args.product.name),
onTap: event 'shop.productSelect' { name: args.product.name, path: args.product.link },
);
The example in example/remote shows how a program could fetch
different user interfaces at runtime. In this example, the interface
used on startup is the one last cached locally. Each time the program
is run, after displaying the currently-cached interface, the
application fetches a new interface over the network, overwriting the
one in the cache, so that a different interface is used the next time
the app is run.
This example also shows how an application can implement custom local code for events; in this case, incrementing a counter (both of the "remote" widgets are just different ways of implementing a counter).
The example in example/wasm shows how a program could fetch logic in
addition to UI, in this case using Wasm compiled from C (and let us
briefly appreciate the absurdity of using C as a scripting language
for an application written in Dart).
In this example, as written, the Dart client could support any application whose data model consisted of a single integer and whose logic could be expressed in C without external dependencies.
This example could be extended to have the C program export data in
the Remote Flutter Widgets binary data blob format which could be
parsed using decodeDataBlob and passed to DynamicContent.update
(thus allowing any structured data supported by RFW), and similarly
arguments could be passed to the Wasm code using the same format
(encoding using encodeDataBlob) to allow arbitrary structured data
to be communicated from the interface to the Wasm logic. In addition,
the Wasm logic could be provided with WASI interface bindings or with
custom bindings that expose platform capabilities (e.g. from Flutter
plugins), greatly extending the scope of what could be implemented in
the Wasm logic.
As of the time of writing, package:wasm does not support Android,
iOS, or web, so this demo is limited to desktop environments. The
underlying Wasmer runtime supports Android and iOS already, and
obviously Wasm in general is supported by web browsers, so it is
expected that these limitations are only temporary (modulo policy
concerns on iOS, anyway).
See CONTRIBUTING.md