This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: To Announce or Not To Announce Feed Title: Travis Griggs - Blog Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml Feed Description: This TAG Line is Extra Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Travis Griggs - Blog

I'm enjoying using the new Announcement framework. I've modified another triggerEvents: thingie to use it. This provider of these "events" is an object which periodically gathers data from some hardware (vi an ethernet query) and broadcasts it. Why not just let the object that wants the data get its own data? Because there are potentially lots of objects that are interested in the data gathered, and having them all hammer the hardware would be suboptimal. Also, the data of interest is really a computed delta between any last TWO acquisitions, so encapsulating this in a single object is nice.

Great. So one of these objects gets created, fires up its loop and starts announcing deltas. How does the loop ever get turned off? What I want is when no one's paying attention to this guy, he quits broadcasting. And if someone starts listening again, he starts broadcasting.

This is where an isEmpty message for SubscriptionRegistry comes in handy. We can teach this guy to determine if he has any subscribers:

hasSubscriptions
	^self subscriptionRegistryOrNil 
		ifNotNil: [:registry | registry isEmpty not]
		ifNil: [false]

updateProcessState
	(self isPolling and: [self hasSubscriptions not]) ifTrue: [self stop].
	(self isPolling not and: [self hasSubscriptions]) ifTrue: [self start]

The above basically detects the two edges it cares about, the one where it was polling but no longer has subscriptions and should be shutdown, and the other where it wasn't polling yet, but now has subscriptions and should be started.

Now it's just a matter of overriding (in the subclass sense--I really hate having to always specify whether I mean subclass reimplementation or "patch" override) some of the announcement configuring messages to hook into our updateProcessState:

when: anAnnouncementOrSymbol send: aSelectorSymbol to: anObject 
	super 
		when: anAnnouncementOrSymbol
		send: aSelectorSymbol
		to: anObject.
	self updateProcessState

We do something similar for unsubscribe: and when:do:for:.

One drawback (though gladly accepted) of the design philosophy to push the subscription management out of Object and into another object, for this case, is that it means there's no "one method" that acts as a hook for updating the subscription configuration. When I did the above using triggerEvent:, I had only to override setActionList:forEvent:. ALL modifications of the event table's state ultimately went through that. With Announcements, I had to pick the common APIs that I expected to use. For example, I didn't bother to override when:do: and unsubscribe:for:, because I didn't expect to use those.