Makes sense to me.
On Thu, Mar 19, 2009 at 5:21 PM, Greg Brown <[email protected]> wrote: > OK, I'm starting to agree. I suggest that we replace > setTimeout()/setInterval() with: > > public void scheduleCallback(Runnable callback, int period, boolean > recurring) { ... } > > This naming is more consistent with queueCallback(), and it pretty clearly > describes what it does and how it differs from queueCallback(). > > Internally, this method will continue to use a Timer. I think there is still > a valid use case for providing a static method that uses a shared timer to > schedule callbacks. Every Timer instance creates a new background thread on > which to execute its tasks, so executing a large number of tasks, each with > their own timer, would be prohibitive. On the other hand, the Javadoc for the > Timer class says that a single instance "scales to large numbers of > concurrently scheduled tasks (thousands should present no problem)". Also, > there is nothing to preclude an application developer from creating and using > additional Timers as appropriate. > > Thoughts? > > On Thursday, March 19, 2009, at 04:47PM, "Christopher Brind" > <[email protected]> wrote: >>Sorry for my vagueness, I've limited access to everything at the moment as >>I'm at the Java Symposium in Las Vegas just now so am just guessing from the >>context of these messages. >> >>As such I think I get the queueCallback method now, and with that in mind, >>what purpose do the setTimeout/Interval, clearTimeout/Interval methods >>actually serve? Is it just to facilitate JavaScript/Ajax/Flex developers >>transition to Pivot? If so, I think they are fairly redundant - do we hope >>to win these people over? I somehow can't imagine an Ajax developer >>particularly going out of their way to pick up Pivot in the first place. >>It should just be documented that Timers and queueCallback are the approach >>for those people who search for those methods, IMHO. >> >>And I agree with the comment about setXXX being for properties, Pivot >>shouldn't be mixing metaphores just because this is an RIA project. =) >> >>Cheers, >>Chris >> >> >>2009/3/19 Greg Brown <[email protected]> >> >>> >I guess my thoughts were that the internal ui queue should be private >>> >apart from one shot tasks that need to be kicked off at the end of any >>> >ui processing ie callLater. >>> >>> Not sure exactly what you mean, but I think that's pretty much how it >>> currently works. Most app developers probably won't even need to call >>> queueCallback(), since the recommended approach to execute background tasks >>> that update the UI is to use a Task and wrap the task listener in a >>> TaskAdapter (which calls queueCallback() for you). >>> >>> G >>> >>> >> >
