Faul und latente TreeViewer Fragen

Question

Ich habe eigentlich zwei Fragen, aber sie sind so eine Art so hier gehen sie wie ein ...

Wie, um sicherzustellen, Garbage Collection von Baumknoten, die derzeit nicht TreeViewer angezeigt bezogen (SWT.VIRTUAL) unter Verwendung von und ILazeTreeContentProvider? Wenn ein Knoten 5000 Kinder hat, werden diese, sobald sie vom Viewer angezeigt werden, nie wieder losgelassen. daher Out of Memory Error, wenn Ihr Baum eine große Anzahl von Knoten und Blättern und nicht genügend Heap-Größe hat. Gibt es eine Art von Best Practice, wie Speicherleckagen vermieden werden können, die durch nie geschlossene Ansichten verursacht werden, die einen Treeviewer mit großen Datenmengen (Hunderttausende von Objekten oder sogar Millionen) enthalten? Vielleicht gibt es vielleicht eine Callback-Schnittstelle, die eine größere Flexibilität mit Viewer/Content-Provider-Elementen ermöglicht?

Ist es möglich, DEFFERED zu kombinieren (DeferredTreeContentManager) und faul (ILazyTreeContentProvider) Laden für einen einzelnen TreeViewer (SWT.VIRTUAL)? So viel ich verstehe, indem ich Beispiele und APIs betrachte, ist es nur möglich, entweder einen zu einer gegebenen Zeit, aber nicht beide gleichzeitig zu verwenden, z. , rufen Sie NUR die sichtbaren untergeordneten Elemente für einen bestimmten Knoten ab und holen Sie sie mithilfe der Job-API in einem separaten Thread. Was mich stört ist, dass der aufgeschobene Ansatz ALLE Kinder lädt. In einem anderen Thread laden Sie zwar alle Elemente , obwohl nur eine minimale Teilmenge gleichzeitig angezeigt wird.

Ich kann Code-Beispiele auf meine Fragen geben, wenn erforderlich ...

ich zur Zeit mit denen selbst bin zu kämpfen, so, wenn ich mit etwas in der Zwischenzeit kommen verwalten werde ich es gerne hier teilen.

Danke!

Grüße, Svilen

Answer 1

Ich finde das Eclipse-Framework manchmal schizophren. Ich vermute, dass die DeferredTreeContentManager, wie sie sich auf die ILazyTreeContentProvider bezieht, einer dieser Fälle ist.

In einem anderen Beispiel empfahlen sie auf der EclipseCon im vergangenen Jahr, dass Sie Adapterfabriken (IAdapterFactory) verwenden, um Ihre Modelle an den zu diesem Zeitpunkt erforderlichen Bindungskontext anzupassen. Wenn Sie beispielsweise möchten, dass Ihr Modell in einem Baum angezeigt wird, tun Sie dies auf diese Weise.

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

Registrieren Sie Ihren Adapter und der BaseWorkbenchContentProvider findet die Anpassung im Werk. Wunderbar. Klingt wie ein Plan.

„Oh by-the-Art und Weise, wenn Sie große Datenmengen haben, bitte tun, um diese Art und Weise“, sagen sie:

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

Es stellt sich heraus, dass erste und zweite Beispiele nicht nur unvereinbar sind, aber sie schließen sich gegenseitig aus. Diese beiden Ansätze wurden wahrscheinlich von verschiedenen Teams implementiert, die keinen gemeinsamen Plan hatten, oder die API befindet sich in der Mitte eines Übergangs zu einem gemeinsamen Framework. Trotzdem bist du alleine.