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 standardize
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 functionality 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
functions 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
containing
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)