Platform-specific issues

OS and installed applications

The OS and installed applications comprise Windows OS and applications, Linux OS and applications, access features in mainstream applications and Assistive Technology The integration process with Cloud4all/GPII in any OS or any of its applications was described above, but depending on the platform, the system may require the use of certain native and platform-specific mechanisms either to configure or launch the ATs and applications. Thus, many cross-platform and native settings handlers and launching mechanisms have been created in order to cover a wide range of use cases.

The following list covers aspects to be considered when you develop for:

  • Windows, the Windows’ native settings handlers need to be used in order to activate ATs or to configure the built-in settings of the operating system. These native settings handlers are the registrySettingsHandler and the spiSettingsHandler, which only work on this platform and are part of the GPII on Windows.
  • Windows applications, both native and cross-platform settings handlers can be used when configuring the solutions, but when launching, stopping or detecting them, native mechanisms (provided by Cloud4All/GPII) need to be used. Regarding cross-platform settings handlers, currently there are settings handlers for applications that make use of JSON, XML, INI to store their settings.
  • GNU/Linux (differs from Windows), the native settings handlers need to be used in order to configure the system, and these are the GSettings, ALSA, Orca and XRandr settings handlers. All these and more platform-specific modules are part of the GPII on Linux.
  • GNU/Linux applications (differ from Windows), as with the Windows applications, both native and cross-platform settings handlers can be used when configuring the solutions, but when launching, stopping or detecting them, native mechanisms provided by Cloud4All/GPII need to be used.

An example of the step-to-step implementation of Maavis can be found in the Cloud4all/GPII developer blog. All the implementations/integrations achieved under the above Operating Systems can be found in the solutions registry entries of the universal repository for Windows and Linux.

The access features in mainstream applications and ATs, which are currently implemented and can be implemented in new solutions, can be found in (Cloud4all, Auto-personalization from profile for PCs OS, D301.1, 2015), chapter ATs, solutions and its settings, section 2.2.

Android and Android applications

As with PC OS, the integration process of Android with Cloud4all/GPII may require the use of native mechanisms in order to configure the system or to launch applications. In order to fulfil the most relevant use cases related to Android, the following settings handlers have been created: persistentConfiguration, androidSettings and audioManager. Moreover, some other mechanisms, such as launch/stop applications or enable/disable system services have been created and included into the activityManager module; these can be used by any solution that runs on Android.

The Android applications can also be implemented by following the same integration process described in the previous section by taking into account the different platform-specific utilities. All the implemented solutions on Android can be found in the Github repository of the Cloud4all/GPII project.

The big difference between mobile OS and PC OS is its restrictive and secure design that imposes some special issues. To mention some of these:

  • The only way to add new software in Android is by creating an Android application, which has a restricted access to the system given by the SDK and has to follow the general standards and recommendations.
  • Every application runs under its own and confined user space (every app is owned by a unique user, they only have access to their own processes in the system, etc.) and is not able to communicate with other applications.
  • Most of the OS internals, which can be useful to configure the system, are not readable or writable from any application.
  • Vendors such as Samsung, Motorola or Sony include their own versions of Android (custom ROMs), so the APIs may differ or even not be available.
  • Given that Cloud4all/GPII needs to access the OS internals, the application must be installed as a system application. It requires the device to be rooted.

Another Android-related issue is that the Cloud4all/GPII should be packaged and distributed in a different way than for Windows or GNU/Linux. Following the Android restrictions, the entire Cloud4all/GPII personalization framework needs to be included within the application.

Further information can be found in the Github repository for the GPII on Android.

Browser support

The long-term goal is to have browsers support Cloud4all/GPII, without the need of extensions or add-ons. However, in the short-term, extensions are a good approach to adapt website content according to the user’s NP set. Thus, they enable APfP capabilities in browsers.

The communication mechanism established between the browser extensions and Cloud4all/GPII is, which connection is preconfigured in the browser extension. GPII handles the communication via the webSocketSettingsHandler.

Currently, there are two browser extensions developed that is able to modify webcontent that is not normally GPII compatible: “org.ilunion.cloud4chrome” for Chrome and “org.ilunion.cloud4firefox” for Firefox. A third extension has been developed in the last year of Cloud4All, working as a bridge between an installed GPII system and a GPII compatible webpage. This allows a website to retrieve settings from the GPII and modify its content accordingly whenever a user visits that site from a device running GPII.

