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
>>
>>
>
