Preguntas de TreeViewer diferidas y diferidas

Question

En realidad tengo dos preguntas, pero están relacionadas, así que aquí van como una sola...

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 espectador los muestra, nunca se lo suelta, por lo tanto, un error de memoria si su árbol tiene una gran cantidad de nodos y hojas y no lo suficientemente grande.¿Existe algún tipo de práctica recomendada para evitar pérdidas de memoria causadas por una vista que nunca se cierra y que contiene un visor de árbol con grandes cantidades de datos (cientos de miles de objetos o incluso millones)?¿Quizás haya alguna interfaz de devolución de llamada que permita una mayor flexibilidad con los elementos del espectador/proveedor de contenido?

¿Es posible combinar diferido (DeferredTreeContentManager) Y perezoso (ILazyTreeContentProvider) cargando por un solo TreeViewer(SWT.VIRTUAL)?Por lo que entiendo al observar ejemplos y API, solo es posible usar cualquiera de ellas en un momento dado, pero no ambas juntas, por ejemplo., obtenga solo a los niños visibles para un nodo dado y busque en un hilo separado usando la API de trabajo.Lo que me molesta es que el enfoque diferido carga a todos los niños.Aunque en un hilo diferente, aún cargue todos los elementos a pesar de que solo se muestra un subconjunto mínimo a la vez.

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

Actualmente estoy luchando con ellos, así que si logro encontrar algo mientras tanto, con mucho gusto lo compartiré aquí.

¡Gracias!

Saludos, Svilen

Answer 1

El marco de Eclipse a veces me parece esquizofrénico.Sospecho que el DeferredTreeContentManager en lo que se refiere a la ILazyTreeContentProvider es uno de estos casos.

En otro ejemplo, en EclipseCon el año pasado recomendaron que usara fábricas de adaptadores (IAdapterFactory) para adaptar sus modelos al contexto de enlace necesario en ese momento.Por ejemplo, si quieres que tu modelo aparezca en un árbol, hazlo 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());

Registre su adaptador y BaseWorkbenchContentProvider encontrará la adaptación en fábrica.Maravilloso.Suena como un plan.

"Por cierto, cuando tengas grandes conjuntos de datos, hazlo 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 el primer y segundo ejemplo no sólo son incompatibles, sino que se excluyen mutuamente.Estos dos enfoques probablemente fueron implementados por diferentes equipos que no tenían un plan común o tal vez la API esté en medio de una transición a un marco común.Sin embargo, estás solo.