Difference between revisions of "WebRuntime"

From Apertis
Jump to: navigation, search
m (App Manager & Hardkey integration (Canterbury): Fix typo)
Line 34: Line 34:
 
== App Manager & Hardkey integration (Canterbury) ==
 
== App Manager & Hardkey integration (Canterbury) ==
  
Canterbury is a service that handles instalation 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.
+
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 of course connect to the service and do its own handling should it decide it is important.
 
The app state handling currently does nothing in web runtime mode and is likely not relevant for the web runtime - the web app can of course connect to the service and do its own handling should it decide it is important.

Revision as of 09:57, 10 February 2016

This page is a work in progress.


Definitions

  • 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
  • web app an application using web technologies such as HTML, CSS and JavaScript, integrated on the system through the web runtime
  • native app an application targeting the Apertis system using the Apertis UI toolkit for its user interface, developed in either C or one of the other supported languages such as JavaScript
  • 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

Overview

The web runtime is provided through a library that mediates the interaction between the WebView and the system. There will be two ways of using the web runtime library: handing over the whole task to it or by picking and choosing from its helper 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 simply initiate the web runtime library and hand over the task. The web runtime will be a part of the system image, alongside other frameworks such as the App Manager, while the launcher will be a part of the app bundle. The web runtime will handle the window and manage any additional WebViews the application ends up using, providing appropriate stacking.

For hybrid apps, a custom launcher will be necessary, since more than just the web runtime is required. In that case, the web runtime library can still be useful to provide integration with the JavaScript bindings for the system APIs or to help manage additional views. The hybrid app's author will need to decide which functions to delegate and which to build based on the requirements, the web runtime library needs to be flexible to cover these use cases.

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. Web apps may also use remote resources, of course. All of them will contain at least one binary to start the app, to allow proper AppArmor containment.

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.

User interface

There will be access to the native UI toolkit through the JavaScript API, but any interface created using it cannot be mixed into the web page, of course. Being able to access those APIs may be useful for using standard dialogs, for instance. Unless the developer is writing a hybrid app, and thus rolling their own launcher, any native UI toolkit usage will only be possible on a separate window.

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 & Hardkey integration (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 of course connect to the service and do its own handling should it decide it is important.

The hardkey handling connects to the back feature of the view on the current proof of concept runtime. It may make more sense to use the back key to close views that got stacked (when the app creates a new window when a button is clicked, say). The handling of stacked views is something that the runtime has to deal with, but the app should be able to decide whether it wants to handle the key press itself as well though. To achieve that and avoid the problem of having to register twice for getting the back button press signal, the runtime will be the sole responsible for registering with the Canterbury service for this. It will then relay back presses to a JavaScript callback when it is provided by the web app. In the event the web app does not provide the callback or does not handle it (i.e. returns false), the default behaviour will be to close the top-most view.

Inter-App integration (Didcot)

Applications can tell the system to launch other applications by using the content hand-over service (Didcot). The API used to communicate with the service will be available to the JavaScript context through the bindings provided by seed, but regular links in web apps can use the same schemes used by the content hand-over mechanism. The WebView provided by the web runtime library will automatically handle navigation to those schemes and call the content hand-over API.

Audio Management

Apertis uses an Audio Manager to let apps register and release audio resources. It may be necessary to patch WebKit to interact with this service for both the regular WebView and the web runtime. However, the audio management is being redesigned, and may end up not requiring any kind of manual registration.

Security

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. To properly make it contained by AppArmor, each web app has its own executable loader shipped on its bundle. 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.

Notice however that this is not a rule, web apps may also come in the form of simple shells for content downloaded from a remote web server, in which case it is probably advisable that the system API made available to the app be limited. For this reason, the JavaScript bindings will make it possible to use a blacklist or a whitelist to describe which modules are made or not available to a given app. It is advisable that no bindings are made available at all for remote content not directly controlled by the web app publisher.

Potential API

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.

WebRuntimeWebView (WebKitWebClutterView subclass)

This is a WebView with a few additions:

  • makes GObject bindings available to the page's JavaScript context
  • 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

A few JavaScript methods will also be made available by the WebRuntime itself through a globally available ApertisWebRuntime object:

  • 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