preguntas TreeViewer perezoso y diferidos

Question

tengo realmente dos preguntas, sino que son una especie de relacionados, de manera que aquí se van como uno ...

¿Cómo garantizar la recolección de basura de los nodos del árbol que no se muestran actualmente usando TreeViewer (SWT.VIRTUAL) y ILazeTreeContentProvider? Si un nodo tiene 5000 hijos, una vez que el visor los muestra, nunca los suelta, , por lo tanto, Error de falta de memoria si su árbol tiene una gran cantidad de nodos y hojas y no tiene el tamaño de pila suficientemente grande. ¿Existe algún tipo de práctica recomendada sobre cómo evitar las pérdidas de memoria causadas por la vista nunca cerrada que sostiene un treeviewer con grandes cantidades de datos (cientos de miles de objetos o incluso millones)? ¿Tal vez haya alguna interfaz de devolución de llamada que permita una mayor flexibilidad con los elementos del proveedor de contenido/espectadores?

¿Es posible combinar DEFFERED (DeferredTreeContentManager) y perezoso (ILazyTreeContentProvider) de carga para un solo TreeViewer (SWT.VIRTUAL)? Por mucho que entiendo al ver ejemplos y API, solo es posible usar uno en un momento determinado, pero no ambos en conjunto, p. Ej. , busque SOLAMENTE los elementos secundarios visibles para un nodo determinado Y búsquelos en un subproceso separado utilizando la API de trabajos. Lo que me molesta es que el enfoque diferido carga TODOS los niños. Aunque en un hilo diferente, todavía carga todos los elementos aunque solo se muestre un subconjunto mínimo a la vez.

puedo proporcionar ejemplos de código a mis preguntas, si es necesario ...

Actualmente estoy luchando con los mismo así que si me las arreglo para llegar a algo, mientras tanto, voy a compartir con mucho gusto aquí.

Gracias!

Saludos, Svilen

Answer 1

que encuentran la infraestructura Eclipse veces esquizofrénico. Sospecho que el DeferredTreeContentManager relacionado con el ILazyTreeContentProvider es uno de estos casos.

En otro ejemplo, en EclipseCon este año pasado le recomendaron que use fábricas de adaptadores (IAdapterFactory) para adaptar sus modelos al contexto de enlace necesario en ese momento. Por ejemplo, si quiere que su modelo aparezca en un árbol, hágalo de esta manera.

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

Registra tu adaptador y el BaseWorkbenchContentProvider se encuentra la adaptación en la fábrica. Maravilloso. Suena como un plan.

"Oh by-the-manera, cuando usted tiene grandes conjuntos de datos, por favor hacerlo de esta manera", dicen:

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

Resulta que los ejemplos primero y segundo no sólo son incompatibles, pero son mutuamente excluyentes. Estos dos enfoques probablemente fueron implementados por diferentes equipos que no tenían un plan común o tal vez la API se encuentra en medio de una transición a un marco común. Sin embargo, estás solo.