Perguntas preguiçosas e diferidas da TreeViewer

Question

Na verdade, eu tenho duas perguntas, mas elas estão meio relacionadas, então aqui estão eles como um ...

Como garantir a coleta de lixo de nós de árvores que não são exibidos atualmente usando TreeViewer(SWT.VIRTUAL) e ILazeTreeContentProvider? Se um nó tiver 5000 crianças, uma vez exibidas pelo espectador, eles nunca serão liberados, portanto, fora do erro de memória, se sua árvore tiver um grande número de nós e folhas e não grande o suficiente. Existe algum tipo de prática recomendada como evitar vazamentos de memória, causada por uma visão nunca fechada, segurando um visualizador de árvores com grandes quantidades de dados (centenas de milhares de objetos ou até milhões)? Talvez haja alguma interface de retorno de chamada que permita maior flexibilidade com os elementos do visualizador/provedor de conteúdo?

É possível combinar desviado (DeferredTreeContentManager) E preguiçoso (ILazyTreeContentProvider) Carregando para um único TreeViewer(SWT.VIRTUAL)? Por mais que eu entenda, olhando para exemplos e APIs, só é possível usar qualquer um em um determinado momento, mas não ambos em conjunto, por exemplo, buscar apenas as crianças visíveis para um determinado nó e buscá -las em um tópico separado usando trabalho API. O que me incomoda é que a abordagem diferida carrega todas as crianças. Embora em um encadeamento diferente, você ainda carrega todos os elementos, embora apenas um subconjunto mínimo seja exibido de uma só vez.

Posso fornecer exemplos de código para minhas perguntas, se necessário ...

Atualmente, estou lutando com aqueles que eu mesmo, se eu conseguir inventar algo enquanto isso vou compartilhá -lo aqui.

Obrigado!

Atenciosamente, Svilen

Answer 1

Acho que a estrutura do eclipse às vezes esquizofrênica. Eu suspeito que o DeferredTreeContentManager no que se refere ao ILazyTreeContentProvider é um desses casos.

Em outro exemplo, no Eclipsecon, no ano passado, eles recomendaram que você usasse fábricas adaptadoras (IAdapterFactory) para adaptar seus modelos ao contexto de ligação necessário na época. Por exemplo, se você deseja que seu modelo apareça em uma árvore, faça dessa maneira.

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 seu adaptador e o BaseWorkbenchContentProvider encontrarão a adaptação na fábrica. Maravilhoso. Soa como um plano.

"Oh, a partir do caminho, quando você tem grandes conjuntos de dados, faça dessa maneira", eles dizem:

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

Acontece que o primeiro e o segundo exemplos não são apenas incompatíveis, mas são mutuamente exclusivos. Essas duas abordagens, onde provavelmente implementadas por diferentes equipes que não tinham um plano comum ou talvez a API esteja no meio de uma transição para uma estrutura comum. No entanto, você está sozinho.