Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 15
Текст из файла (страница 15)
Polymorphic DLLs are used heavilyby Symbian OS for this purpose. Polymorphic DLLs normally do not endin .dll, but in an extension that is more descriptive of the type of plug-inthey are implementing (e.g., .prt for a networking protocol module).Polymorphism is built into C++, and is arguably one of its best features.To implement polymorphism in C++, you have a base class with one ormore methods declared as virtual (and in many cases it’s pure virtual,meaning there is no code for it in the base class at all).
This base classthen acts as an abstract interface to classes derived from the base class.SHARED CODE: LIBRARIES, DLLS, AND FRAMEWORKS67The methods themselves are implemented in concrete classes derivedfrom the base class. However, to implement polymorphic behavior, youaccess the objects through a base class pointer, relying on C++ to automatically call the overridden method in whatever concrete class is assignedto that base pointer. In this way you have common code that behaves thesame, no matter which concrete class is assigned to that base pointer.Polymorphic DLLs use C++ polymorphism across the DLL file boundary.
To give you an idea of how this works, here is some code to load apolymorphic DLL and call a method:RLibrary library;_LIT(KPluginName,"printerX.apr");library.Load(); // load a pluginTLibraryFunction entry=library.Lookup(1)GenericPrinter* printer= static_cast<GenericPrinter*> entry();// ...// common abstracted codeprinter->PrintDocument(MyDoc);// ...Don’t worry if you do not understand the details in this code (andit’s not really complete; it does not verify the DLL type or have errorchecking). The intent is not to teach you how to write a polymorphicDLL, just to show the general concept.This code snippet uses the class, RLibrary, to load the polymorphicDLL containing the PrinterX concrete class (I just used extension .apr,standing for ‘a printer’).
The code then calls the first exported functionin the DLL (Lookup(1) returns a pointer to this first function) – this willinstantiate the PrinterX class and return a pointer to it. This pointeris then assigned to the printer base class pointer for controlling theprinter through the abstracted base class interface. Lastly, printer->PrintDocument(MyDoc) is called, which will print the documentusing PrinterX.apr’s implementation of that function specific to theprinter the plug-in represents.3.3.3 ECOM FrameworkECOM is a software framework used for implementing plug-ins – it hascustom functionality for different entities of a particular type, whilemaintaining a consistent, abstract interface to them. Isn’t that whatpolymorphic DLLs do? Yes, but ECOM is a more extensive framework forthis.
While polymorphic DLLs allow for abstracted interfaces, the methodof finding and loading the available DLLs falls on each application. ECOMprovides for a generic framework for handling this higher-level plug-infunctionality.More information about ECOM can be found in Symbian OS forMobile Phones Volume 3 and Symbian OS Explained.68SYMBIAN OS ARCHITECTURE3.3.4 Static Data in DLLsDLLs written using Symbian OS versions earlier than v9.0 cannot containwritable static data. This means you cannot declare global non-constantvariables externally in functions (automatic variables are fine since theyare on the stack), or have non-constant static variables declared withina function or class. This can be limiting, but Symbian made this choiceto conserve memory due to the large number of DLLs that can be loadedat a time.This example will not work in a DLL:int myGlbVar;void myfunc{}Nor will the following:void myFunc{static int myVar;...}However, constant data is permissible – this will work fine:const int myData=4;void myFunc(){int myVar;...}From Symbian OS v9.0 onwards, this restriction is removed, and DLLsmay contain writable static data.
While this can greatly simplify the taskof importing code from other operating systems, the practice of usingwritable static data can have a significant impact on memory usage, andis strongly discouraged.3.4 Client–Server ModelSymbian OS software relies on a client–server architecture to implementmuch of its functionality. A server in Symbian OS has no user interfaceand acts mainly as an engine to manage some resource or functionalityon behalf of other programs, which become clients to the server. Serverscan receive commands from one or more clients and execute theseCLIENT–SERVER MODEL69commands, one by one.
A server always resides in a separate thread fromits clients and usually is also contained in its own process.An example of a server in Symbian OS is the file system server. Thisserver runs as a process (it’s an EXE file) and receives and executescommands to manage the creation, reading, and writing of files on thedevice’s memory drives. The API classes that applications use to managefiles (e.g., RFs, RFile) are client-side classes that send commands tothe file server (transparently to the API user), which then executes thefunctionality. The client-side class typically resides in a DLL.The basic execution flow of a server is:1. Wait for a command to be received from the client (data may also besent with this command).2. When the command is received, execute it.3. Return the status (and any data) to the client (this can be synchronously or asynchronously).4.
Go to step 1.Not only are many applications written using this model, but muchof the OS itself is implemented using it. In most cases the details of thecommunication between the client and the server are hidden in API calls.Figure 3.1 shows several callers communicating with two servers (forexample, the file system server and the window server). Note that acaller may use more than one server and that some servers communicatewith each other. As mentioned, servers are always in separate threadsfrom their clients (although multiple servers can exist in a single thread).App1Client DLLWindowServerWindowServerClient DLLFile ServerFile ServerApp2App3Thread boundaryFigure 3.1Client/Server Interaction70SYMBIAN OS ARCHITECTUREData is transferred between the client and the server using inter-threadcommunication functionality within Symbian OS.
In the case of thewindow and file servers used in the example shown in Figure 3.1, theservers are contained in their own processes, and reside in EXE files.Symbian OS provides a client–server framework that handles thedetails of the communications between the client and server. Chapter 10describes this framework in detail, and shows how to use it to write yourown server and the client-side class that interfaces with it.3.5 Memory in Symbian OSLet’s look at the different types of memory that exist on a smartphonebased on Symbian OS:•Random Access Memory (RAM)RAM is the volatile execution and data memory used by runningprograms. Applications vary in how much RAM they use, and this alsodepends on what the application is doing at the time. For example, abrowser application loading a web page needs to allocate more RAMfor the web page data as it’s loaded.
Further, the more RAM spaceyou have, the more programs you can run on your smartphone atonce. Typically, mobile phones have between 7 and 30 MB of RAMavailable for applications to use.•Read Only Memory (ROM)The ROM is where the Symbian OS software itself resides. It includesall the startup code to boot the device, as well as all device driversand other hardware-specific code.
This area cannot be written to bya user, although some of it can be seen by the file system as drive Z.For added efficiency, code in ROM is executed in place – that is, itis not loaded into RAM before executing, although this is not true forall types of ROM. Typically, a phone has between 16 and 32 MB ofROM.•Internal Flash DiskThe internal flash acts like a disk drive and allows for reading andwriting files to it via the Symbian OS file system.
The file systemis fully featured and supports a hierarchical directory structure, withvery similar features to those you would find on high-end operatingsystems. The internal flash drive is represented as the C drive to thefile system. This memory contains user-loaded applications, as well asdata such as documents, pictures, video, bookmarks, calendar entries,etc. The size of the internal flash disk varies with the phone, but itcan be quite generous.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
