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)