libhfp: HfpPendingCommand Class Reference

List of all members.


Public Member Functions
virtual bool	Cancel (void)=0
	Request that the command be canceled and not sent.
template<typename TargT>
void	Register (TargT targp, TRet(TargT::mfp)(TA1, TA2, TA3, TA4, TA5, TA6))
	Register a simple object and method to be called.
void	Register (BaseT const &src)
	Copy the state of an identical callback object.
TRet	operator() (TA1 a1, TA2 a2, TA3 a3, TA4 a4, TA5 a5, TA6 a6)
	Invoke the callback method.
bool	Registered (void) const
	Test whether an object and method are registered to be called.
void	Unregister (void)
	Clear the currently registered object and method.
template<typename TargT>
void	Bind (TargT objp, TRet(TargT::mfp)(void))
	Register a method with a nonconforming signature to the callback object.

Detailed Description

Some HfpSession methods control the connection state to the audio gateway. Others, such as HfpSession::CmdDial(), relay commands to the audio gateway device. All HfpSession methods are asynchronous, and for longer-running operations, the method will return either having started the operation, or having failed to start the operation for whatever reason.

HfpSession methods that relay commands to the audio gateway, including HfpSession::CmdDial(), will return an HfpPendingCommand object. This object functions as a callback that is invoked when a reply is received from the audio gateway for the queued command.

Every HfpPendingCommand object returned is guaranteed to have its registered callback invoked exactly once.

The caller may also use the Cancel() method of the HfpPendingCommand object to cancel the command, although this may fail if the command has already been sent.

The caller of the HfpSession method is entirely responsible for the lifecycle of the HfpPendingCommand object. If the caller is not interested in the result of the command, it should delete the HfpPendingCommand object. Likewise, it must also delete the HfpPendingCommand object after receiving a callback, or after a successful call to the Cancel() method.

Member Function Documentation

virtual bool Cancel ( void ) [pure virtual]

Request that the command be canceled and not sent.

Return values:

	true	Command has been canceled and will not be sent.
	false	Command has already been sent or has already completed.

void Register	(	TargT *	targp,
		TRet(TargT::*)(TA1, TA2, TA3, TA4, TA5, TA6)	mfp
	)			`[inline, inherited]`

Parameters:

	targp	The object to receive the method call
	mfp	Pointer to the method of the object to be invoked

If the method to receive the callback invocation matches the signature of the callback, as specified by template parameters, this method may be used to register the target method.

For example, if the callback has signature:

 Callback<void, int, int, bool, const char *>

The method to be registered must have signature:

 void Method(int, int, bool, const char *).

Nonconforming methods may also be registered as the target using Bind(). However, Register() results in lower overhead callback invocations, and its use is advised when possible.

TRet operator()	(	TA1	a1,
		TA2	a2,
		TA3	a3,
		TA4	a4,
		TA5	a5,
		TA6	a6
	)			`[inline, inherited]`

Invoke the callback method.

Note:: If no method is registered, this will cause a segfault/access violation.

Returns:: The return value from the called method

void Bind	(	TargT *	objp,
		TRet(TargT::*)(void)	mfp
	)			`[inline, inherited]`

In the spirit of boost::bind, this module provides a generic argument remapping mechanism for target methods. This makes it possible to bind methods to callbacks where the method's signature does not match that of the callback, as long as a useful argument mapping can be created. This mechanism allows values to be stored at the time the method is bound to the callback, and passed to the target function each time the callback is invoked.

Note:: To register methods with matching signatures and no desire to remap arguments, use Callback::Register() instead. It results in lower overhead callback invocations.

Parameters:

	objp	Target object to receive the callback
	mfp	Target method to receive the callback. The signature of the method need not conform to the signature of the callback, but it must have the same return type.

Parameter 3 and on are arguments to pass to objp->mfp, and must match the signature of mfp. Arguments will be saved in the callback object and passed to the method when the callback is invoked. Special keywords Arg1, Arg2, ... Arg6 can be used to identify parameters passed to the callback by its caller, as potential arguments to the nonconforming method.

As an untypical example, suppose we want to log messages to stdout, and prefix them with either "error" or "warning" depending on which of two objects the message is submitted to.

 class Target {
        void LogValue(const char *source, const char *value) {
                printf("%s: %d\n", source, value);
        }
 };

 Target tgt;
 Callback<void, const char *> error;
 Callback<void, const char *> warning;

 error.Bind(&tgt, &Target::LogValue, "Error", Arg1);
 warning.Bind(&tgt, &Target::LogValue, "Error", Arg1);

 error("This is an error\n");
 warning("This is a warning\n");

The output would be:

 Error: This is an error
 Warning: This is a warning

This method has one specific advantage over boost::bind. It does not allocate memory under any circumstances. It will not unpredictably fail or throw an exception at runtime. On the down side, it is quite primitive compared to boost::bind. It does not support pointers to nonmember functions. Also, its stored parameters reside inside the Callback object itself. The amount of space reserved for stored parameters is larger than that set by boost::function, and Callback objects take up more space. Additionally, if a binding request is made that would exceed the space reserved for stored parameters, a compile time error will be generated.

HfpPendingCommand Class Reference [Bluetooth Hands-Free Profile Implementation]

Public Member Functions

Detailed Description

Member Function Documentation

HfpPendingCommand Class Reference
[Bluetooth Hands-Free Profile Implementation]