CustomInterest

CustomInterest is a sample that defines an sample TInterest derived class. It modifies TSender to send this interest, as well as the standard interest. It defines an additional receiver class, TValueReceiver, that only registers for this particular interest.

This is an extension of CustomNotification.

Running the sample:

Execute CustomInterestSApp. As the notifications are sent and received, a series of values appear in the shell window. TReceiver prints out the entire series of values. The TValueReceiver also prints a message when it is notified.

Files and classes

TSender is defined in Sender.h and Sender.C. It differs from the version in CustomNotification in two respects: 1) It defines additional interest protocol, GetValueInterest, that creates a particular class of interest, TLongInterest, to represent interest in the provided value. 2) It issues notification twice when its value changes--once for receivers who are interested in any change, and once for receivers who are interested when its value matches a particular value. The same notification is sent each time.

TValueReceiver is defined in ValueReceiver.h and ValueReceiver.C. It is a new sample receiver that registers for interest in a specific value using the new protocol defined by TSender. It shows how you can add and remove interests while a connection is connected.

TLongInterest is defined in LongInterest.h and LongInterest.C. It derives from TInterest, providing state and protocol to include a long value with the interest. It implements streaming operators, Hash, and IsEqual so that the Notification framework can use it properly.

TLongNotification and TReceiver are the same as in the CustomNotification sample.

Warning

Subclassing TInterest requires implementing IsEqual, which is not part of the API. Subclasses of TInterest may not be portble to new releases of the CommonPoint(TM) environment.

Notes

Deriving TInterest is appropriate when there is an essentially unrestricted range of states that an object can be in, and when receivers are typically interested in a subset of those states. Another common case is when an object manages a collection of instances of some class, and the receivers are interested in operations affecting a particular instance.

When this technique is used, the sender can issue notifications several times with different interests. While it is tempting to try to use HasConnectionFor to reduce the need for this, it is possible that one receiver might handle notification in such a way that it or other receivers add or remove interests that would be affected. The safest option for the sender is to notify with all relevant interests and let the notifier determine whether any receivers are interested.

It is possible to respond to a notification by adding and removing interests. The Notification framework handles the concurrency issues. This sample does not illustrate this, but it can easily be modified to do so. For example, TValueReceiver could report when the value changed either to or away from its special value. To do this, it could implement HandleValueNotification to unregister interest in the value and register interest in any change. Then when the sender's value changed again, TValueReceiver could reregister for interest in its special value.

Unfortunately, the use of IsEqual to determine whether interests match (and therefore that notifications should be sent) makes it difficult to implement interest in values that meet other criteria, for instance, those over a particular threshold. Such an interest would have to be "equal" to a range of other interests in a way that was not bidirectional. In such cases the receiver would have to receive all value notifictions and filter out the ones it wished to respond to.

Click the icon to mail questions or corrections about this material to Taligent personnel.