ICCHP implementer preparation

From wiki.gpii
Jump to: navigation, search

Implementer preparation:

Name and description of the product

  • What is the product that will be made compatible with the GPI?
  • Give a short description of what it does

Attendee organization name

  • What is the name of your organization/company?

Compatability and environment

  • What OS does the application require to run. If it supports multiple OS', all need to be listed (e.g. Windows XP, Windows 7, Windows 2000)
  • (Hardware/Computer Requirements like CPU, Memory, Screen Size, Disk Space (for running))
  • (Perephicals requirements, like speakers/audio, microphone, mouse device, etc.)

To tell the GPII when an application is relevant, we need to know what operating system(s) it runs under, and any other device requirements there might be to the machine.

Background: The architecture currently has a single component reporting about the environment, namely the DeviceReporter, and it currently only reports the OS. This will later be extended to report things like CPU, Memory, etc., and supplemented with other environment reporters, reporting applications installed, current time, etc.

Location and Format of settings

  • Where are the settings file(s) stored? (and does this location depend on OS, user settings, some registry value?)
  • What format are the settings stored in? (eg. xml, json, registry, gsettings)

For GPII to be able to change the application settings, it needs to know where to find these settings and how to write to them. There are several ways to store your prefences, e.g. in .xml, .json, .ini, or even a binary file or using the operating systems built in features, like the windows system registry or the gsettings tool of Gnome.

Background and Recommendations: The architecture uses SettingsHandlers to deal with the settings of applications. Since the way of writing preferences to eg. system registry, XML files and json files is very different, a SettingsHandler needs to be implemented for each. For this reason, it is recommended to use a common method for storing your preferences, since the likelihood of a SettingsHandler already being implemented and high standard is higer. Likewise, it is recommended that the path to your settings (be that in the system registry, gsettings schema or for a file on the system) is the (system) standard location.

The SettingsHandler is called by the LifeCycleHandler when on user login and logout to change and restore settings, respectively. If an application has its settings spread across several places, it can have several SettingsHandlers, one for each location/format.

Starting and closing the application

  • How is the application launched?
  • Any specificities/curiosities related to launching (eg. location of exe file, prerequisites for application start)?
  • How to (gracefully) close the application
  • Any specificities related to closing the application

To be able to launch applications, the GPII need to know how to launch the application (eg. via an .exe file, launch a shell script, switching a gsettings flag, etc). Furthermore, if the launching might differ from OS to OS, installation to installation, or the like this needs to be handled by the GPII. Furthermore, anything else relevant related to launching the application is relevant to know, as this will have to be handled by the GPII as well.

For closing the application, the most graceful way is preferable. This is used when on user login and logout respectively and handled by the Lifecycle Actions managed by the LifeCycleManager.

Detecting whether the application is running

  • how to detect whether the application is running.

How this is detected will vary from OS to OS and application to application, but generally it should be sufficient to provide the name of a process expected to be seen in windows 'tasklist.exe' or unix' 'ps' command. Alternative methods could be using a small script to detect it, or checking a flag in gsettings.

NB: This is not currently implemented in the GPII architecture, but will be required in the future to know whether to update an already running application, launching it, or even a combination of killing/launching the application. This handles by Lifecycle Actions managed by the LifeCycleManager.

Notifying the application of updated settings

  • how to notify the application that it's settings have updated and it needs to refresh

If an application is already running when a user logs into the GPII, and the settings of this application are changed by the GPII, it needs some means of notifying the application that it should re-read its settings and perhaps reconfigure itself. This scenario is very likely to be the case for some applications (web browsers/built in features) and less likely for others - but always a possibility. While it's a nicer user experience to have the application automatically adapt while running, an alternative and perfectly acceptable option/answer is that the requires to be restarted (i.e. closed and then started) to be able to detect the settings.

Background: This is handled by one or more Lifecycle Actions - depending on the notification strategy. Like with all Lifecycle Actions it is managed by the LifeCycleManager

Detecting whether application is installed

  • How to detect whether the application is installed
  • Detecting the version of the application (if applicable)

This is could involve checking for a specific registry key, a specific file in some location (but be aware that this should be applicable even if user has chosen custom settings on install).

NB: Currently unimplemented. This is used by the Device Reporter to be able to tell which solutions are installed on the system. This limits the list of relevant and available solutions sent to the Matchmaker.

Anything else

  • Is there any specific behavior of the application that might be relevant to the GPII?
  • What else is useful to know about the application?"

All the questions on this page, are things that are necessary to take into account when making an AT compatible with the GPII, but there might be other information that could be relevant -- either simplifying or complicating handling the application. Generally, put anything here that might be useful to know about the application, in particular, anything that is special/unique for your application. Examples could be that: the application is running as a service, the 'application' is just a webpage running in a browser, the preferences can be got dynamically -- anything that might be relevant to the architecture/GPII.