That looks good to me. Cheers, Chris
2009/3/19 Greg Brown <[email protected]> > 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 > >> > >> > > >
