diff -r ebc84c812384 -r 46218c8b8afa Symbian3/PDK/Source/GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita --- a/Symbian3/PDK/Source/GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita Thu Mar 11 15:24:26 2010 +0000 +++ b/Symbian3/PDK/Source/GUID-BBC374AD-88E6-5C58-88BB-B939C2948DDA.dita Thu Mar 11 18:02:22 2010 +0000 @@ -1,50 +1,50 @@ - - - - - -Application -user interface (AppUi) -

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:

- - - - - + + + + + +Application +user interface (AppUi) +

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)

  • +
\ No newline at end of file