從EContentAdapter更新UI的正確方法

我有一個econtent適配器，它本質上導致許多表的刷新。儘管從理論上講，可以將所有通知過濾到應該引起表格刷新的確切通知，但由於我們有一個龐大的模型，以及可能觸發一個或多個事件的許多不同事件和更改，這會非常困難和耗時刷新。此外，經常發生的情況是單個「用戶事件」（例如，在應用程序中單擊狀態 - >新建），觸發4個對象在幕後創建，所有這些對象與通知立場看起來非常相似，因此很難過濾掉。我想知道是否有一種好的方法來做某種「延遲工作」，這樣4個通知只會導致一次刷新。例如，類似於：從EContentAdapter更新UI的正確方法

public void notifyChanged(final Notification notification) 
    super.notifyChanged(notification); 
    @Override 
    public void run() { 
     if(matchesFilters(notification)) { 
      //some sort of check to see if we recently had another event that would have triggered a refresh? 
      if(!schedulingJob) { 
       scheduleDelayedJob(); 
      } 
     } 
    } 
}

不幸的是我在工作之類的東西沒有什麼經驗，所以這將是非常有益的，如果有人能夠給什麼這樣做的正確的方法是提供援助。作爲另一個例子，如果某人在我們的應用程序中非常迅速地碰到了20次控制-N，它將快速創建20個新狀態，而我們只想在這20個通知結束時更新UI，而不是刷新20次。

來源

2013-02-20 jekelija

如果我理解正確，Eclipse爲您提供了所需的全部功能。首先，應該在顯示線程上更新GUI。其次，有一種異步執行的方法，如下所示：

final IWorkbench workbench = PlatformUI.getWorkbench(); 
workbench.getDisplay().asyncExec(new Runnable() { 
    public void run() { 
    // Do your thing, e.g. refresh() 
    } 
});

你在Runner中做什麼取決於GUI框架。如果您使用的是JFace，那麼您可以執行刷新（），我相信這對於排隊工作非常明智。

來源

2013-04-24 08:28:00 jastram

不完全是我的意思，雖然這仍然有幫助。基本上，你上面的解決方案仍然會導致「我的事情」，例如如果20個通知在1秒內下降到管道上，refresh（）會發生20次。基本上我正在尋找一些延遲「刷新」一段時間的東西，這樣如果用戶非常快速地執行操作，最終不會出現刷新的日誌堵塞。 – jekelija 2013-04-25 12:03:40

從EContentAdapter更新UI的正確方法

回答

相關問題