WO2007063263A1

WO2007063263A1 - An interactive computing device with a configurable user interface

Info

Publication number: WO2007063263A1
Application number: PCT/GB2005/003858
Authority: WO
Inventors: Matthias Reik; Johan Carnegard; Jonas Lindeborg; Mattias Petersson
Original assignee: Uiq Technology Ab
Priority date: 2004-10-05
Filing date: 2005-10-05
Publication date: 2007-06-07
Also published as: JP2008516358A; CN101044451A; GB2419009A; GB0422090D0; GB0520269D0; EP1834232A1

Abstract

An interactive computing device or apparatus is able to support a plurality of U1 Configurations and can switch from one U1 Configuration to another U1 Configuration dynamically during normal operation. The supported U1 Configurations are a subset of the possible permutations obtained from all the different individual hardware and software settings for the device. Software written for such devices may, therefore, be ale to support multiple Configurations, and may respond to a dynamic switch in the U1 Configurations by adapting its own user interface to the requirements of the new U1 Configuration. The device itself may also switch U1 Configurations in response to a request from a software application.

Description

An Interactive Computing Device with a Configurable User Interface

This invention relates to interactive computing devices and in particular to an interactive computing device with diverse hardware configurations which is able to switch dynamically during operation between a plurality of Ul Configurations obtained by combining a number of different individual hardware and software application settings.

It has been proposed to provide an Application Programming Interface (API) that aims to allow a developer to write an application once only while allowing that application to run on many different types of interactive computing device.

The term 'interactive computing device' should be construed to include any device which includes both a screen or other method for displaying information and also a keyboard, keypad, button array, touchscreen or some other method for input such as selecting information; today this includes personal devices such as desktop computer, laptop computers, PDAs, Mobile Telephones, Smartphones, Digital Camera, Digital Music Players as well as many other industrial and domestic devices ranging from ATMs to domestic electrical apparatus (such as washing machines and televisions) to transport mechanisms including such devices, such as motor vehicles (of all forms), trains, boats and planes.

The most notable example of this prior art is that of Java:

