domande TreeViewer pigro e differite

Question

Non ho in realtà due domande ma sono specie di parente ecco vanno come uno ...

Come garantire la raccolta dei rifiuti di nodi dell'albero che non vengono visualizzati attualmente in uso TreeViewer (SWT.VIRTUAL) e ILazeTreeContentProvider? Se un nodo dispone di 5000 bambini, una volta che essi vengono visualizzati dallo spettatore non sono mai lasciato andare, qui, di errore di memoria se il vostro albero ha un grande numero di nodi e foglie e dimensione heap non abbastanza grande. C'è una sorta di best practice come evitare perdite di memoria, causate da vista mai chiuso in possesso di un treeviewer con grandi quantità di dati (centinaia di migliaia di oggetti o addirittura milioni)? Forse forse c'è qualche interfaccia di callback che consentono una maggiore flessibilità con elementi fornitore di spettatore / contenuti?

E 'possibile combinare deffered (DeferredTreeContentManager) E (ILazyTreeContentProvider) pigro carico per una singola TreeViewer (SWT.VIRTUAL)? Per quanto comprendo cercando in esempi e API, è possibile utilizzare solo uno dei due in un dato momento, ma non entrambi in combinazione, per esempio , recuperare solo i bambini visibili per un dato nodo a prenderli in un thread separato utilizzando API lavoro. Quello che mi preoccupa è che l'approccio differita Carica tutti i bambini. Anche se in un thread diverso, si è comunque caricare tutti gli elementi anche se solo un sottoinsieme minimo vengono visualizzati in una sola volta.

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

Al momento 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. Ho il sospetto che il DeferredTreeContentManager in quanto si riferisce alla ILazyTreeContentProvider è uno di questi casi.

In un altro esempio, a EclipseCon l'anno scorso hanno consigliato di utilizzare le fabbriche adattatore (IAdapterFactory) per adattare i modelli al contesto vincolante necessario in quel momento. Ad esempio, se si desidera che il modello di presentarsi in un albero, fare 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());

Pubblica il tuo 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 sono mutuamente esclusive. Questi due approcci dove probabilmente implementati da diverse squadre che non hanno un piano comune o forse l'API è nel bel mezzo di una transizione verso un quadro comune. Tuttavia si è da soli.