In part 1 of this series we showed the benefits of Flutter on embedded, in part 2 we discussed the general technical requirement to run Flutter code on embedded devices.
Now in part 3 we will outline a system architecture to implement a cross-platform Flutter application. Our main objective is to achieve close to 100% reusability of our Flutter source code across mobile, desktop, and embedded platforms, meaning that the vast majority of application logic, UI components, and data-handling code can be shared without modification, with only minimal platform-specific adjustments where necessary.
System Architecture
Figure 2 shows a classic HMI system architecture approach on an embedded device; you easily end up with a strong coupling between your HMI code and the existing filesystem and middleware. These strong coupling can complicate the reuse of your code on mobile.
How to Build our Target Use Case and Ensure Reusable HMI Code?
- HMI code reusability: Avoid strong coupling to your embedded device! This means minimizing dependencies on platform-specific APIs, middleware, or hardware features.
- Data consistency: Ensure consistent data across all devices.
- Middleware: Ensure you can access your device business logic and middleware from external (mobile) systems and the embedded system.
- Communication protocols: Implement reliable communication between mobile app and embedded device, ideally supporting concepts of schema evolution.
First, we want to avoid strong coupling, but what is strong coupling, how does it manifest? A strong coupling, you may also call it dependency, occurs when the HMI code, in our case Flutter, does access APIs or features that are only available on a specific (embedded) platform. In the embedded case, as shown in Figure 2, these are APIs provided through middleware or direct filesystem access. This could be, for example, reading a sensor value from our hardware. On cross-plattform, let’s say mobile, neither the middleware nor the sensor is available – meaning we would have to reimplement the source of the data – and this is explicitly what we do not want.
Lets note this requirement : “✅No direct access to local resources“.
Second, data consistency and middleware. Assume our cross-platform application runs on a mobile phone and on the embedded device. Also assume the app on the mobile phone is connected to the embedded device. I think we can all agree on the expectation that the data displayed on all screens is consistent and up-to-date. We expect to see the same values, the same configuration on all screens (while we may allow unsaved local states). In this assumption we define the embedded device as single point of truth. The embedded device delivers data and holds the active configuration. Furthermore the embedded device serves this information to the mobile applications.
Lets note this requirement: “✅ Embedded Device is single point of truth and serves data and configuration“
Proposed System Architecture
Concluding from our two requirements we have drawn Figure 3. It shows an approach to achieve the requirements. The proposed architecture follows a typical client-server model. The server, running on the embedded hardware, manages the system state and provides access for clients. Clients comprise both the local HMI and remote HMI. The server handles all application logic, while the clients focus on displaying information and handling user interactions in the simplest way possible.
Integration of Middleware
Protocols
The communication with the HMIs and apps (including the local HMI on your embedded device) should be done using protocols that work over Bluetooth LE, TCP, Unix Sockets (local) or any other communication method that fit your use case. Common examples include gRPC, RESTful APIs or protocols on top of WebSockets as well as proprietary protocols.Â
Comparison of Communication Protocols you may consider:
|
PROTOCOL
|
ADVANTAGES
|
DISADVANTAGES
|
|---|---|---|
|
gRPC/Protobuf
|
Efficient, supports bi-directional streaming, language-agnostic.
|
Requires both server and client setup, higher learning curve. Protobuf as a data format (not grpc) can also be sent over Bluetooth LE.
|
|
RESTful API
|
Easy to implement, widely supported, good for request-response.
|
Stateless, less suited for real-time updates or streaming.
|
|
WebSockets
|
Full-duplex communication, good for real-time data.
|
Requires more resources, increased complexity.
|
Challenges and Limitations of Flutter on Embedded
Now that we have outlined an approach of how a Flutter app can be implemented for embedded, you need to be aware of the limitations and be prepared to address the unique issues that arise in embedded environments.
- Hardware acceleration and GPU support: Currently, Flutter heavily relies on GPU support to provide a smooth and responsive UI. There is no simple software rendering option available for Flutter on embedded platforms, meaning that your embedded device must have a GPU. This requirement limits the types of hardware that can effectively run Flutter and may increase hardware costs.
- Integration of embedded hardware: The server-client architecture that we propose in this blog allows for easy integration of embedded hardware, much like you would without using Flutter. Of course accessing low-level hardware features (like GPIOs, I2C, or SPI) could be done in Flutter, but as it was not initially designed for such use cases, we strongly suggest using a server-client approach even in cases where no external HMIs or apps are required.
- Dependency on specific Embedders: The availability of features and performance largely depends on the integration of the chosen Embedder. Different Embedders, like Flutter-Pi, Sony Embedder, or Toyota IVI Homescreen, offer different levels of functionality. Choosing the best Embedder, particularly for 64-bit systems (since on 32-bit there is only Flutter-Pi) is a crucial but also complicated decision. Each Embedder has specific strengths and limitations, which impact the suitability for certain projects.
