-
Notifications
You must be signed in to change notification settings - Fork 33
HybridOS App Framework
HybridOS Specification 01-A
Topic: HybridOS App Framework
Author: Vincent Wei
Category: App Framework
Date: November 2018
Status: Proposal
Copyright Notice
Copyright (C) 2019 FMSoft Technologies
All Rights Reserved.
Only a new app framework can define a new operating system.
Per a HybridOS app, because it can run on device side and client side, the app framework should be platform independent.
Generally, a HybridOS app consists of zero, or more activities, and zero, or more request responders. But a HybridOS app at least consists of one activity or one request responder.
An activity shows a rendered content page to the end user, the user interacts with the app to complete some tasks.
A request responder executes a request and feeds the result data to various system services or requests from network and other HybridOS apps.
The app framework should hide the details of the different runtime platforms. For example, on a platform that supports multiple processes, a request responder of an HybridOS App may run in a separate process on that platform, but on a platform that supports only multithreading, the request responder may run in a thread.
Moreover, the app framework needs to provide a consistent API for different app running environments, such as device-side, client-side, and simulator, thus greatly reducing the cost of development.
The app framework should also hide the details of the different application protocols, so the app can use one request responder to serve a request in different protocols, for example, HTTP, CoAP, or MQTT.
In order to achieve the above goals, we use data bus as an infrastructure, which interchanges the data between different activities and services in JSON format, and use URI to determine the identity of a resource, regardless it is located in other thread of the same process, other process, other device, other client, or other remote server.
A new app framework defines a new operating system, while the new app framework first needs a new GUI programming model.
In GUI programming model, the event-driven programming model has gained popularity. Event-driven programming is structured around the concept of decoupled relationships between event producers and event consumers.
Currently, almost all mature GUI support systems are event driven. In order to facilitate development, these GUI support systems, including Gtk+, Qt, MiniGUI, Windows, Android, iOS basically adopt concepts such as Toolkit, Widget, or Control. The developer puts various widgets on a window or an activity, and manipulates the widgets or handles the events generated by them.
However, the traditional widget-based programming mechanism does not provide a good solution for decoupling data and rendering relationships.
On the other hand, the development of Web technologies, especially the development of HTML5 and CSS 3, makes webpages more interactive, and provides a simple, easy to use and flexible coding and implementation mechanism, especially on decoupling the data and rendering relationships.
The designers of HybridOS believe that the client GUI programming mechanism should learn from Web technologies. Furthermore, we believe that the many benefits of web client programming are not derived from the JavaScript language, but rather the underlying structured document description mechanism (DOM) and the CSS-based style definition mechanism.
Therefore, HybridOS's GUI programming model no longer adheres to the traditional Toolkit/Widget mechanism; we choose to extend HTML5 and introduce the support of CSS 3. When programming is required, HybridOS provides the JavaScript programming interface same as Web browser for high-end device configurations and a C++ programming interface for low-end device configurations.
The key features follow:
-
The developer always use HVML (HybridOS View Markup Language, which defines a few new tags based on HTML 5.3) and CSS 3 to define the structure, styles, and layout of the elements and GUI.
-
If the hardware has enough computing power (at lease 64MB RAM and 600MHz CPU), the developer can write the device apps in JavaScript language. Or, the developer falls back to write the device apps in C++ language.
-
For the device apps written in JavaScript language, HybridOS provides a user agent like a Web browser, which contains the V8 JS engine and the HVML renderer. We name the user agent as 'HybridOS App Engine' (
HAEfor short). -
When you write the device apps in C++ language, the HVML documents and CSS definitions can be interpreted by some ready-to-use tools to one or more C++ source files. The developer can manipulate all DOM elements, their attributes, styles, and content like JavaScript does. You can even convert existed HTML webpages to the C++ source files. In this way, we can use the same UI description files for device apps, client apps, and even web apps.
-
HAE will be cross-platform, one device app written in JavaScript can run on any operating system (Linux/Windows/macOS/Android/iOS) directly.
We think that this is a universal solution for the GUI programming framework, and never be out of date.
The concept of activity and intent is almost the same ones like
other platform, such as Android.
In HybridOS, you can think of one activity as one webpage. Generally, an activity is created by a HVML file. However, not like a web browser, the HVML file of an activity of a HybridOS app is not generated by a HTTP server, but it is loaded from the asset manager of HybridOS, specifically, HFCL.
Per webpages, we may got a dynamic HTML content by send a request to the HTTP server with different parameters. In HybridOS, the dynamic content of an activity is obtained by using intent and the new tags introduced by HybridOS View Markup Language.
When you create an activity, you can pass a JSON object as intent to the activity, and the HVML parser will use the intent data to generate some new HVML elements.
When the user submits a form in an activity, HybridOS will pass the data in JSON format to the next activity as the intent. In this way, a HybridOS app will run like a web app without the HTTP server.
Note that HybridOS also provides the traditional way to fetch a HVML file from a remote HTTP server. In this situation, the intent data will be included in the HVML file.
For a HybridOS app running in a device, most of resource assets of it should be stored locally, either on file system or embedded into the program image.
You can use the URL scheme file to locate an asset, for example,
an image, which is stored on file system. However, HybridOS provides
more flexibility to support assets which are embedded in the
program image. We call this type of asset as in-core resource.
For such assets, a HybridOS app can still use file to refer to
them. But the app don't have to worry about whether the asset comes
from a local file system or is data embedded in the program image.
In HybridOS, HVML files, image files, media files, GNU gettext
mo files are all assets of a HybridOS app.
The goal of a service of one HybridOS app is providing data for other components of HybridOS.
As described in HybridOS Architecture, one HybridOS app can register a request handler at a specific endpoint. When there is a request on this endpoint which comes from HybridOS HTTP, MQTT, or CoAP servers, the server forwards the request to this app, the app handles the request and returns the response data to the server.
For example, a HTTP request may be sent to the device:
http://foo/bar/get_current_value?which=temp
Here foo is the host name of the HybridOS device, bar is the
app name, while while get_current_value is the endpoint registered
by the app.
On a traditional OS, the request handlers commonly are implemented by centralized Python scripts. On HybridOS, the request handlers will be implemented by individual HybrdiOS apps.
Not only that, the request handlers implemented by HybridOS apps can serve many application protocols, including HTTP, MQTT, or CoAP.
The implementation of a service is called a request responder.
Generally, a request responder runs in a separate thread (or process).
For different protocols, the response data should be represented in different forms. For example, HTTP needs returns a HTML document instead of a raw JSON data.
Therefore, the HybridOS app framework should provide a way to convert the response data in JSON to a specific representation form.
One HybridOS apps can interact with the system daemons by using hiBus in two ways:
- Listen to system events. For example, the changes of WiFi signal strength.
- Send a commend to a system daemon synchronously or asynchronously. For example, connect to a WiFi hotspot.
For security, one HybridOS app which want to listen or talk to a specific system daemon needs to get an access token from the security daemon first. If the app does not have the corresponding permission, or the access token is expired, the daemon will deny the access.
The access token are bound to the signature of a HybridOS app. For more information, please refer to HybridOS Security Design.
On device, HybridOS app runs in Linux sandbox.
For more information, please refer to HybridOS Security Design.
hiBus provides a secure data bus mechanism for communication between different modules of the system. One HybridOS app can send commands to the specified server via hiBus, the server returns the execution result, or HybridOS can listen for certain types of events, and the underlying server or daemon sends events to the app via hiBus.
For more information, please refer to hiBus.
hiWebKit, a WebKit derivative, provides support for HybridOS View Markup Language, as well as the popular Web standards and specifications such as HTML 5.x and CSS 3.
HFCL (HybridOS Foundation Class Library) provides a set C++ APIs to create and manage resource, activities, services for your HybridOS apps, also provides support for customizing the view type defined by HVML.
hybrid.js provides APIs for the JavaScript edition of one HybridOS app, to create and manage resource, activities, and services of it.
For more information, please refer to [hybrid.js].
For a long time, the development of an embedded or IoT apps is basically a loop of the following steps:
- Write code on the host;
- Cross compilation on the host;
- Transfer the image to the development board;
- Run the program on the development board;
- If encountered any problem, go to the first step.
Through high-level abstraction, HybridOS isolates apps, servers, and the underlying details of system. As a result, most of the debugging work can be done on the host. Not only that, HybridOS's device emulation environment can also simulate the underlying communication protocols such as mobile/wireless networks (NB-Iot, 4G/LTE, Bluetooth, WiFi) and other peripherals. This will greatly reduce the development complexity of HybrdiOS apps and help the developers focus on business code rather than system code.
For more information, please refer to HybridOS Device Simulation Environment.