- web runtime a set of rules, supporting libraries, App Framework and SDK integration to allow development and integration of web and hybrid apps targeting the Apertis system
- hybrid app a native app that includes a web page as a piece of its user interface; it may use the web runtime infrastructure but not necessarily does
The web runtime will be provided through a library that mediates the interaction between the WebView and the system, and a launcher. There will be two ways of using the web runtime: handing over the whole task to it by using the shared launcher or by picking and choosing from the library APIs. The simple, hand-over mode will be the one adopted by pure web apps (i.e. not hybrid ones) which do not need a custom launcher. It will use the shared launcher executable to start the web app. The web runtime (library and shared launcher) will be a part of the system image, alongside other frameworks such as the App Manager. The web runtime will handle the window and manage any additional WebViews the application ends up using, providing appropriate stacking.
An important note about the web app concept is in order to avoid confusion. Some platforms like Gnome and iOS support a way of turning regular web sites into what they call a web app: an icon for launching a separate instance of the browser that loads that web site as if it were a regular app. This form of web app does not provide any form of special interaction with system APIs and is not the kind of app discussed in this document.
Anatomy of a web app
Web apps will be very much like regular ones. Their bundles will contain any HTML, image, CSS and JS files they require for running, but they may also use remote resources if it makes sense.
The web runtime will ensure any caching and data storage such as the databases for cookies, HTTP cache, and HTML storage APIs will live under the application's storage area. More specifically, data such as those of cookies and HTML storage APIs will live under the Application User type while HTTP cache will live under the Cache type, see the Data Storage section of the Applications design document.
In the future a web framework may be provided to help create interfaces similar to the ones available natively. For now, the app developer is fully responsible for the look & feel of the web app.
Integration with Apertis App Framework
As with native apps, most interactions with the App Framework are to be done by the apps themselves, but there may be some cases where the web runtime itself needs to handle or mediate that integration. This section lists and addresses those cases.
App Manager (Canterbury)
Canterbury is a service that handles installation and starting applications, along with centralizing several App Framework features (some of which may end up being split in redesigns, though). The current proof of concept implementation of a web runtime includes handling of app state and hardkeys.
The app state handling currently does nothing in web runtime mode and is likely not relevant for the web runtime - the web app can connect to the service and do its own handling should it decide it is important.
Hardkey integration (Canterbury / Compositor)
Hardware keys handling is currently in a state of flux and is likely to move from Caterbury to the compositor, but the basic mechanism to register for notification is probably going to remain the same.
In the current proof of concept runtime, the hardkey handling connects to the back feature of the view, similar to the back button in regular browsers. While that may make sense for apps that use a single view and rely on navigation history alone, it may make more sense to let the app decide what to do and default to closing the top-most view if the app does not handle it. The same goes for other hardware keys.
Inter-App integration (Didcot)
Web apps security should not be that different from native apps. The same firewall rules may apply, as well as resource limits and AppArmor rules. While native and hybrid apps can easily be contained by their own AppArmor profile, pure web apps will use a shared binary and thus need a different solution.
The AppArmor API provides a change_profile function that allows specifying a different profile to switch to. Web apps will follow the convention of prefixing their profile names with *web_*, so that the launcher can be allowed to switch exclusively to web app profiles by means of a wildcard permission. The name of the profile will be the *web_* prefix plus the reverse domain-name notation used in the app's manifest and install path.
As described in the overview, being an web app does not necessarily mean that its data comes from remote web servers. Most apps should actually ship with local HTML, CSS and JS files for rendering and controlling their UIs, only using remote data like any native app would.
It is advisable that no bindings are made available at all for remote content not directly controlled by the web app publisher. This needs to be screened for in the app store approval process.
WebRuntimeApplication (GApplication subclass)
Manages WebViews, when the main WebView is closed it will quit the application. Connects to the back hardkey, tells web app about it being pressed and handles it if the app does not.
webruntime_init - WebExtension
The Web Runtime will provide a loadable web extension which will enable the following:
- handles requests for opening new windows/views and tells WebRuntimeApplication about them
- handles navigation requests for non-web, non-file schemes and hands them to Didcot
- popView(): will remove the top-most view from the stack, destroying the related WebView
- onBackPress(): the web app should provide this method by adding it to the ApertisWebRuntime object; if it exists on the top-most view, the runtime will call it whenever the back key is pressed, the boolean return value tells the runtime whether the press has been handled
- onFavoritesPress(): like onBackPress, called for the favorites button
- on…Press(): all hardware keys will have equivalent callbacks