1 <?xml version="1.0" encoding="utf-8"?>

     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

     3 <!-- This component and the accompanying materials are made available under the terms of the License 

     4 "Eclipse Public License v1.0" which accompanies this distribution, 

     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

     6 <!-- Initial Contributors:

     7     Nokia Corporation - initial contribution.

     8 Contributors: 

     9 -->

    10 <!DOCTYPE concept

    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

    12 <concept id="GUID-37CB6D0C-41F0-5C52-A925-978FAC30D311" xml:lang="en"><title>Implementing

    13 the Client Side</title><prolog><metadata><keywords/></metadata></prolog><conbody>

    14 <p>The animation framework requires implementers to write server side and

    15 client side code. On the client side, provided by the Window Server Client-Side

    16 API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita"><apiname>RAnimDll</apiname></xref> should be derived from

    17 for DLL level functionality, and for each animation an <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita"><apiname>RAnim</apiname></xref> class

    18 should be derived. The client side classes can be thought of as thin layers

    19 of code that are used to pass information through to the matching server side

    20 classes, where the detailed logic is implemented. </p>

    21 <p>Clients must request an animation DLL to be loaded before the animations

    22 provided by it can be used. This is done using the <codeph>RAnimDll</codeph>. </p>

    23 <p> <codeph>RAnim</codeph> provides functions for implementing client side

    24 behavior. Generally, the client side code is concerned with setting up and

    25 initializing the server side classes which implement the actual animation

    26 graphics. The mechanisms that allow information to be packaged on the client

    27 side, passed through the Window Server, and recovered on the server side,

    28 are described in <xref href="GUID-ECE9B461-B473-5B7B-B5EB-FAA60479848C.dita">Passing

    29 Arguments from Client to Server</xref>. </p>

    30 <p>Two kinds of command function are provided, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita"><apiname>RAnim::Command()</apiname></xref> and <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita"><apiname>RAnim::CommandReply()</apiname></xref>. The choice of which one

    31 to use depends on whether a return value is required and whether the command

    32 takes effect immediately or can be cached to the Window Server queue. If leaves

    33 are possible in code within or called from a command function, a return code

    34 should be tested and errors handled appropriately. </p>

    35 <p>The <codeph>CommandReply()</codeph> function forces immediate action. In

    36 general by the time these functions return, Window Server requests have been

    37 carried out. The background to this behavior is Window Server buffering of

    38 the requests it receives. In effect the behavior of these commands is to put

    39 a request to the Window Server queue and then flush the queue to ensure immediate

    40 action. The <codeph>Command()</codeph> function is buffered by the Window

    41 Server. Although these functions return immediately, there is no guarantee

    42 when the Window Server request will actually be carried out. </p>

    43 </conbody><related-links>

    44 <link href="GUID-E5CDDA05-CD86-5C44-B9DA-3249D9C14396.dita"><linktext>Client-Side

    45 Buffer</linktext></link>

    46 <link href="GUID-FAF1B60A-A4B5-5E45-B9B9-84DA982F2E2B.dita"><linktext>Animations</linktext>

    47 </link>

    48 </related-links></concept>