Monitor de cambios en una colección

Question

Digamos que tiene la siguiente Java Bean:

public class MyBean 
{ 
    private List<String> names = new ArrayList<String>(); 

    public void addName(String name) 
    { 
     names.add(name); 
     fireNamesPropertyChange(name); 
    } 
} 

¿Cómo se implementará normalmente un evento de cambio de propiedad de una colección? ¿Intenta utilizar la propiedad de índice que parece ser más para matrices que para colecciones?

Answer 1

Eche un vistazo a la biblioteca Glazed Lists, que tiene soporte para colecciones observables.

Si tuviera que hacerlo yo mismo, yo probablemente crearía interfaz de escucha personalizado con elementsAdded, métodos elementsRemoved, o similares :-) (también en función de mis necesidades)

Answer 2

Para un evento de GUI de oscilación normalmente solo usaría un EventListenerList para hacer el trabajo por mí.

EDITAR: sobre la reformulación de las preguntas: cómo se tratan las colecciones, normalmente usaría un evento similar al tipo de colecciones, por ejemplo, un evento TreeModel suele tener un argumento TreePath o algo en un mapa Yo indicaría la clave.

Sin embargo, para los JavaBeans simples, el más común es asumir una lista/matriz y simplemente usar el índice.

Answer 3

Me parece que necesitará fireNamesPropertyAdd, fireNamesProperyDelete. Una notificación de nivel de lista no funcionará en mi humilde opinión, incluso si se tratara de una matriz y se agregó un índice, ya que no puede gestionar las eliminaciones. Si se puede cambiar el elemento en algún índice, también necesitará fireNamesProperyChange. Puede ser útil tener un índice como parámetro además del valor de la cadena.

Answer 4

(NOTA: He actualizado este post tras darse cuenta de algunos errores de mi propia por lo que este no es el original, pero una vez más refinado)

Para ello me gustaría hacer dos nuevos interfaces, ListListener y Listenable y luego crearía una nueva clase como ListenableArrayList que envolvería cada método List con una llamada a uno (o más) métodos relevantes definidos en ListListener. En el código sería algo como esto:

public class ListenableArrayList<T> extends ArrayList<T> 
            implements Listenable<T> { 

    private ArrayList<T> internalList; 
    private ListListener<T> listener; 

    /* .. */ 

    public void add(T item) { 
     listener.beforeAdd(T item); 
     internalList.add(item); 
     listener.afterAdd(T item); 
    } 

    /* .. */ 

    public void setListener(ListListener<T> listener) { 
     this.listener = listener; 
    } 

} 

public interface ListListener<T> { 
    /* .. */ 
    void beforeAdd(T item); 
    void afterAdd(T item); 
    /* .. */ 
} 

public interface Listenable<T> { 
    /* .. */ 
    void setListener(ListListener<T> listener); 
    /* .. */ 
} 

La razón por la que lo haría de esta manera sería la de permitir la creación de oyentes verdaderamente ad-hoc sobre la marcha en lugar de atar el ListenableArrayList a alguna aplicación específica. Por ejemplo, con esto, el siguiente sería posible:

Listenable<String> list = new ListenableArrayList<String>(); 

list.setListener(new ListListener<String>() { 
    @Override 
    public void beforeAdd(String item) { 
     System.out.println("About to add element "+item+"..."); 
    } 
    @Override 
    public void afterAdd(String item) { 
     System.out.println("...element "+item+" has been added."); 
    } 
}); 

Un poco desordenado, tal vez, pero por otro lado esto permitiría una fácil extensión a las colecciones, conjuntos y otras cosas con bastante facilidad.

Answer 5

¿Está quizá buscando java.beans.PropertyChangeSupport?

En mi opinión, debe evitar PropertyChangeEvent. IndexedPropertyChangeEvent es peor, y muy poco utilizado por Swing de todos modos. Es mejor restringir el enfoque de sus tipos, y disparar un javax.swing.event.ChangeEvent o similar (incluso simplemente llame a Runnable).

Para ciertos tipos (como las listas!), Las listas esmaltadas (o equivalentes) mencionadas en otra publicación de Peter Štibraný parecen una buena forma de hacerlo.

Answer 6

Puede utilizar una colección observable: https://commons.apache.org/dormant/events/apidocs/org/apache/commons/events/observable/ObservableCollection.html

Answer 7

Normalmente yo haría lo siguiente:

public class MyBean { 
    private PropertyChangeSupport pcs = new PropertyChangeSupport(this); 
    private List<String> names = new ArrayList<String>(); 
    public void addName(String name) { 
     names.add(name); 
     pcs.firePropertyChange("names", null, Collections.unmodifiableList(names)); 
    } 
    public void addPropertyChangeListener(PropertyChangeListener l) { 
     pcs.addPropertyChangeListener(l); 
    } 
    public void removePropertyChangeListener(PropertyChangeListener l) { 
     pcs.removePropertyChangeListener(l); 
    } 
} 

PropertyChangeSupport gestiona los oyentes y los incendios de los acontecimientos en su nombre.

Al pasar nulo como el "valor anterior" fuerza el evento a ser disparado. (Es probable que los oyentes no serán realmente se preocupan por el valor antiguo de todos modos)

Answer 8

JDK 7+ solución:

import javafx.collections.*; 
import java.util.*; 

public class Test { 
    public static void main(String[] args) { 
     List<String> list = new ArrayList<>(); 

     list.add("s1"); 
     list.add("s2"); 

     ObservableList<String> observableList = FXCollections.observableList(list); 
     observableList.addListener(new ListChangeListener<String>() { 
      @Override 
      public void onChanged(Change<? extends String> change) { 
       while(change.next()){ 
        System.out.println("added: " + change.getAddedSubList()); 
       } 
      } 
     }); 

     observableList.add("s3"); 
    } 
}