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.
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
Close1 are default actions with no changes.
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.
Control pane and menu definitions
In an application user interface the action is rendered according to its referer:
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).
Action1but 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:
When a handler is defined it can be assigned to an action:
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.
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.
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|