|
|
|
Changes and new features in the UI framework are described in detail in the Programmer's guide. Below is an outline of the most important changes.
The dialog classes have been changed in UIQ 3.0; the previous CEikDialog class has been deprecated and replaced by CQikSimpleDialog and CQikViewDialog.
The CQikSimpleDialog is intended for cases where a simple dialog, for example a yes/no query, is needed.
CQikViewDialog is a new framework class that extends CQikMultiPageViewBase. It provides invocation that is similar to CEikDialog invocation. This means that common code can be used for both views and complex dialogs.
Dialogs that are complex, that require scrolling or use multiple tabs, are prime candidates for porting to the View framework.
Differences between CEikDialog and CQikViewDialog:
The CEikDialog uses the same resource regardless of screen configuration. A CQikViewDialog can have different layouts for different screen configurations, just as any other view,
A CEikDialog can be non-waiting whereas the CQikViewDialog, when invoked as a dialog, is always waiting,
CEikDialog can be used as is; CQikViewDialog must always be derived. The constructor is protected. ViewId should be set if the dialog-view is to be used as a view as well.
To take full advantage of the flexibility in UIQ 3, one of the newly introduced methods for component layout should be used.
In UIQ 3.0 the concept of building blocks is introduced to support creating layouts in views. Building blocks are themselves controls with a number of slots that can be filled with any control, one control per slot.
The layout process using building blocks is:
Select building blocks,
Fill the building block slots with controls,
Place the building blocks in the view.
The SDK comes with a number of pre-defined building blocks but new building blocks can be created programmatically or from a resource file.
See the UIQ Style Guide Appendix A for a complete list of the built-in system building blocks.
If, for some reason, you cannot use building blocks for layout, layout managers can be used.
A layout manager is attached to a compound control and is used to assist the control in setting its size and position and to layout the control’s component controls.
There are four different layout managers provided by the framework: CQikRowLayoutManager, CQikFlowLayoutManager, CQikGridLayoutManager and CQikColumnLayoutManager.
The concept of row-based views address the problem of the cluttered appearance found when rows with different heights were laid out dynamically.
In row-based views, each row has the same height and a view is made up of only whole rows.
In UIQ 3, views can be created from resource files, similar to the way dialogs were created in UIQ 2.1.
When you want to create the layout of a view driven from resource, you start by defining a QIK_VIEW. A view based on CQikViewBase contains a single QIK_VIEW_PAGE while a view based on CQikMultiPageViewBase contains many QIK_VIEW_PAGEs.
A command is the visual representation of an action in an application and not the action itself. Users initiate an action by selecting the corresponding command in the user interface.
In UIQ 3, a command can be located, for example, on a softkey, in a toolbar or in a menu, depending on the interaction style of the phone. Because of this, developers cannot hardcode a command to be represented by a menu item in a menu pane as was the case in UIQ 2.1.
To deal with this, a more abstract command concept has been introduced. Instead of creating a menu item in a specific menu pane to represent an action, you now create a command to represent that action.
In addition to the text that represents a command in the user interface, a developer can set various attributes, such as type and priority, to control where in the user interface the command will be located.
Commands are either defined in a resource file with the QIK_COMMAND_LIST structure or created in code by instantiating CQikCommand.