Ленивые и отложенным TreeViewer вопросы

Question

У меня есть на самом деле два вопроса, но они отчасти связаны с тем здесь они идут как один ...

Как обеспечить вывоз мусора из узлов дерева, которые в настоящее время не отображается с помощью TreeViewer (SWT.VIRTUAL) и ILazeTreeContentProvider? Если у узла есть 5000 детей, как только они будут отображаться зрителем, они никогда не будут отпущены, , следовательно, Ошибка в памяти, если ваше дерево имеет большое количество узлов и листьев и не достаточно большой размер кучи. Есть ли какая-то лучшая практика, как избежать утечек памяти, вызванных никогда закрытым представлением, содержащим treeviewer с большим количеством данных (сотни тысяч объектов или даже миллионов)? Возможно, возможно, есть какой-то интерфейс обратного вызова, который обеспечивает большую гибкость в отношении элементов-провайдеров/контент-провайдеров?

Можно ли совместить deffered (DeferredTreeContentManager) и ленивая (ILazyTreeContentProvider) загрузки для одного TreeViewer (SWT.VIRTUAL)? Насколько я понимаю, глядя на примеры и API, можно использовать только один в заданное время, но не оба вместе, например. , Извлечь ТОЛЬКО видимых дочерних элементов для заданного узла И получить их в отдельном потоке с помощью Job API. Меня беспокоит то, что отложенный подход загружает ВСЕ детей. Хотя в другом потоке вы все равно загружаете все элементы , хотя одновременно отображается только минимальное подмножество.

Я могу привести примеры кода на мои вопросы, если требуется ...

Я в настоящее время борюсь с теми себя так, если мне удастся придумать что-то в то же время я с удовольствием поделюсь здесь.

Спасибо!

С уважением, Svilen

Answer 1

Я считаю, рамки Eclipse, иногда шизофреник. Я подозреваю, что DeferredTreeContentManager, относящийся к ILazyTreeContentProvider, является одним из этих случаев.

В другом примере на EclipseCon в прошлом году они рекомендовали использовать фабрики адаптеров (IAdapterFactory) для адаптации ваших моделей к контексту привязки, необходимому в то время. Например, если вы хотите, чтобы ваша модель отображалась в дереве, сделайте это так.

treeViewer = new TreeViewer(parent, SWT.BORDER); 
IAdapterFactory adapterFactory = new AdapterFactory(); 
Platform.getAdapterManager().registerAdapters(adapterFactory, SomePojo.class); 
treeViewer.setLabelProvider(new WorkbenchLabelProvider()); 
treeViewer.setContentProvider(new BaseWorkbenchContentProvider()); 

Зарегистрируйте свой адаптер и BaseWorkbenchContentProvider найти адаптацию на заводе. Замечательно. Звучит как план.

«О бай-зе-пути, когда у вас есть большие массивы данных, пожалуйста, сделать это таким образом», они говорят:

TableViewertableViewer = new TableViewer(parent, SWT.VIRTUAL); 
// skipping the noise 
tableViewer.setItemCount(100000); 
tableViewer.setContentProvider(new LazyContentProvider()); 
tableViewer.setLabelProvider(new TableLabelProvider()); 
tableViewer.setUseHashlookup(true); 
tableViewer.setInput(null); 

Оказывается, что первый и второй примеры не только несовместимы, но они 'взаимно исключая. Эти два подхода, которые, вероятно, были реализованы разными командами, не имеющими общего плана или, возможно, API, находятся в середине перехода к общей структуре. Тем не менее ты сам по себе.