|
||
Cone provides the
CCoeAppUi
class as a generic base for application user interface development. Uikon
provides a specialization,
CEikAppUi
, from which concrete application UIs can be
derived. UI variant libraries typically derive their own AppUi base class from
CEikAppUi
to standardise common UI paradigms.
CCoeAppUi
is, therefore, normally a 'long way' from the surface of the finished
application and knows little of the concrete controls or funtionality that it
contains.
CCoeAppUi
provides the following key functionality:
An event-handling framework
CCoeAppUi
is the at the top of the run-time control hierarchy. It is the point at
which key-press events are received from the Window Server. Many of the
event-handling funtions are virtual and implemented in the derived AppUi
classes.
View Management
The View Manager (CCoeViewManager
) is encapsulated
by
CCoeAppUi
which provides a view management API.
Views are concrete classes that implement the
MCoeView
interface. Typically they are top-level window-owning controls.
The significance of views is that they are known of outside the application to which they belong. This allows one application to switch, or link, directly to a view in another. If the target application is running it will be brought to the foreground with the linked view activated. If it isn't running it will be started up first.
All of the API required for implementing, registering, activating,
deactivating, linking and observing is provided by
MCoeView
and
CCoeAppUi
.
To participate fully in the view architecture an application must register at least one view. An application with no views may still be linked to using the view architecture. It registers itself with a TVwsViewId contaning its application UID. Obviously it will not receive activation and deactivation events but will trigger view switch events in other applications' views.
An application may opt out of the view architecture (see
TApaCommand::EApaCommandRunWithoutViews
and
TApaCommand::EApaCommandBackgroundAndWithoutViews
)