![[Index]](../../../../a_stock/btn_index_wt.gif){kind=small}
![[Spacer]](../../../../a_stock/btn_spacer.gif){kind=small}
![[Previous]](../../../../a_stock/btn_prev_wt.gif){kind=small}
![[Next]](../../../../a_stock/btn_next_wt.gif){kind=small}
|
|
|
|
|
|
||
Location:
obexserver.h
Link against: obex.lib
class MObexServerNotifyAsync;
OBEX asynchronous server notification interface.
Any service that provides OBEX server functionality must implement one of the two server observer classes -- this one or MObexServerNotify.
The CObexServer object handles the protocol side of an OBEX server session, while this class provides the server policy for a particular
session.
PUT and GET requests are handled asynchronously, with the upcall from the server being followed at some stage in the future by a call to CObexServer::RequestIndicationComplete to trigger processing.
Defined in MObexServerNotifyAsync:
AbortIndication(), CancelIndicationCallback(), ErrorIndication(), GetCompleteIndication(), GetPacketIndication(), GetRequestIndication(), MOSNA_ExtensionInterfaceL(), ObexConnectIndication(), ObexDisconnectIndication(), PutCompleteIndication(), PutPacketIndication(), PutRequestIndication(), SetPathIndication(), TransportDownIndication(), TransportUpIndication()
virtual IMPORT_C void MOSNA_ExtensionInterfaceL(TUid aInterface, void *&aObject);
Returns a null aObject if the extension is not implemented, or a pointer to another interface if it is.
|
virtual void ErrorIndication(TInt aError)=0;
Called if an OBEX protocol error occurs.
It is only called for fatal errors that cause the OBEX connection to terminate. An error that does not terminate the connection, for example the server issuing a semantically valid, but unrecognised command, will not be indicated.
|
virtual void TransportUpIndication()=0;
Called when the underlying transport connection is made from a remote client to the server.
Note that this does not, however, indicate an OBEX connection has been successfully established.
You can define any low-level connection policy here. It is also a good place to set up the local connection information (CObex::LocalInfo()), if any non-defaults are required.
virtual void TransportDownIndication()=0;
Called when the transport connection is dropped (by either party).
It is called whether the OBEX connection was gracefully disconnected or not. The function is the definitive place for disconnection processing.
virtual void ObexConnectIndication(const TObexConnectInfo &aRemoteInfo, const TDesC8 &aInfo)=0;
Called when an OBEX connection is made from a remote client.
Override this function to provide any extra OBEX connection processing.
|
virtual void ObexDisconnectIndication(const TDesC8 &aInfo)=0;
Called on a (graceful) OBEX disconnection by the client.
Override this to provide any extra processing OBEX disconnection processing.
Note that this indication will not be raised if the remote machine simply drops the transport connection. However, ErrorIndication() will be called if the disconnection is unexpected/ invalid (i.e. another operation was in progress at the time). In all cases,
TransportDownIndication() will be called.
|
virtual void PutRequestIndication()=0;
Called on receipt of the first packet of a (valid) put request.
It is called before any parsing of the packet is performed, simply to establish whether this server is interested in receiving objects at all.
Following this notification, the server will wait for a call to CObexServer::RequestIndicationCallback supplying a CObexBaseObject derived object to receive into or a response code specifying the error.
virtual TInt PutPacketIndication()=0;
Called on receipt of every packet of an OBEX PUT operation.
It will always be preceded by a PutRequestIndication(). The object returned by the request indication will be updated to reflect all the information received concerning the object
which the client is sending, from packets up to and including the current one.
You can use this function to provide periodic user notification on the progress of the transfer (noting that the Length attribute may take an arbitrary number of packets to become non-zero, and the constraints on its accuracy). Due to the nature of OBEX operations, where any header attribute can be sent at any point in the transfer, this is also a good place to marshal the details of a received object, and possibly prompt for action on the received object (e.g. renaming on filename clashes).
Note that this function could be hit quite heavily, in proportion to the size of the object transferred. Therefore more consideration should be given to the speed of execution of this function than that of the other indications.
|
virtual void PutCompleteIndication()=0;
Called after the final put packet has been successfully received and parsed.
Note that there will not necessarily be a call to this function corresponding to each PutRequestIndication() as, if an error occurs while the put is being carried out, ErrorIndication() will be called instead.
Following this notification, the server will wait for a call to CObexServer::RequestCompleteIndicationCallback supplying a Obex response code.
virtual void GetRequestIndication(CObexBaseObject *aRequiredObject)=0;
Called when a full get request has been received from the client.
aRequestedObject holds all the details about the object the remote client has requested. Use this function to analyse the client's request, and return a pointer to the object to be returned to the client, or NULL to return no object.
Following this notification, the server will wait for a call to CObexServer::RequestIndicationCallback supplying a CObexBaseObject derived object to send to the client or a response code specifying the error.
|
virtual TInt GetPacketIndication()=0;
Called for every packet of get reply sent by the server back to the client.
The function is only called while an object is being sent to the client, not while the client is providing its initial specification for the object it requires.
You can use this function to provide user notification on the object being sent, and its progress. As with PutPacketIndication(), you should consider that this function might get called often, especially for large objects and small OBEX packet sizes,
so the speed of execution here is important.
|
virtual void GetCompleteIndication()=0;
Called when the final packet of the object has been returned to the client.
Note like PutCompleteIndication(), this function might not be called for each GetRequestIndication(), if the operation is interrupted by an error.
Following this notification, the server will wait for a call to CObexServer::RequestCompleteIndicationCallback supplying a Obex response code.
virtual void SetPathIndication(const CObex::TSetPathInfo &aPathInfo, const TDesC8 &aInfo)=0;
Called when an OBEX SETPATH command is received by the server.
Following this notification, the server will wait for a call to CObexServer::RequestCompleteIndicationCallback supplying a Obex response code.
|
virtual void AbortIndication()=0;
Called when an abort packet is received from the client.
An OBEX abort command simply cancels the current operation, and does not necessarily have to cause the connection to be dropped. On return, a ERespSuccess packet is sent to the client.
virtual void CancelIndicationCallback()=0;
Cancel an asynchronous callback request (ie. PutRequest/GetRequest/PutComplete/GetComplete/SetPath notification).
Note that ignoring this call will lead to a panic when the indication callback function is called.
|
Copyright ©2008 Symbian Software Ltd. |
|
![[Previous]](../../../../a_stock/btn_prev.gif){kind=small}
![[Top]](../../../../a_stock/btn_top.gif)
![[Next]](../../../../a_stock/btn_next.gif){kind=small}