The process of integrating a plugin differs slightly in that they should connect to the GPII on start-up and have to adhere to the API of the web sockets settings handlers to be able to retrieve settings. Other than this, the process of integrating a browser extension is identical to doing so for any other application (i.e. registering it, the settings and their relations to the common terms, etc.).

Web applications

The first three steps in the process to integrate a web application refer to the declaration of settings and transformers. They are the same as in the general process described above. The application also needs an identifier in the solutions registry for web-based solutions and transformers between the standard format terms (see the PTD above) and its own settings.

Next task is the choice of FM. There can be a FM either online or locally, in the machine where the browser is running. The latter is common in developing stages for some platforms:

  • Online Flow Manager: Web applications can connect to the Online FM. This means that they will be able to take advantage of the Cloud4all/GPII even without being on a device where it is installed. But as a consequence, they need to implement the functions that would normally be performed by some of the components of a locally installed Cloud4all/GPII, namely the User Listeners, the Lifecycle Manager and the Settings Handlers. First, the web application needs to implement a mechanism to identify the user and send a REST call with the user’s Cloud4all/GPII Token to the Online FM. The web application will then need to parse the JSON payload returned by the Online FM and to apply the settings contained in it to the application’s user interface. If the web application has a control panel where the user can tweak the user interface settings, the application will also need to implement a function to pass these changes back to the Online FM in order to update the user’s preference set.
  • Local Flow Manager: For webpages to retrieve settings from a local FM (i.e. installed system) a bridge is required. This has been implemented as a browser extension, but once Cloud4all/GPII support is built into the browser this will no longer be required. Besides this fact, the actual integration process with the Cloud4all/GPII is quite similar to that of other applications. The website needs an entry in the solutions registry specifying its settings and how they relate to common preferences. Websites will always be using the webSocketSettingsHandler, as their settings are passed to them via the browser extension (which depends on the sockets). For web applications there is no need to specify how to launch and stop like with desktop applications. One extra requirement for websites to integrate with Cloud4All/GPII is that they follow the API of the browser extension. This involves notifying the plugin that the site is GPII-compatible and following a simple API for retrieving and returning settings on request. This process is just a matter of adding some simple javascript.

Cloud-based Adaptive Technology

The cloud-based AT works in a very similar to the regular installed ATs – in that is there is a cycle of launching and setting up on user key-in and closing and restoring the system on user key-out. There are some rather important differences, though:

  • Like regular applications, the cloud-based AT is started on login, but this is done via the default browser of the system – where the browser is set to load the URL to the cloud-based AT.
  • Instead of using a settings file, the settings are applied to the cloud-based AT via URL parameters. This also means that the process of setting the AT settings is not a separate step (like when using a settings file), but rather part of the launch process step. In other words, on user key-in a single step takes place, where the browser is launched with a URL to the cloud-based AT including the settings as URL parameters.
  • The final difference is in the restoration step on user key-out. The browser with the AT needs to be closed but regular the step of ‘restoring the settings’ that happens in the standard auto-personalization process doesn’t apply to the cloud-based AT, as nothing has been modified on the system, and simply closing the browser will mean that the system can be considered restored

TV platforms

In contrast to traditional PC operating systems, a TV OS traditionally is a closed system. This means that a TV, in most cases, is not designed to execute third party applications. However, in the last few years, TVs have followed the trend of smart and connected devices. Although the number of applications for TVs is still quite limited, it is now possible to run some applications on a TV.

Still, the TV specific featuring is not exposed to third-party applications. There are very strict requirements from broadcasters to protect their content and, in addition to high DRM requirements; broadcasters also want to certify user interaction on TVs.

For this reason, the TV does not have an API towards applications to change settings and drive TV-specific features. Thus, in addition to the above described integration process for other solutions, developers on TV platforms may need to create the interfaces towards the required features.

However, developers can create a centralized component, a proxy, in the TV that acts as an interface between the Cloud4all/GPII and the TV. This proxy is then responsible to manage the required settings and features.

Moreover, if the TV does not support Cloud4all/GPII login mechanisms, an additional User Listener has to be implemented to interact with the digital TV solution. Although Cloud4all/GPII already has User Listeners for general purpose OS, embedded solutions like TVs cannot always use these inputs. However, thanks to the ease of the Cloud4all/GPII login mechanism, the effort for this is not expected to be big.

Helpful Links