"Practically from the moment the first mainframe received its first operating system upgrade, computers have been hurtling down a path of increasing fragmentation and incompatibility. Two years ago a technology emerged that held out the hope of reversing this trend and bringing some much- needed unity to today's fractured computing environments. That technology, Java, defines a common computing architecture that transcends differences in underlying systems. It fosters a new model of computing, dubbed "Write Once, Run Anywhere," which offers cross- platform operation without limiting platform diversity." (from http://java.sun.com/features/1997/aug/wora.html).

Java programs are written to run on a Java Virtual Machine instead of on a physical computer — it is the Virtual Machine that runs on a real computer. Thus a programmer can develop a program that will work on the sort of computer he/she likes and the sort of computers that his/her customers like, because the program runs inside of the Java Virtual Machines on those computers. This means that when a consumer goes to buy an application, it is not necessary to buy the "Mac version" or the "Microsoft Windows version." The consumer can buy the "Java technology version." And, as long as the consumer has the Java Virtual Machine — which is free, and available from a large number of vendors — the consumer is able to buy the program without having to worry whether it is going to run on his/her particular computer.

The problem with the prior art as described above is that the mechanism for write once/run anywhere functionality depends on the existence of the Java Virtual Machine (JVM). The JVM is a static entity, which is written to insulate the software (which is generic) from the hardware (which is specific); it is static because its capabilities are fixed when it is built. All similar solutions which depend on capabilities that are fixed at compile time or build time or install time are likewise static.

The reason why the static capabilities are problematical is because it is no longer true that the hardware on a device is unchanging. A class of computing devices is emerging which consist of hardware which can reconfigure itself on the fly; for example, the Sony Ericsson P800 and P900 smartphones are able to operate in flip open mode (large screen) or flip closed mode (small screen). There are likely to be further developments in this area; for example, devices that run in two-handed touch screen mode or one-handed button mode, devices that can run either in landscape or portrait orientation, and devices that can run on different levels of zoom for the display. Possibly the closest device that approximates to this is the current desktop PC which can have many different types of screen attached, with many different resolutions and colour depths. All PC users know that the user interface (Ul) does not automatically reconfigure itself if the screen resolution changes during run-time; sometimes a reboot is required, and at best applications have to be terminated and then restarted. However, reboots and restarts are not considered a practical option for devices incorporating mobile telephony functionality, such as modern smartphones and PDAs, which are required by users to be always on and always available.

All operating systems (OSs) and user interfaces to date have been able to assume that the hardware on a single device is essentially unchanging and therefore these OSs have made no provision for UIs that need to cope with changing hardware at run-time.

A new class of software architecture is needed to deal with this new class of hardware which is able to reconfigure itself at run-time. However, adding native run-time support for different user interface configurations to existing software platforms is non-trivial; it is unfortunately true that this would require big architectural changes that are expensive, time consuming and risky to perform.

Therefore, it is an object of the present invention to provide an interactive computing device or apparatus that is able to support more than one Ul Configuration and that can switch from one Ul Configuration to another Ul Configuration dynamically during normal operation.

According to a first aspect of the present invention there is provided an interactive computing device having a capability of a. operating in multiple supported user interface (Ul) Configurations; and b. switching from one Ul Configuration to another Ul Configuration dynamically during operation; and wherein a set of supported Ul Configurations is selected from possible Ul Configurations obtained by combining a plurality of different individual hardware and software application settings.

According to a second aspect of the present invention there is provided a method of operating an interactive computing device, the method comprising a. operating the device in multiple supported Ul Configurations; and b. switching from one Ul Configuration to another Ul Configuration dynamically during operation of the device; and wherein the set of supported Ul Configurations is selected from possible Ul Configurations obtained by combining a plurality of different individual hardware and software settings.

According to a third aspect of the present invention there is provided an operating system for causing an interactive computing device of the first aspect to operate in accordance with a method of the second aspect.

Embodiment of the present invention will now be described, by way of further example only.

This invention deals with the problem of applications that run in changing Ul configurations in a novel way. As well as enabling applications to reconfigure themselves dynamically to handle configuration changes at run-time, this invention also allows applications to request dynamic run-time reconfigurations of the hardware configuration when, without reconfiguration, they would not otherwise be able to run. Furthermore, because re- engineering an existing platform from the ground up is expensive and risky, this invention is implemented almost entirely at the Ul level.

The basic concepts underlying this invention are as follows: System level view

A Ul Configuration is a set of very high level; global settings/properties that determine the look and feel of a computing device to a user. The set of settings is built up by combining a number of different individual settings. This may include (inter alia) the following:

• Screen Mode (portrait, landscape; note that it is particularly important for landscape mode to define whether the screen is "rotated" clockwise or anticlockwise)

• Orientation ( normal, inverted)

• Zoom level (in, out)

• Touch screen ( yes, no)

• Ul Style (menubar, softkey)

These suggestions are illustrative only; the precise possibilities and values they might take are defined and controlled by the Ul designer and, in the context of the present invention, are not to be limited to the above settings. However, the various permutations of settings and values together build up a Ul Configuration. Therefore for any specific device, a relatively large number of Ul Configurations are possible by combining the different settings with each other in various ways.

This multi-dimensional complexity of a device that supports a plurality of Ul Configurations derives from the possible permutations of the settings and values, and clearly distinguishes it from the relative simplicity of those devices where only a single setting (such as the display resolution on a personal computer) needs to be considered, or where a virtual machine running is the device is used.

Devices which implement this invention may support one or more of these Ul Configurations. Support for multiple Ul Configurations on a single device requires that the device can, at runtime, switch between the different Ul Configurations. The set of Ul Configurations supported by a device is called, in the context of the present invention, the System Ul Configurations. There are a number of System Ul Configurations that are allowed on a device, all of which may be stored in a configuration file which is always set up by the hardware manufacturer, and which must be protected from unauthorized tampering. Suggested methods are to store the configuration file in read-only memory, or to adopt a platform security model such as those disclosed in GB Patent applications 0312191.0 or 0312190.2. However, the list of possible System Ul Configurations is accessible to the application framework running on the device.

At any given time there is only one out of the possible allowed System Ul Configurations active. This configuration will be referred to as the Current Ul Configuration.

Application level view

An application written for and/or optimised for several Ul Configurations will only run in those Ul Configurations that are supported by the device. Hence, there is no requirement for an application to support all Ul Configurations.

Each application can support several Ul Configurations (potentially even those that are not supported by the device) and will identify those via a Ul Configuration ID.

When the application starts it finds the best match between the Ul Configurations it can support and the System Ul Configurations supported by the device. Where one of the possible matches is the Current Ul Configuration, then that particular configuration is chosen.

However, if the application cannot run in the Current Ul Configuration but can match another of the possible System Ul Configurations, it can request that the application framework change to a Ul Configuration that it can support.

For example, should a view in an application wish to automatically swap from portrait to landscape, then the view can request a different screen mode as its preferred screen mode. Before a view becomes activated the framework will ask for the preferred screen mode. If there is one specified, the system will automatically switch to the appropriate Ul Configuration.

The example below shows a preferred implementation developed for the UIQ user interface written by UIQ Technologies AB of Ronneby, Sweden for Symbian OS, the advanced operating system from Symbian Software Ltd of London England. This is provided to illustrate the principles behind this invention and should not be construed as an indication that its applicability is in any way restricted to this particular operating system and user interface.

While some familiarity with Symbian OS and UIQ is necessary to fully understand this specific implementation, the principles behind the invention as disclosed can be applied to any OS and the insights disclosed here will be readily appreciated by anyone skilled in the art of designing user interfaces and operating systems

In this exemplary UIQ/Symbian OS implementation, the Ul configurations for each application are stored in the resource file (.rss) and identified via ui_config_id's. This file links to the .ra files for each configuration. To avoid having to store common settings in all .ra files a default .ra file is suggested with the deviations being stored in the individual .ra files.

At device startup, a set of system configurations supported by the device are created:

Onehanded portrait

• EQikUiConfigPortrait

• EQikUiConfigOrientationNormal

• EQikUiConfigSoftKey

• EQikUiConfigTouchScreenNo

Classic (two-handed) portrait

• EQikUiConfigPortrait

• EQikUiConfigOrientationNormal

• EQikUiConfigMenu

• EQikUiConfigTouchScreenYes

Onehanded landscape • EQikUiConfigLandscape

• EQikUiConfigOrientationNormal

• EQikUiConfigSoftKey

• EQikUiConfigTouchScreenNo

Classic (two-handed) landscape

• EQikUiConfigLandscape

• EQikUiConfigOrientationNormal

• EQikUiConfigMenu

• EQikUiConfigTouchScreenYes

Onehanded flip closed

• EQikUiConfigFlipClosed

• EQikUiConfigOrientationNormal

• EQikUiConfigSoftKey

• EQikUiConfigTouchScreenNo

Classic (two-handed) flip closed

• EQikUiConfigFlipClosed

• EQikUiConfigOrientationNormal

• EQikUiConfigMenu

• EQikUiConfigTouchScreenYes

However, if the uiconfig.dat file exists in c:\system\data, this set of default configurations is not created. The configuration is read from the file instead. The uiconfig.dat file is a temporary solution for booting the device in a specific screenmode.

It is possible to switch between the possible Ul-configurations with Ctrl+Alt+Shift+U. The possible screenmodes may be determined by the Windows Server from the listing in wsini.ini, which may be as follows:

AUTOCLEAR 0

STARTUP \SYSTEM\PROGRAMS\QStart

REMOVEFADINGONFOCUSGAIN

WINDOWMODE COLOR64K

TRANSPARENCY

FLICKERFREEREDRAW

SIZE_MODE 0

SCR_WIDTH1 240

SCR_HEIGHT1 320

SCR_ROTATION1 0 180

SCR_WIDTH2 320

SCR_HEIGHT2 240

SCR_R0TATI0N2 90 270

SCR_WIDTH3 240

SCR_HEIGHT3 208

SCR R0TATI0N3 0 180 The order in which the different screen modes are listed must match the declaration order in TQikScreenMode to be found in QikUiConfigManager.h.

enum TQikScreenMode

{

EQikUiConfigPortrait = EQikScreenModePortrait ,

EQikUiConfigLandscape = EQikScreenModeLandscape,

EQikUiConfigFlipClosed = EQikScreenModeFlipClosed

};

View activation

Trying to switch to an application that has not specified any of the supported device configurations in its QIK UI CONFIG struct will cause the device to switch to system default view for current screen mode.

QikScreenDeviceChangeHandler

The screendevice-change-handler is a CCoeStatic where it is possible to subscribe for changes in the Ul-configuration. Changes are propagated through the MQikScreenDeviceChangeObserver interface.

/

This class defines an interface used by the CQikScreenDeviceChangeHandler to target the control that should be notified of a screen device change . Any control implementing this interface will automatically be targeted by the screen device handler .

*/ class MQikScreenDeviceChangeObserver

{ public: virtual void HandleScreenDeviceChangedL ( ) = 0 ;

} ^; class CQikScreenDeviceChangeHandler : public CCoeScreenDeviceChangeDefaultHandler

{ public :

Tint AddScreenDeviceChangeObserver (MQikScreenDeviceChangeObserverS: aObserver) ; void RemoveScreenDeviceChangeObserver (MQikScreenDeviceChangeObserver& aObsver) ;

QikUiConfigManager

The UI-config manager is a CCoeStatic where information can be retrieved about the current Ul-configuration. Below are parts of the API: class CQikUiConfigManager : public CCoeStatic

{ public:

Tint CurrentConfigldO const; TQikUiConfig CurrentConfig() const;

TQikScreenMode CurrentScreenMode () const ; TQikTouchScreen CurrentTouchScreen ( ) const ; TQikUiStyle CurrentUiStyle ( ) const ; TQikOrientation CurrentOrientationO const; void SetCurrentConfigld (Tint aConfigld) ; void SetCurrentConfig (const TQikUiConfig& aConfig) ;

TBool IsConfigSupportedByDevice (Tint aConfigld) ;

TBool IsConfigSupportedByDevice (const TQikUiConfig& aConfig) ; void GetConfigSupportedByDeviceL(RArray<TInt>& aConfigldList) ; void GetConfigSupportedByDeviceL(RArray<TQikUiConfig>& aConfigList) ;

Naming conventions for rss files

When views are implemented in resource files, these files can quickly become too large. To help, a naming convention is adopted which for example dictates that a view should use one .ra file for each U l-configu ration. A developer is normally only interested in one configuration at a time, and is not usually concerned about changes within the other configurations. Making a physical separation of different configurations in different files simplifies whether it is necessary to care about a certain change or not.

The idea is to separate layout, control, view and command resources into separate Ul-configuration specific .ra files (included into the .rss file). Some of the (layout and command-list) resources are shared between several Ul- configu rations, and those resources should not be duplicated. Therefore a separate .ra file with those shared resources should be used.

Thus, this invention allows write-once run-anywhere software to be produced for devices which have the capability to reconfigure themselves at run time through the provision of an interactive computing device or apparatus which is able to support a plurality of Ul Configurations and which can switch from one Ul Configuration to another Ul Configuration dynamically during normal operation. The supported Ul Configurations are a subset of the possible permutations obtained from all the different individual hardware and software settings. Software written for such devices may, therefore, also be able to support multiple Configurations, and may respond to a dynamic switch in the Ul Configurations by adapting its own user interface to the requirements of the new Ul Configuration. The device itself may also switch Ul Configurations in response to a request from one of the software applications.

Although the present invention has been described with reference to particular embodiments, it will be appreciated that modifications may be effected whilst remaining within the scope of the present invention as defined by the appended claims.

Claims

Claims:

1. An interactive computing device having a capability of c. operating in multiple supported user interface (UI) Configurations; and d. switching from one Ul Configuration to another Ul Configuration dynamically during operation; and wherein a set of supported Ul Configurations is selected from possible Ul Configurations obtained by combining a plurality of different individual hardware and software application settings.

2. A device according to claim 1 in which the set of supported UI configurations is stored in a read-only file protected from unauthorized alteration.

3. A device according to claim 1 or 2 operable to switch UI Configurations in response to a request from a software application on the device.

4. A device according to claim 3 in which a change in Ul Configuration is arranged not to occur if the software application supports a Ul Configuration current on the device.

5. A device according to claim 3 or 4 operable to list the Ul Configurations in order of preference and if the software application requests a switch in Ul Configuration, the best match between the Ul Configurations supported by the software application is selected from the Ul Configurations supported by the device.

6. A device according to any of the preceding claims wherein the settings comprise any one or more of screen mode, device orientation, zoom level, touch screen and Ul style.

7. A method of operating an interactive computing device, the method comprising e. operating the device in multiple supported Ul Configurations; and f. switching from one Ul Configuration to another Ul Configuration dynamically during operation of the device; and wherein the set of supported Ul Configurations is selected from possible Ul Configurations obtained by combining a plurality of different individual hardware and software settings.

8. A method according to claim 7 in which the set of supported Ul configurations is stored in a read-only file protected from unauthorized alteration.

9. A method according to claim 7 or 8 wherein switching from one to another Ul Configuration is carried out in response to a request from a software application on the device.

10. A method according to claim 9 in which a change in Ul Configuration is arranged not to occur if the Ul Configuration current on the device is supported by a software application running on the device.

11.A method according to any one of claims 7 to 10 comprising listing the Ul Configurations in order of preference for a software application and if a switch in Ul Configuration does occur, selecting the best match between the Ul Configurations supported by the application and the Ul Configurations supported by the device.

12.A method according to any of claims 7 to 11 wherein the settings comprise any one or more of screen mode, device orientation, zoom level, touch screen and Ul Style.

13.An operating system for causing a computing device to operate in accordance with a method as claimed in any one of claims 7 to 12.