Provide a complete software development kit (SDK) to allow developers to build Flutter experiences in languages other than Dart and deliver those experiences over the air (OTA).
The API surface, development experience (hot-reload) and deployment model (native AOT) of Flutter combine to make it a fantastic choice for building apps.
Codepush services built for web based development frameworks like Cordova, Ionic and React Native have shown to provide tremendous value for users of those frameworks. While Flutter's native AOT deployment model provides for great performance, it precludes any kind of over the air delivery.
Many have tried and are working on different approaches to bring an OTA capability to Flutter. In general, these approaches can be broadly classified into a few categories:
Use native Android APIs to download and update the installed APK.
Use JSON (or another format) to describe trees of widgets.
Parse Dart source code to produce JSON (or another format) to describe trees of widgets. Some initiatives have taken this a step further by building recursive AST interpreters for a subset of the parsed Dart source code. Examples are Meituan Waimai's Flap or Wuba's Fair.
Hydro-SDK aims to differentiate itself from the above categories by providing a tight vertical integration of the entire development and deployment experience from writing code to deploying it.
Each layer of Hydro-SDK should be small and as generic as possible. Where cross cutting concerns must happen in order to enable a feature (for example, hot-reload) it should be isolated and itself built as generically as possible.
Hydro-SDK aims to have as small of a runtime footprint as possible. Hydro-SDKs runtime system, common Flutter runtime (CFR) is a subset of a Lua 5.2 environment. It provides an interpreter for Lua 5.2 bytecode, a set of Lua 5.2 intrinsics and a binding system for clean and powerful interop with Dart code. Poviding a full Lua parser and runtime compiler is out of scope. All complexity related to compiling and packaging code is left to other layers. This is similar to the philosophy of the Hermes Engine.
Compiling TypeScript to Lua source code, managing incremental compilations and generating debugging symbols is the responsibility of the
ts2hc SDK-tool. Compiling Lua source code to bytecode is separately handled by the
codepush SDK-tools all need to be able build and package projects for different purposes. Project building is managed by the
*Builder family of classes and shared across SDK-tools.
Hydro-SDK aims to differentiate itself most critically by allowing rich interop with Dart packages. All tooling related to ALP is managed by SWID.