domande TreeViewer pigro e differite

Question

Ho fatto due domande, ma sono gentili dei relativi ecco vanno come uno ...

Come garantire la raccolta dei rifiuti di nodi dell'albero che non sono attualmente visualizzati utilizzando TreeViewer (SWT.VIRTUAL) e ILazeTreeContentProvider? Se un nodo ha 5000 figli, una volta che vengono visualizzati dal visualizzatore non vengono mai rilasciati, quindi Errore di memoria insufficiente se l'albero ha un numero elevato di nodi e foglie e non ha dimensioni di heap abbastanza grandi. Esiste una sorta di best practice su come evitare perdite di memoria, causate da una vista mai chiusa che contiene un treeviewer con grandi quantità di dati (centinaia di migliaia di oggetti o addirittura milioni)? Forse forse c'è qualche interfaccia di callback che consente una maggiore flessibilità con gli elementi visualizzatore/fornitore di contenuti?

E 'possibile combinare deffered (DeferredTreeContentManager) e pigro (ILazyTreeContentProvider) carico per una singola TreeViewer (SWT.VIRTUAL)? Per quanto comprendo guardando esempi e API, è possibile utilizzare solo uno in un dato momento ma non entrambi in congiunzione, ad es. , preleva SOLO i figli visibili per un determinato nodo E li preleva in un thread separato utilizzando l'API di lavoro. Ciò che mi infastidisce è che l'approccio differito carica TUTTI i bambini. Sebbene in un thread diverso, si caricano comunque tutti gli elementi anche se solo un sottoinsieme minimo viene visualizzato contemporaneamente.

posso fornire esempi di codice alle mie domande, se necessario ...

Attualmente sto lottando con quelli me quindi se riesco a trovare qualcosa nel frattempo sarò felice di condividerle qui.

Grazie!

saluti, Svilen

Answer 1

trovo il framework Eclipse volte schizofrenico. Sospetto che lo DeferredTreeContentManager relativo allo ILazyTreeContentProvider sia uno di questi casi.

In un altro esempio, in EclipseCon lo scorso anno hanno raccomandato l'utilizzo di adattatori (IAdapterFactory) per adattare i modelli al contesto di binding necessario al momento. Ad esempio, se vuoi che il tuo modello si mostri in un albero, fallo in questo modo.

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 l'adattatore e il BaseWorkbenchContentProvider troverà l'adattamento in fabbrica. Meraviglioso. Suona come un piano.

"Oh by-the-way, quando si dispone di dati di grandi dimensioni, si prega di farlo in questo modo", dicono:

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

Si scopre che prima e la seconda esempi non solo sono incompatibili, ma si escludono a vicenda. Questi due approcci, probabilmente implementati da team diversi che non avevano un piano comune o forse l'API, sono nel bel mezzo di una transizione verso un framework comune. Tuttavia sei da solo.