Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

Symbian os Expleined effective C++ programming for smartphones - Batchelor D.

Batchelor D. Symbian os Expleined effective C++ programming for smartphones - Wiley publishing , 2005. - 394 p.
ISBN 0-470-02130-6
Download (direct link): symbianosexpltivec++2005.pdf
Previous << 1 .. 69 70 71 72 73 74 < 75 > 76 77 78 79 80 81 .. 151 >> Next

11.4 What Classes Does the Client-Server Framework Use?
This section gives an overview of the classes Symbian OS uses to implement the client-server framework. For further details of any of the classes, you should consult your preferred SDK. The next chapter reviews a typical implementation of a transient server3 and its client-side access code, and further illustrates how the classes I discuss here are used.
3 A transient server is started by the first client session that connects to it and shuts itself down when the last client session disconnects itself. I'll discuss server startup and shutdown in more detail in Section 11.6.
WHAT CLASSES DOES THE CLIENT-SERVER FRAMEWORK USE?
171
This section provides general background information on how the client-server framework is implemented. Although it helps to understand what is happening "under the hood", this information is not necessary simply to use a Symbian OS server. Most of the rest of the chapter discusses the implementation of a typical server or the client-side wrapper code that communicates with a server. If you don't want to get into this much detail, but want to know howto use a Symbian OS server most effectively, you may wish to skip ahead to Section 11.14.
The classes I'll discuss are as follows:
• RSessionBase -the client-side base class, representing a session with a server
• RMessage -a server-side representation of a client request and its request payload data
• DSession - a kernel class that represents a client-server session
• CSharableSession - an abstract base class for a server-side representation of a session
• CServer - an abstract base class, deriving from CActive, which is used server-side to receive client requests from the kernel and direct them to the appropriate session.
RSessionBase
RSessionBase is the main client-side class. It derives from RHandle-Base, which is the base class for classes that own handles to other objects, often those created within the kernel. RSessionBase uniquely identifies a client-server session.
Here's the declaration of RSessionBase from e32std.h (I've omitted a couple of private methods):
class RSessionBase : public RHandleBase {
public:
enum TAttachMode {EExplicitAttach,EAutoAttach}; public:
IMPORT_C TInt Share(TAttachMode aAttachMode=EExplicitAttach);
IMPORT_C TInt Attach() const; protected:
inline TInt CreateSession(const TDesC& aServer, const TVersion& aVersion);
IMPORT_C TInt CreateSession(const TDesC& aServer,
const TVersion& aVersion,TInt aAsyncMessageSlots);
IMPORT_C TInt Send(TInt aFunction,TAny* aPtr) const;
IMPORT_C void SendReceive(TInt aFunction,TAny* aPtr,
TRequestStatus& aStatus) const;
IMPORT_C TInt SendReceive(TInt aFunction,TAny* aPtr) const;
};
172
THE CLIENT-SERVER FRAMEWORK IN THEORY
The methods of this class are used to send messages to the server. You'll notice that most of them are protected. This is because the client-side class which accesses a server will typically derive from RSessionBase (for example, class RFs, which provides access to the file server). The derived class exports functions that wrap RSessionBase communication with the server and are more meaningful to potential clients of the server (such as RFs::Delete() or RFs::GetDir()).
The overloads of RSessionBase::CreateSession() start a new client-server session. They are typically called by client-side implementation code in an exported method such as Open() or Connect(). As an example, when you start a session with the file server you call RFs::Connect(), which itself calls RSessionBase::Create-Session(). When the session is opened successfully, corresponding kernel and server-side objects are created.
A server has a unique name which must be passed to RSession-Base::CreateSession() to connect the client to the correct server. Again, the client-side implementation takes care of this, so the calling client does not need to know the name of the server. CreateSession() also takes a TVersion structure4 for compatibility support.
You'll notice that one overload of CreateSession() takes an integer parameter called aAsyncMessageSlots. This value reserves a number of slots to hold any outstanding asynchronous requests that client session may have with the server.5 The maximum number of slots that may be reserved for each server is 255. The other overload of CreateSession() does not pre-allocate a maximum number of message slots. Instead, they are taken from a kernel-managed pool, of up to 255 message slots for that server, which is available to the whole system. If the number of outstanding requests to a server exceeds the number of slots in the system pool, or the number reserved for a particular session, the asynchronous request fails to be submitted and completes immediately with the error KErrServerBusy.
A request to a server is issued through a call to RSession-Base::SendReceive() or RSessionBase::Send(). Send-Receive() has overloads to handle both synchronous and asynchronous requests. The asynchronous request method takes a TRequestStatus& parameter, while the synchronous version returns the result in the TInt return value. RSessionBase::Send() sends a message to the server but does not receive a reply (and in practice, this function is rarely used).
Previous << 1 .. 69 70 71 72 73 74 < 75 > 76 77 78 79 80 81 .. 151 >> Next