Concepts
[Developer's Guide]

Views and View Groups

A GUI of each Agia application consists of at least one view group containing at least one view. In terms of GUI construction, a view group contains common functionality for its views while each view represents a different state of application. The view group and view elements are shown in the picture below, both in emulator (on left) and on view designer (on right).

view_group_crop_merge.png

Application can contain multiple view groups that create a view group hierarchy. A view group can contain arbitrary number of views and a view can be shared between different view groups. Combined with delegation mechanism the views and view groups provide the developer with an intuitive and flexible way of constructing structural GUI that reflects the different states of the application. With Agia tool's project properties, the user can easily bind the views to view groups and view groups to tabgroups. The latter is a typical Series 60 graphical user interface composition, where navigation pane (Navipane in pictures above) shows a tabbed pane. In addition, the state changes can be initiated with Actions.

In addition to its views, a view group manages its status pane (including navigation pane), control pane (softkeys), actions and their event handlers and menus.

Actions

Both control pane and menus in a view group contain selectable items that user can use to launch some application specific action. In other words, both menu items and softkeys can be seen as mere representatives of the corresponding actions. This would also mean that menu item and command button can both represent the same action.

This kind of action mechanism is widely used in different development environments (e.g., Delphi, C++Builder, Java, ...). Agia makes the concept available to Symbian C++ developers as well. Actions are defined in a view group level and in addition to "plain" actions, Agia supports the following default actions. The default functionality can be augmented/replaced by event handler.

Since for a non-trivial application the number of actions may become quite large, Agia tool provides a way to categorize the actions. As the categories are only an Agia tool specific convenience mechanism (there are no action categories in Agia framework), the user can define them freely.

Below are action definitions for a view group. The Options1 and Close1 are default actions with no changes.

actions_hello.png

Action definitions

Menu items are associated with their actions in Menubar tab of View Groups panel. Other possible menu elements are separators and sub menus. In control pane, each softkey can refer to an action.

hello_cba_menu_merge.png

Control pane and menu definitions

In an application user interface the action is rendered according to its referer:

actions_menu_cba_merge.png

Control pane and menu in emulator

When an action is executed (menu item or softkey is selected) its event handler gets executed. If no event handler is assigned then nothing happens (for plain actions) or the default functionality is executed (for default actions).

Event Handling

In the previous section we constructed action Action1 but without any functionality. When an action is executed it creates an event and passes it to the event handler assigned to the action. In Agia the actions' event handlers are listed in Handlers tab of View Groups Inspector panel:

handler_hello.png

Event handlers

When a handler is defined it can be assigned to an action:

actions_hello_handler.png

Action with handler

In addition to actions and event groups a similar event handling mechanism is used with widgets and views as well. Each view has a list of event handlers. Different kinds of widgets can generate different types of events and each event is handled by its assigned handler from the view's list. In other words, where actions' event handlers are view group specific, the widgets' event handlers are defined on the view level.

In terms of code an event handler is simply a member function. The details are discussed in Code Generation section.

Overridable Delegation

The state of on application is reflected by active view group and view. Thus, a typical application can have multiple view groups and views. However, it is often desirable to have features that are shared between multiple view groups (e.g., title). Thus, when a new view group is created it shares some of the features with its immediate parent in the hierarchy. Only the views are not "inherited" in the similar fashion. The mechanism where child view group uses its parent's features is called delegation. The mechanism is overridable in a sense that the child view group can also define its own version for most features.

As a simple example consider the picture below. It shows Control pane definitions for a base view group (ViewGroup1, on left) and its child (ViewGroup2, on right). ViewGroup2 has overridden the left softkey but other details of (right key and visibility) are shared.

control_pane_delegation.png

Overridable delegation

The delegation relationships are defined with Agia tool and they cannot be changed in code. For example, making the Control pane of ViewGroup2 invisible in code would hide the ViewGroup1's title as well, since the titles' Visible attribute is shared between the view groups.

While overridable delegation is quite a simple mechanism it offers developer a very flexible way of creating user interfaces. For example, consider a typical example where the contents of softkeys are changed from one view group to another. With OD the developer can either override Control pane or actions that fill it, depending on the nature of the needed changes.



VTT 30 Mar 2006