UIQ 3 basics
From UIQ Books
UIQ 3 Basics
UIQ 3 enables mobile phone manufacturers to create a range of products that have different hardware characteristics but use the same codeline. You can write a UIQ 3 application and deploy it to all UIQ 3 phones via a single package (SIS file). This chapter explains the fundamental concepts so that you can understand how UIQ 3 delivers this flexibility.
UI Configuration
UIQ 3 supports a variety of screen and hardware configurations. These are defined using parameters. Many configurations are theoretically possible, and more options may be added as new types of hardware and user interaction are developed. In practice, you will work with just a few UI configurations, as we explain later on.
Configuration Parameters
Screen Mode
Screen Mode defines the screen resolution in pixels and its position; portrait or landscape:
| Screen Mode | Display Size (width x height) | Position |
|---|---|---|
| Portrait | 240 x 320 (QVGA) | Portrait |
| Landscape | 320 x 240 (QVGA) | Landscape |
| Small | 240 x 256 | Portrait |
| Small Landscape | 240 x 256 | Landscape |
Figure 1 UIQ 3 screen modes
UIQ3 is optimized for these display resolutions, but a phone manufacturer may build a phone having a different screen resolution. Your application can find out the exact resolution from the screen device.
If the UI configuration changes from portrait to landscape, it also rotates the four navigation keys (up, down, left, right) so that they stay lined up correctly with the screen. For example up becomes left. Typically, the phone operates in portrait mode and applications that want to use landscape switch the display to that mode, generally via a command.
Screen Orientation
UIQ3 supports inversion of the screen by 180 degrees. What this means in practice is that, where supported, the user may choose to see Landscape mode by turning the phone to the left or to the right.
| 
|
| Landscape (Normal) | Landscape 180 (Inverted) |
Figure 2 Screen orientation
Your application does not need to do anything special to support inverted mode, it is handled by UIQ3. The 4-way navigation keys are transposed so that they operate correctly in the new mode.
Touchscreen and Interaction Style
The touchscreen parameter indicates the presence of a digitizer, typically a touchscreen layer applied to the front of the screen.
Interaction style defines the way the user works with the phone.
Softkey Style is optimized for one-handed use without a touchscreen.
Softkey Style Touch is based on Softkey Style, but allows both one-handed use via softkeys and two-handed use via a touchscreen.
Pen Style is optimized for two-handed use. The phone is held in one hand and applications are used by means of a stylus held in the other hand. A touchscreen is required for this mode. Hardware buttons can also be used to interact with applications.
UIQ 3 Screen Layout
The UIQ 3 screen is divided into five areas, two of which differ between Softkey Style and Pen Style interaction. The anatomy of the screen is described in more detail in the Chapter Understanding UI components.
Softkey Style Screen Layout
Status Bar
The Status bar presents information such as signal strength, battery status and unread messages. It is configured by the phone manufacturer and cannot be used by third party applications. In Softkey Style the Status bar is read-only; in Softkey Style Touch and Pen Style, the user can tap on the icons to see further information and access settings.
Title Bar
The application name and icon are displayed in the Title bar. In Pen Style, additional icons provide access to the menu and category selection.
Figure 3 Screen areas in Softkey Style and Softkey Style Touch
View Context Area
Applications typically break down data into a number of pages. The first (default) page shows the most important information, such as the appointment name, data and time, while details such as location and notes are provided on extra pages. Where there is more than a single page, tabs are displayed in the view context area, one for each page. In Softkey style, the left and right keys can be used to change page; in Softkey Style Touch and Pen Style, pages can be selected directly by tapping on the required tab. Additional status information can be provided in the space to the right of any tabs.
Application Space
This space belongs to the application. Building blocks, which we will describe later, are typically used to construct application views.
Softkey Labels
In Softkey Style, the labels for the three softkeys are displayed here
Pen Style Screen Layout
In Pen Style, the Status bar is positioned at the bottom of the screen and the Softkey labels are replaced by a Button bar.
Figure 4 Screen areas in Pen Style
Button Bar
The Button Bar can be configured to have up to three buttons rather like the Softkey bar, up to nine icons or a combination of these.
Pre-Defined UI Configurations
A reference configuration plus four further configurations make up the five pre-defined UI configurations supported in the application development platform and used in current UIQ 3 phones.
Name/Constant (qikon.hrh)
| Screen Mode | Touchscreen | Interaction Style | Orientation |
|---|---|---|---|---|
| Softkey Style (reference)
| Portrait | No | Softkeys | Normal |
| Softkey Style Touch
| Portrait | Yes | Softkeys | Normal |
| Pen Style
| Portrait | Yes | Menu Bar | Normal |
| Pen Style Landscape
| Landscape | Yes | Menu Bar | Normal |
| Softkey Style Small
| Portrait, small | No | Softkeys | Normal |
A phone can only display one UI configuration at once but may support a number of different configurations. A hardware event may change the configuration, for example closing the flip on a Sony Ericsson P990i changes from Pen Style to Softkey Style Small. You can access a list of the possible System UI configurations that are available on a phone using the CQikUiConfigClient interface.
These are the default UI Configurations of current UIQ 3 phones:
| Phone | Name/Constant (qikon.hrh) |
|---|---|
| Motorola
MOTO Z8 | Softkey Style
|
| Sony Ericsson
M600i, W950i, P1i, W960i | Softkey Style Touch
|
| Sony Ericsson P990i
(Flip open) | Pen Style
|
| Sony Ericsson P990i
(Flip closed) | Softkey Style Small
|
You will need to define which UI configurations your application supports. When it starts, the UIQ 3 application framework will select the most appropriate of your supported UI configurations, meaning the one that fits best to the current UI configuration. This best fit ability means that you do not have to care about orientation; your application will work in both normal and inverted orientation, for example. We describe this in more detail in the ListView1 application in the Chapter List boxes.
Alternatively, your application view may request a different screen mode; for example switching from the default Portrait mode to Landscape mode. The UIQ 3 application framework reads this request and, if necessary, changes the current UI configuration before activating the view. The web browser, for example, can switch from portrait mode to landscape mode under user control.
Because of its hardware flip design, the Sony Ericsson P990i supports the most UI configurations of any UIQ 3 phone to date:
- Pen Style Touch Portrait (default with flip open)
- Pen Style Touch Landscape
- Pen Style Touch Landscape Inverted (180)
- Softkey Style Small Portrait (default with flip closed)
- Softkey Style Small Landscape
- Softkey Style Small Landscape Inverted (180).
Figure 5 Sony Ericsson P990i UI configurations
Apart from the P990i, all the other Sony Ericsson UIQ 3 phones to date operate in Softkey Style Touch by default and also support Pen Style Touch Landscape in normal mode (not inverted).
Sony Ericsson phones support landscape in full screen mode only, since this the most useful for applications.
| 
|
Figure 6 Sony Ericsson P1i UI configurations
Softkey Style (Reference Configuration)
Softkey Style is the Reference Configuration. This is a new UI configuration introduced in UIQ 3. It is intended for phones with smaller displays and keypads and does not require a touchscreen. The UIQ applications are optimized for this UI configuration. As well as the UI configuration parameters for Softkey Style, UIQ makes recommendations for the hardware.
Screen properties:
- 240 x 320 pixels (portrait mode)
- dot pitch: 0.14 mm
- minimum screen size: 2.2’’ - 34 mm x 45 mm
- color depth from 8-bit (256 color) to 24 bit (> 16 million colors).
Mandatory hardware keys:
- Four-way navigation (up, down, left, right)
- Action key
- Left and right softkeys (LSK and RSK)
- Clear (backspace) key
- Send and End (phone)
- Numeric keypad (0-9, *, #)
- Application launcher key.
Optional hardware keys:
- Cancel (Back) key
- Video call
- QWERTY keyboard
- Done key
- See UIQ Product Description for further supported keys.
Figure 7 Softkey Style UI Configuration with 3SK & Back
In UIQ 3.0 the Cancel (Back) key is mandatory and the arrangement is called 3SK&B (Three Softkeys & Back). The hardware key is used for the Back operation. From UIQ 3.1 the hardware key is optional. The Back function is instead represented as a Back label placed on the right Softkey. This variant is called 3SK (Three Softkeys). Manufacturers can choose from two different softkey configurations so that the softkeys on UIQ 3 based phones match other phones in the portfolio.
Figure 8 Softkey Style UI configuration with 3SK
In this book, we use the 3SK&B model for Softkey Style commands. This is used by current Sony Ericsson phones that run in Softkey Style Touch and the P990i in Softkey Style Small (flip-closed) mode. This mode is presented in the UIQ 3.0 emulator. To see 3SK, use the UIQ 3.1 emulator. We will look at command handling in more detail in the Section Command Processing Framework.
At this point, it’s useful if we describe the behavior of the hard keys in more detail.
Up and Down
- navigate up and down lists
- navigate inside an activated control.
Left and Right
- switch page within a view (moves across the tabs in the View Context area)
- navigate within a view
- navigate within an activated control.
Action
- select command displayed on the center Softkey label
- select highlighted item within an activated control.
Clear
- deletion of characters in an editor
- deletion of an item in a list
- cancel and go back when navigating within applications.
Cancel (Back)
- cancels and closes an active control or pop-up such as the menu
- closes the view or dialog performing the Back function.
Send/End
- The MOTO Z8 uses Send to make a call and End to end it.
- Sony Ericsson‘s phone application that is softkey driven. It does use Send or End keys.
Application Launcher
- mandatory for Softkey Style phones like the MOTO Z8
- Sony Ericsson provides an alternative implementation via the start (idle) screen and status bar.
Softkey Style Touch
Softkey Style Touch can be used in exactly the same way as Softkey Style via the hardware keys. Adding a touchscreen means that applications can also receive input from stylus operations such as tapping controls and dragging scrollbars. The UI layout is modified slightly in this mode so that then pen can be used. Softkey Style Touch is a fully-enabled touchscreen interface; some key differences are shown below:
Figure 9 Comparison of Softkey Style (top) and Softkey Style Touch (bottom)
In the UIQ emulator, the Softkey label area has a flat background; there are no graphical dividers between the three labels.
Sony Ericsson phones modify the style of the Softkey labels so that they look and behave like three buttons. This reminds the user that it is possible to touch the screen.
Figure 10 Agenda (Calendar) application on Sony Ericsson P1i
From Figure 10 you can also see how Sony Ericsson has customized the UI with its own graphics and colour scheme.
Pen Style
This configuration is similar to the UIQ versions 1.0 - 2.1, but targets displays with a slightly smaller dot pitch In UIQ 3.0, Pen Style is a reference configuration.
Interaction style:
- pen on touchscreen, with menu bar.
Screen properties:
- 240 x 320 pixels (portrait mode)
- dot pitch: 0.165 mm
- minimum screen size: 2.6’’ - 40 mm x 53 mm.
- color depth from 8-bit (256 color) to 24 bit (> 16 million colors).
Recommended hardware keys:
- four-way navigation (up, down, left, right)
- Action key
- Send and End (phone) keys
- Done key.
Figure 11 Pen Style UI mode
Here is the UIQ Agenda application in Pen Style mode. While some tasks can be carried out one-handed, it is optimized for two-handed use and some tasks can only be carried out using the stylus.
Figure 12 Agenda application edit view in Pen Style UI mode
Here is the main view of the Agenda application, showing iconic rather than textual buttons in the Button Bar.
Figure 13 Agenda application month view
Some applications benefit from a different UI approach when a touchscreen is present. You are free to implement a different GUI for each UI Configuration where this is beneficial. The Calculator application has been designed in this way so that one-handed use in Softkey Style is optimized. Numbers can only be entered using the hardware keypad, so no number keys need to be displayed on the screen. Instead, the calculator functions are laid out in a grid so that they can be easily selected using the four-way navigation and Action keys.
Figure 14 Calculator in Softkey Style
In Pen Style, the calculator can have a traditional layout. Numbers can be entered via the screen or hardware keypad.
Figure 15 Calculator in Pen Style
Pen Style Touch Landscape
Figure 16 Pen Style Touch Landscape
Applications can take the full screen in any UI configuration. This is particularly useful for displaying video, pictures, web content and games, especially in landscape orientation. If your application uses this mode, make sure it is easy for the user to get out of full screen and back to other applications.
Figure 17 Pen Style Touch Landscape (full screen)
Softkey Style Small
The Sony Ericsson P990i uses Softkey Style Small mode when the number-pad flip is closed and part of the screen is obscured. The application space is reduced in size.
Figure 18 Softkey Style Small UI configuration
Building Blocks and Layout Manager
In UIQ 2, the layout of an application was manually created by the application developer. UIQ 3 introduces the concepts of a Building Blocks and Layout Manager.
Building Blocks
In UIQ 3 you use building blocks to place controls in the application space on the screen. Each building block has a defined layout and handles the placement of the controls to achieve the correct margins and alignment.
System Building Blocks
The 18 standard building blocks can be used in any combination; this makes layout design extremely flexible. You can choose a set of building blocks to compose a layout that suits your application. Technically, building blocks are controls themselves, but they have no visual appearance or state information; they are simply containers for other controls. Each building block has a defined layout and a number of slots where controls are inserted. Using the standard building blocks that UIQ 3 provides makes the behavior of your application predictable and familiar to users. You can also create custom building blocks for specific layout needs.
Keeping the user interface consistent across applications and phone models is easy with building blocks. They manage the layout of the controls as well as managing focus and highlight.
Figure 19 Designing a view using building blocks
Prior to choosing which building blocks to use, you need to decide how much information you need to display. Try to use a set of building blocks where all of the blocks are of the same height. This way, the highlight will also have the same height no matter which building block has focus. (The first building block containing the image does not take focus in the above example.) The visual effect of scrolling through the building blocks will then be a smooth instead of a jumpy, which would distract the user from the task at hand.
Custom Building Blocks
If you require a layout that is not supported by any of the standard building blocks, you can create custom building blocks either programmatically or from resource files. Using custom building blocks means that the appearance and good scrolling behavior of your application is maintained.
Figure 20 Making a custom building block
You can define further parameters of your custom building block such as:
- horizontal and vertical margins
- horizontal and vertical alignment
- number of visible text lines before truncation.
Layout Managers
Layout managers are introduced in UIQ 3 to make it easier to implement the layout of controls. If you are using building blocks, then the role of the layout manager is hidden and you do not need to worry about it. The difference is that building blocks are controls themselves while layout managers are a mechanism for laying out controls. Building blocks are basically compound controls that are also arranged by a layout manager.
If you create a control which cannot be placed in a building block, or for some reason you do not wish to use building blocks, layout managers are a good alternative for managing layout. The view can be laid out in rows, columns, a grid or as a flow. Flow means that the controls are laid out along rows, breaking to a new row when there is not enough space for the next control.
Figure 21 Layout manager types
Layout managers are covered in more detail in the Chapter Layout managers and building blocks, and an example application, LayoutManager1, shows row and grid layouts in operation.
Command Processing Framework
Users interact with a mobile phone and applications by giving commands. Applications are typically in a waiting state until the user selects an action to be performed.
As we have seen, UIQ 3 introduces a set of UI configurations which use the screen and keys in different ways. It is no longer possible to define a single menu structure that can work effectively across all the available configurations. To make it possible to support all UI configurations from a single codeline, UIQ 3 includes a Command Processing Framework (CPF). Instead of programming commands directly on to buttons and menus, applications present an abstract set of commands and the CPF is responsible for presenting them in the UI, including hardware buttons, softkeys and menus. Each view, dialog and popout has its own command list, while individual controls can also add commands.
You give each command in your application parameters such as type, priority, group and behavior flags which guide the CPF to present each one in the best way. Some types such as Yes, No and Done give very specific direction because softkeys are used for these commands wherever possible. Other types, like screen, make a command generally available so it will typically end up in a menu.
In the same way, you do not explicitly dim a command when it is unavailable, you set the CPF parameter SetAvailable to false. In Pen Style, UIQ 3 will dim the menu option, however in Softkey Style the option will not be displayed so that the user does not have to navigate over it.
Figure 22 Command Processing Framework outline
Because the CPF does the work, you do not have to worry about arranging commands for each UI mode. It is important that you work with the abstract system rather than trying to force commands to display in a specific way. However, you can specify different commands or parameters for each UI configuration if necessary, so that you can present the most suitable functionality in each case. The Chapter Commands and categories provides a Commands example application and describes in detail how you can add commands to your application.
Commands in Softkey Style
In the 3SK&B Softkey model, commands are based on the three softkeys and the Cancel (Back) key:
Figure 23 Commands in Softkey Style (3SK&B)
The softkey actions are defined by labels across the bottom of the screen.
The Center key is used for the most likely action, and is often linked to the item that has focus; these commands have type item.
The left softkey is used for:
- Done
- positive and safe actions like Yes and Save
- second-most-likely actions (second item command)
- ‘More’ – access to a menu (3SK).
The right softkey is used for:
- negative or destructive actions like No and Cancel
- third-most-likely actions (third item command)
- ‘More’ – access to a menu (3SK&B)
- Back (3SK).
‘More’ is the most common usage of the right softkey (3SK&B) or left softkey (3SK). In this case, the third-most-likely action and other actions are placed in to the menu.
The 3SK variant differs from 3SK&B in the following ways:
- The Action key label (Center softkey) duplicates the left softkey in case only two actions are available; meaning also the Action key is used to select a positive command. An icon,
, is displayed on the Action key when this occurs.
- The Clear key which is used to delete text in text input mode can also be used to Cancel and go back when navigating between and within applications in non-text input mode.
- The command on the Action key label (Center softkey) is also available as the first item in the menu when available.
- 3SK places the More menu on the left softkey.
The MOTO Z8 uses the 3SK variant. If you look at this model, you will notice that the ‘More’ menu is called ‘Options’ and located on the left softkey. The right softkey is used as the Back button. Other Motorola phones use this type of interaction model. Keeping a similar interaction model across different mobile phones is important to manufacturers. Customers moving from one model of phone to another will expect similar behavior. Consistency also reduces technical support training effort and reduces the number support requests from users.
Examples in this book use the 3SK&B variant, as found on current Sony Ericsson phones that operate in Softkey Style Touch configuration. The Contacts application shows how the hard and softkeys are used in practice:
Figure 24 Commands in the Contacts application, phone number highlighted
Looking at the detail view of a contact with the highlight on a telephone number, the center softkey is assigned the most obvious action of making a call. The left softkey is assigned the second most likely action of sending a message. Contacts is a rich application with many more commands, therefore the right softkey gives access to a menu. The third most likely action, make a video call, is placed in the menu:
Figure 25 Menu in the Contacts application
When the menu is open, the navigation keys move focus and the center softkey is used to select the required menu item and the right softkey closes the menu. It is possible to define cascading menus.
If we move the focus to the Email address, the labels change to reflect the different actions that are possible with an Email address:
Figure 26 Commands in the Contacts application, Email highlighted
Send an Email is the most obvious action and is assigned to the centre key. A second option is to send an MMS. The right softkey still provides access to the menu.
If we try to delete the contact, the confirmation dialog conforms to this convention by placing Yes on the left softkey and No on the right:
Figure 27 Confirmation dialog in Contacts (UIQ 3.0)
Here we can see the addition of the 
symbol in UIQ 3.1, indicating that the Center key duplicates the default action (Yes in this case).
Figure 28 Confirmation dialog in Contacts (UIQ 3.1)
Softkey Style Touch
If a touchscreen is present, UIQ 3 allows the softkeys and menus to be driven by the pen as well as via the hardware buttons.
Commands in Pen Style
In Pen Style, most commands are actioned via controls displayed on the screen. The action key (clicking in the Jog Dial on Sony Ericsson phones) is also used, together with the navigation keys.
Looking at the Contacts application detail view in Pen Style UI configuration, we observe that the three most common actions on a telephone number are now available by touching the screen:
Figure 29 Commands in the Contacts application (Pen Style)
The most likely action (make a voice call) is also mapped on to the Action key.
The main menu is accessed by clicking the 
symbol next to the application name. In this case, the Make video call and Create message commands are repeated.
Figure 30 Menu in the Contacts application (Pen Style)
The CPF also works in dialog boxes, where up to three textual buttons or nine icon buttons can be displayed. Commands not visible as buttons are placed in a title bar menu, accessed via a symbol. You can specify which commands are preferred on buttons.
Figure 31 Confirmation dialog in the Contacts application (Pen Style)
Figure 32 Button Bar and Menu in dialog (Pen Style)
Commands in Full-Screen Mode
In Softkey Style, it is important to leave the Softkey labels on the screen, so that the user can still access commands:
Figure 33 Full-Screen mode, Softkey Style
In Pen Style, you can choose whether to display the button bar or not. The menu is made available from an icon:
Figure 34 Full-Screen mode (Pen Style)
If your application needs to go completely full-screen, it may do so. You must clearly implement a key action or command within your application UI that exits full-screen mode.
Categories
UIQ applications frequently use categories to break up data into more easily manageable subsets. In the Contacts and Agenda applications, for example, categories Work and Personal can be created to classify entries.
UIQ 3 has a specific UI model for working with categories, that is, creating, deleting, allocating and filtering. In Softkey Style and Softkey Style Touch, category selection and management is done using the menu:
Figure 35 Category menu in Agenda (Softkey Style)
In Pen Style, a special category menu is added to the Title Bar and Category operations are selected from a drop-down menu in much the same way as UIQ 2.
Figure 36 Category menu in Agenda (Pen Style)
Categories are described in more detail in the Chapter Commands and categories, together with an example application.
UIQ 3 Operational Model
When a UIQ 3 phone is switched on, it goes to a start or idle screen which is configured by the phone manufacturer. This screen can also be customized for mobile operators.
Figure 37 Sony Ericsson P1i idle screen
Frequently used applications such as Contacts, Agenda and Messaging are typically available directly from the idle screen, which is often user-configurable so that different users can access their favorite applications easily. Additional applications are accessed via the application launcher. The Sony Ericsson P1i provides an icon which the user can tap with the stylus or access using the Jog-Dial.
The MOTO Z8 idle screen looks like this:
Figure 38 MOTO Z8 idle screen
The MOTO Z8 provides a Home key 
to reach the application launcher.
Figure 39 Application launcher
Newly installed applications appear in the application launcher.
UIQ 3 applications typically follow a list-and-details model. When we first open an application, it displays a list view of the data:
Figure 40 List view
We can navigate up and down the list to find the item we want. We can program the list view so that important tasks are possible directly from the list view. UIQ 3 provides extensive support for constructing list views; The Chapter List boxes describes this in detail.
From the list view, the default operation is typically to view the item in detail. The most frequently needed information is displayed first:
Figure 41 Contacts Detail View (main page)
Less frequently used information is available on further pages within the view:
Figure 42 Contacts Detail view, Birthday and Address page
We have already provided an introduction to the parts of the screen in the Section UIQ 3 Screen Layout. We provide further information in the Chapter Understanding UI components while the Chapter Views and dialogs shows you how to build views and dialogs.
View Layout Construction
A resource file is a text file in which you can define user interface items. It is compiled into a compressed binary file. UIQ 3 makes extensive use of resource files to define views, dialogs and commands, although they can also be defined in code. The resource structure allows a lot of freedom and can look complicated at first, however, once you understand how a view is constructed you should find it easy.
In this section we introduce the structure in simple terms. As you go through the example applications, we will show you in detail how to work with resource files.
For each view in your application, the resource file typically defines the following;
- list of UI configurations declared for the view
- view and command lists to be used in each UI configuration
- command definitions for each view
- layout for each view.
In the simplified example below, we support Pen Style and Softkey Style UI configurations in our view configurations. We use the same layout in each case, View 1, however, we supply a different command definition for each configuration. If the mobile phone is in a UI configuration that is not declared, UIQ 3 will select the declared view configuration that it considers to be the most suitable.
We can define single or multi page views, and use building blocks to arrange the layout. Individual controls are placed in our chosen building blocks.
Figure 43 Simplified resource definition
Commands can be defined at various levels including view, page and item (linked to controls that gain focus). The CPF takes in to account all of these in determining where to place commands.
Figure 44 shows the data entities that can be declared and how they are related.
Figure 44 View resource files and related structure
Changes from UIQ 2.1 to UIQ 3
If you are familiar with UIQ 2.1, this section summarizes the key changes in UIQ 3 for you. These are the main headline changes:
- UIQ 3 is based on Symbian OS v9; UIQ 2.1 is based on Symbian OS v7.0.
- Platform Security is introduced with Symbian OS v9.
- UIQ 3 provides increased flexibility in UI configuration.
- UIQ 3 enables keypad input as well as touch-screen input, as described in the section UI Configuration.
- Building blocks and Layout Managers help you construct your application views, as we describe in the section Building Blocks and Layout Manager and the Chapter Layout managers and building blocks.
- A Command Processing Framework (CPF) is introduced so that your application can specify its commands without needing to worry about the UI configuration. We describe this in the section Command Processing Framework and Chapter Commands and categories.
- UIQ 3 provides enhanced customization features.
- UIQ 3 has improved public APIs.
You can read more in the UIQ migration quick guide and Programmer’s guide to new features documents.
If you have UIQ 2.1 applications that you wish to port to UIQ 3, you can find examples in the Special Interest Paper – Porting and Porting DreamConnect to UIQ 3 papers.
Symbian OS v9
Symbian OS v9 has a new security architecture which introduces two important concepts: capabilities and data caging.
Capabilities
Functions which are sensitive, meaning, for example, that they may incur cost to the user or compromise privacy, are protected and your application must have the appropriate capabilities to be able to use sensitive APIs.
There are three groups of capabilities:
- User Capabilities. These cover resources that the user can understand and grant when your application is installed, such as send an SMS or access the phone book.
- System Capabilities. These cover sensitive operations that could threaten the integrity of the mobile phone.
- Device Manufacturer Capabilities. These cover unrestricted file system access, access to Digital Rights Management protected content and the ability to install software, load executable code and so on.
System and Device Manufacturer capabilities are assigned to your finished application by the Symbian Signed process. User capabilities can be granted by the user, but we recommend that you also sign your application for these. During development, you can use Open Signed to test your application on real mobile phones.
Symbian Signed and capabilities are explained in detail in the Chapter Symbian Signed. We also show you how to build an application, SignedApp that is capable of passing Symbian Signed. The Chapter Building an application introduces SignedAppPhase1 and SignedAppPhase2, while Chapter Multimedia adds some multimedia functionality to provide SignedAppPhase3 that we have successfully signed.
Data Caging
Application data has been separated from application code to provide a simple, trusted path on the platform. An application’s stored data can be hidden from other applications.
The file system has the following structure:
-
\sys. This is the restricted system area which can only be accessed by highly trusted system processes. -
\sys\bin. Holds all executables such as EXEs, DLLs and plug-ins. The OS will not run code placed in other locations. -
\private. Each application has its own private view of the file system consisting of\private\\where SID is a unique security identifier taken from the program’s UID. The application should use this sub tree to hold the data files. -
\resource. A public read-only directory that allows files to be publicly shared without compromizing integrity. An application should, for example, put its UI resource files and icon files in\resource\apps.
Other directories are public and can be read from or written to by any program. An application installation package can install files in, or below, another application's \private\\import directory if such a directory exists.
New Kernel Architecture
Symbian OS v9 introduced a new kernel architecture (known as EKA2, EPOC kernel architecture 2), security model and tool chain, compared to that used in previous versions. There is a binary break from the earlier versions of Symbian OS which means that UIQ 2.1 applications are incompatible with UIQ 3. In some very simple cases it is enough to recompile the code, however, most applications require code changes.
Application Building
UIQ 3 introduces significant changes to the MMP and PKG files; the AIF file is replaced by two resource files.
MMP File
The target type for applications has been changed from APP to EXE.
UIQ 2.1:
TARGET HelloWorld.app TARGETTYPE APP
UIQ 3:
TARGET HelloWorld.exe TARGETTYPE EXE
The Vendor ID (VID) is new in Symbian OS v9 and specifies the vendor of the application executable. In most cases, this will be zero or omitted from the MMP file, which means that the source of the executable is not required for security checks. VIDs are allocated to Symbian licensees, partners, operators and Independent Software Vendors through sign-up programs.
VENDORID 0
If your application requires capabilities in order to access protected APIs, these are defined in the MMP file:
CAPABILITY LocalServices ReadUserData
The LIBRARY keyword lists the import libraries needed by the application. The build will report link errors (unresolved externals) if you don't specify all the required libraries. The class-level documentation in the Developer Library tells you which library to import for each class. No path needs to be specified and each library statement may contain several libraries, separated by a space. More than one library statement may also be used.
// Specifies import libraries LIBRARY euser.lib LIBRARY apparc.lib LIBRARY cone.lib LIBRARY eikcore.lib LIBRARY eikcoctl.lib
STATICLIBRARY is used to specify statically linked libraries (object code that is built into your application). All UIQ applications should link against a UIQ-specific heap allocator library, which is designed to be more effective in out of memory situations. This is done as follows in a mmp file:
// New heap allocator, which is more effective in out of memory situations. // You only need to include the libs in the mmp file to use the new heap allocator. STATICLIBRARY qikalloc.lib LIBRARY qikallocdll.lib
PKG File
The following changes have been made in the PKG file:
- updated product ID for UIQ 3
- new keywords for mapping media files.
The most important change is the definition of the product ID:
UIQ 2.1:
(0x101F617B), 2, 0, 0, {"UIQ20ProductID"}
UIQ 3:
[0x101F6300], 3, 0, 0, {"UIQ30ProductID"}
Resource Files Replace AIF File
The Application Information (AIF) Files is no longer used. It is replaced by a pair of resource files:
- registration resource file,
AppName_reg.rss, which defines the non-localizable items.' - localizable resource file,
AppName_loc.rss, which contains localizable information such as caption and icon file definitions.'
View Construction
As we explain in the Section View Layout Construction, UIQ 3 makes much greater use of resource files than either UIQ 2.1 or S60. Views, dialogs and commands can be defined in resource files.
Application Framework
Application
Since the application target has been changed from .app, which was loaded dynamically by the framework as a normal DLL, to an executable (.exe), the application entry point has also been changed. The E32Dll() entry function, normally placed in the CQikApplication derived class, is now replaced by E32Main().
Views
UIQ 3 introduces two new view classes, CQikViewBase and CQikMultiPageViewBase. The CQikMultiPageViewBase class is a base class for views with multiple pages. Application views are derived from either of these two base classes instead of from the CCoeControl and MCoeView as was the case in UIQ 2.1.
The CQikViewBase class is the base class for all views and all UIQ views should be derived from it. This class handles much of the new functionality found in UIQ 3:
- construction of views, controls and layouts from resource files
- basic focus management
- hardware-button navigation between controls
- command handling
- interface for runtime UI Configuration switching
- handling the context bar.
Also related to views is the new dialog class QikViewDialog. This class implements a view which can be invoked as a dialog. This means that common code can be used for both views and complex dialogs.
A second new class, CQikSimpleDialog, is intended for cases where a simple dialog, such as a yes/no query, is needed.
Views and dialogs are covered in detail in the Chapter Views and dialogs.
UIQ 3 releases
Compatibility across UIQ releases
UIQ enables 'future proofing' applications by providing backwards compatibility in the platform. To target all UIQ 3 phones, build your application with the UIQ 3.0 SDK and avoid phone-manufacturer specific SDK extensions. Test the applications with both the UIQ 3.0 emulator and the most recent one, and of course on phones you have available. If you need an API or feature available only in a more recent version of the UIQ platform then use the matching SDK but be aware that your application may not work on phones using previous versions of the UIQ platform.
Changes from UIQ 3.0 to UIQ 3.1
UIQ 3.1 is current at the time of writing this book. While UIQ 2.1 to UIQ 3.0 was a very significant change, UIQ 3.1 makes relatively minor changes and additions to UIQ 3.0.
These are the key changes:
- UIQ 3.1 is built on Symbian OSv9.2; UIQ 3.0 is based on Symbian OS v9.1.
- In Softkey Style, the additional softkey arrangement 3SK is introduced for phones that require the Back function to be placed on a softkey rather than a dedicated hardware key. This is explained in the Section Softkey Style (Reference Configuration).
- SVG (Scalable Vector Graphics) Tiny. The SVG Tiny 1.2 player contributes to a richer user experience by, for example, displaying animated SVG icons in the Application launcher.
- Improved Task list which provides the user with a simple way to navigate between applications. The content can be customised by the phone manufacturer.
Figure 45 UIQ 3.1 Task list
UIQ 3.2
Announced in January 2008, UIQ 3.2 is focused on enhanced support for network operator services. UIQ 3.2 is based on Symbian OS v9.2. Developers do not need a new SDK to develop for UIQ 3.2.
Rich Messaging Suite
The UIQ messaging suite has been updated with an improved design and new features:
- MMS postcard, an application which allows the user to send a picture as a printed postcard via a network operator service.
Figure 46 Postcard application
- An Instant Messaging (IM) client is provided for chatting with friends and for viewing their on-line status information. The IM client supports the OMA IMPS 1.1 specification and enables communication with other IM clients such as MSN and Yahoo.
Figure 47 Instant Messaging application
- Support for the OMA E-Mail Notification 1.0 standard offers operators the possibility to provide their customers with a push email solution.
New APIs
New API support in UIQ 3.2 includes the following significant enhancements:
- Java MSA Subset (JSR-248). With this set of APIs, developers can create a wide range of media-capable applications.
- Push Email APIs, independent of email protocol, which enable integration of third-party email clients with UIQ messaging and make them appear as native applications.
Enhanced Media Experience in the Web Browser
The media experience in the web browser has been improved by adding support for enjoying and sharing media, for example:
- support for streaming video
- the option to preview content before purchasing
- the possibility to view or listen to content before the download is completed.
UIQ 3.3
Announced in Marched 2008, UIQ 3.3 includes incremental enhancements in line with market requirements, including enhanced support for operator services and extensive customization for addressing different market segments. UIQ 3.3 is based on Symbian OS v 9.3
New version of Opera Mobile
UIQ 3.3 includes an extensively enhanced version of the Opera browser (9.5) with an improved user experience of browsing on the mobile phone including:
- Faster page loads
- A new layout engine
- A new intuitive user interface including page overview and panning
- Opera Widgets offering the user direct access to content and opening up for new mobile services
UIQ Dashboard
UIQ 3.3 is prepared for mobile widgets and features a dashboard, accessible system wide by pushing the widget button.
Figure 48 Some widgets in the dashboard
Java JSR 248 MSA fullset
The Mobile Service Architecture is the emerging standard for mobile devices running J2ME and CLDC allowing developers to create a wide range of media-capable applications. Examples of new JSR APIs: JSR 179 Location, JSR180 SIP, JSR239 OpenGL ES.
Full-feature unified messaging suite
Contains improvements in SMS and MMS such as a unified message composer allowing for the intuitive creation of SMS and MMS, Voice messaging and rich text messaging.
