Event System & Observers

Relevant source files

The following files were used as context for generating this wiki page:

• LVGL_Features.md
• main/core/apps/system_info/SystemInfoApp.cpp
• main/core/README.md
• reports/docs.txt
• reports/naming.txt
• main/CMakeLists.txt

The Event System and Observer framework in FlxOS provides a reactive mechanism for decoupling the core system logic from the user interface. By utilizing the native observer patterns introduced in LVGL v9, the system allows widgets to bind directly to data sources, ensuring that UI components update automatically when underlying system variables or states change.

This architecture supports a modular application design where background services (such as connectivity or system monitoring) act as subjects, and UI elements act as observers. This pattern reduces the need for manual polling and complex callback chains, facilitating a more responsive and memory-safe environment.

Sources: LVGL_Features.md:6-10, main/core/README.md:12-14

Core Architecture

The observer system is built upon the lv_observer implementation within the LVGL v9 core. It enables a reactive UI where data binding is a first-class citizen. This is complemented by the FlxOS connectivity suite and system services, which expose observables for various hardware and software states.

Key Components

Component	Description
Observable	A data source or variable that can be monitored for changes.
Observer	A UI widget or logic block that reacts to changes in an Observable.
Connectivity Manager	Provides observables for WiFi status, SSID, IP addresses, and hotspot metrics.
System Info Service	Tracks system-level metrics like CPU load, heap usage, and task states.

Sources: LVGL_Features.md:8-10, reports/docs.txt:18-32

Data Flow and Interaction

The following diagram illustrates the relationship between system services providing data and the UI components observing that data.

LVGL Observer Integration

FlxOS leverages the lv_observer module to bind widgets to data sources. This allows for unified property access via IDs or names, facilitating runtime introspection and easy updates.

• Reactive UI: Widgets bind to data sources and update automatically.
• Event Bubbling: Support for lv_obj_event with bubbling and filtering capabilities.
• Async Callbacks: The system uses bridge functions (e.g., async_cb) to handle asynchronous updates between system events and the UI thread.

Sources: LVGL_Features.md:8-14, reports/naming.txt:26-28

Implementation in System Applications

The SystemInfoApp demonstrates a hybrid approach where it manually polls high-frequency data (like CPU usage) while remaining structured to consume service-level data. The app uses an updateInfo() method triggered by a timer to refresh labels and bars representing system health.

Observed Connectivity Metrics

The Connectivity Manager exposes specific observables that the UI system can hook into:

• getWiFiConnectedObservable()
• getWiFiIpObservable()
• getHotspotEnabledObservable()
• getHotspotUsageSentSubject()
• getBluetoothEnabledObservable()

Sources: reports/docs.txt:20-32

Event Handling and Logic

The system distinguishes between low-level hardware events and high-level UI events. Hardware events (e.g., WiFi disconnection) are handled by specialized managers (e.g., WiFiManager) and then propagated through the connectivity observables to the UI.

Event Processing Flow

Naming and Style Guidelines

For consistency within the event system, the following conventions are enforced:

• Callbacks: Usually end in _cb or follow camelCase for bridge functions (e.g., async_cb).
• Observables: Public getters follow the get[Property]Observable pattern.

Sources: reports/naming.txt:26-28, reports/docs.txt:18-32

Summary

The Event System and Observers in FlxOS provide a robust framework for real-time data visualization and system state management. By integrating LVGL's reactive UI features with backend services, FlxOS ensures that users receive immediate feedback on system changes while maintaining a clean separation of concerns between hardware-level drivers and the presentation layer.