Updating Collections from another thread.

[David Delbecq <de...@meteo.be>]

Hello, 

Lots of pivot interfaces are backed by collection, where listeners are registered to be notified of changes. If i change such a collection from another thread (eg call List.add), does that mean pivot will update it's interface / internal state from a thread that is not the ui thread. Does pivot have same rules of "do ui operations only in EDT" as swing/awt does? 

Are there recommandations on how to perform time consuming operations with pivot? (in Swing one would recommande the use of SwingWorker) 

Thanks, 

David Delbecq 

Re: Updating Collections from another thread.

[Roger and Beth Whitcomb <Ro...@rbwhitcomb.com>]

Hi David,
     Yes, you are correct -- all UI operations (which include, as you 
noticed, many Pivot collection updates) must be done in the EDT.  In 
fact, there was a change made for the (almost released) 2.0.1 version 
that actually enforces this.
     Check out the ApplicationContext.queueCallback() method as one of 
the preferred ways to accomplish UI updates from a background thread by 
scheduling the update on the EDT with this method.  There are also the 
Task and TaskAdapter classes that are similar in nature to SwingWorker 
for doing work in the background, and doing the UI updates correctly in 
the EDT.
     There is a small Tutorial on background tasks here: 
http://pivot.apache.org/tutorials/background-tasks.html.  HTH....

~Roger

On 1/9/12 7:11 AM, David Delbecq wrote:
> Hello,
>
> Lots of pivot interfaces are backed by collection, where listeners are 
> registered to be notified of changes. If i change such a collection 
> from another thread (eg  call List.add), does that mean pivot will 
> update it's interface / internal state from a thread that is not the 
> ui thread. Does pivot have same rules of "do ui operations only in 
> EDT"  as swing/awt does?
>
> Are there recommandations on how to perform time consuming operations 
> with pivot? (in Swing one would recommande the use of SwingWorker)
>
> Thanks,
> David Delbecq
>