Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (779890), страница 72
Текст из файла (страница 72)
All applications that displaydata in more than one way are described as having multiple views. Atypical example is a calendar application, which would normally have atleast a month view, a week view and a day view.In Symbian OS, a view is defined more specifically as a class thatimplements an interface to the view architecture. The view architectureis the part of the control framework that provides the functionalityfor applications to make and receive requests to show a particularrepresentation of their data.
In addition to the view architecture providingthe mechanism for an application to switch from one of its views toanother, it also allows the operating system and other applications tocommunicate directly with an application’s views.As we have seen from many of the examples in earlier chapters, it isnot necessary for applications to use the view architecture in order toprovide displays of their data. However, UIQ 3 integrates the conceptof a view so strongly into its UI that it rarely makes sense not to useviews in UIQ applications.
Furthermore, UIQ uses the view architectureto integrate the views from all the applications on a mobile phone,a feature that enables the user to switch between applications on thebasis of the task being performed. An example of this would be to finda person’s details in the contacts list and then to open a new text oremail message, with that person’s details automatically entered in the‘To:’ field.S60 also provides classes that support the view architecture interface,but the implementation is somewhat different. S60 uses the view architecture primarily for manipulating views within applications, rather thanfor integrating views from multiple applications.39214.1VIEWS AND THE VIEW ARCHITECTUREThe View ArchitectureSymbian OS provides a view server with which each application mayregister its views. The relationship between the view server and registeredapplication views is illustrated in Figure 14.1.Application2Application1View1:1View1:2View1:3View2:1View2:2Application3View2:3View3:1View3:2View ServerFigure 14.1 The view server and application viewsIn addition to enabling switching from one view to another, registeringa view with the view server gives the following advantages:• support for saving data – if a view is registered with the view server,the data for that view is always saved before the view is deactivated• support for sending data – by packaging messages as descriptors identified by their UIDs, data can be sent from one view to another (withinthe same or different applications), via the view server.The view server interface is entirely encapsulated by application UIfunctions and the Symbian OS view interface, MCoeView.
This meansthat you, as a developer, never need to interact with it directly.The only requirement on a Symbian OS view class is that it mustbe a C class that implements the MCoeView interface, as illustrated inFigure 14.2.CBaseCxxxx«interface»MCoeViewCMyViewFigure 14.2Generic derivation of a viewTHE VIEW ARCHITECTURE393The view has to display application data, and may need to allow theuser to interact with the data, so it has to provide at least some of thefeatures of a control. However, for the purposes of defining a view, itdoesn’t matter how these features are supplied. This somewhat abstractspecification allows views to be implemented in a variety of ways. Ittherefore isn’t surprising that, although the underlying architecture is thesame, the UIQ and S60 implementations differ.UIQ ViewsUIQ provides a base class for views, derived from CCoeControl.
So,in UIQ, each view ‘is a’ control and, as shown in Figure 14.3, thearchitecture of a view-based application follows the underlying Symbianmodel very closely. Each view is owned by the application UI and theonly additional programming required is to implement the view-relatedfunctions in the application UI and the pure virtual functions defined inMCoeView.CCoeAppUICBaseCEikAppUICCoeControl«interface»MCoeViewCQikAppUICQikViewBaseCMyAppUICMyView1*Figure 14.3 Derivation of a UIQ view394VIEWS AND THE VIEW ARCHITECTURES60 ViewsAs illustrated in Figure 14.4, the S60 implementation is more specialized.CCoeAppUICEikAppUICBase«interface»MCoeViewCAknAppUICAknViewCAknViewAppUICMyViewCMyAppUI1Figure 14.4*Derivation of an S60 viewIn S60, the application UI is derived from the CAknViewAppUi class,rather than from the standard CAknAppUi.
Also, the base class for views,CAknView, is not derived from CCoeControl. Unlike in UIQ, where aview is a control, an S60 view is normally implemented as a class thatowns one or more CCoeControl-derived objects.THE VIEW ARCHITECTURE395PortabilityCreating portable views is likely to prove difficult for several reasons.In addition to the difference between the S60 and UIQ view baseclasses, each UI supports a variety of screen sizes, orientations and inputmethods. Each provides flexibility within its own view implementation toaccommodate its own permutations, but each is dependent upon its ownspecific events and, crucially, its own UI-specific controls.
Realistically,a portable view would have to be based either on Uikon or on the use ofcustom controls.The Role of the Application UIThe view server interface itself is entirely encapsulated within the application UI, which provides mechanisms to create, register and activateviews. Although the relevant functions are available in the CCoeAppUiclass, UIQ and S60 applications need to use the versions provided inCQikAppUi and CAknViewAppUI respectively.Views are normally constructed by the application UI.
Both UIQand S60 provide mechanisms for simplifying the process of constructingviews, using resource files to specify some or all of their content. Oncecreated, a view must be added to the view framework by means of a callto AddViewL() which, in S60, is prototyped as:void AddViewL(CAknView *aView);This call transfers ownership of the view to the view framework andregisters the view with the view server, using the RegisterViewL()function, which is prototyped as:void RegisterViewL(TVwsViewId);The parameter to this call is a view ID, which is described inSection 14.2.Once a view has been added to the view framework, you don’tnormally need to be concerned with its later removal, deregistrationor destruction, as these processes are performed automatically by theapplication UI’s destructor.
If, during the lifetime of the application, youwant to dynamically delete a view (other than the currently visible view)you must first call RemoveView(). This deregisters the view with theview server and removes it from the view framework. You are then freeto call the view’s destructor.396VIEWS AND THE VIEW ARCHITECTUREThe process of displaying a selected view is known as activation.Conventionally, S60 applications activate only their own views but, inprinciple, provided that a view’s unique ID is known (see Section 14.2),any application can activate any view.In both S60 and UIQ, a view is activated by calling the applicationUI’s ActivateViewL() function.
Two overloads of this function areavailable, prototyped as follows:void ActivateViewL(const TVwsViewId& aViewId);void ActivateViewL(const TVwsViewId& aViewId, TUid aCustomMessageId,const TDesc8& aCustomMessage);The second of these allows you to send an additional message ID andan associated item of data to a view. There is no restriction on the contentof the message, which can therefore be tailored to the requirements of aparticular application. If you are activating a view in another application,you need to know about the messages and data that the target view canreceive.
There is no means of finding out this information at run time, soyou have to rely on either the target application’s exported header filesor its documentation.Another problem might occur in UIQ if the target application is notrunning when you attempt to activate one of its views.
If this is likely to bethe case, you can configure the view server to start the target applicationif it is not already running. See the UIQ SDK for further details.Default ViewsEach application has a default view. Typically, the default view is displayed when the application is first started and when it is brought tothe foreground without a view being specified. This view must be constructed, registered and set as the default as early as possible duringconstruction of the application.
Depending on the nature of the application, construction and registration of non-default views could be deferredto a later time.You specify the default view by means of a call to SetDefaultViewL(), and an application may use the same call to change its defaultview while it is running. If you do not specify a default view, the frameworkautomatically chooses the one stored at index zero in its array of views.ObserversSymbian OS provides a number of view observer interfaces. Of particularinterest is the MCoeViewDeactivationObserver interface. You mightimplement this in floating windows, such as dialogs, which need to knowwhen the view underneath is deactivated.THE MCOEVIEW INTERFACE39714.2 The MCoeView InterfaceThe view server communicates with a view through the MCoeViewinterface, whose class definition is shown below.
It follows that everyview must implement this interface.class MCoeView{public:virtual TVwsViewId ViewId() const=0;private:virtual void ViewActivatedL(const TVwsViewId& aPrevViewId,TUid aCustomMessageId, const TDesC8& aCustomMessage)=0;virtual void ViewDeactivated()=0;protected:IMPORT_C virtual TVwsViewIdAndMessage ViewScreenDeviceChangedL();IMPORT_C virtual TBool ViewScreenModeCompatible(TInt aScreenMode);private:IMPORT_C virtual void ViewConstructL();IMPORT_C virtual void PrepareForViewActivation();};All views have to implement the pure virtual functions, ViewId(),ViewActivatedL() and ViewDeactivated(); they normally alsoimplement ViewConstructL(). The remaining functions have defaultimplementations, described in the SDK, that the majority of applicationsdo not need to override.The View IDThe view’s unique ID is an instance of the TVwsViewId class, whichis composed of two parts.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
