¿Por qué los botones tienen oyentes de acción y los comandos no lo hacen en LWUIT?

Question

¿Hay alguna razón por la cual en LWUIT un botón puede tener su propio ActionListener (a través de button.addActionListener) mientras que un comando no lo tiene?

¿La única forma de tener un escucha para un comando específico es agregar un ActionListener a un formulario y verificar el oyente para el comando del que proviene el evento como a continuación?

public void startApp() { 
    Display.init(this); 
    f = new Form("Mixed Record"); 
    exit = new Command("Exit"); 
    start = new Command("Start"); 
    Button button = new Button("Button"); 

    f.addCommand(exit); 
    f.addCommand(start); 
    f.addCommand(delete); 
    f.addComponent(button); 

    f.addCommandListener(new ActionListener() { 

     public void actionPerformed(ActionEvent ae) { 
      if (ae.getCommand().equals(exit)) { 
       //Do Exit command code 
      } else if (ae.getCommand().equals(start)) { 
       //Do Start command code 
      } 
     } 
    }); 

    button.addActionListener(new ActionListener() { 

     public void actionPerformed(ActionEvent ae) { 
      //Do button code 
     } 
    }); 

    f.show(); 
} 

Answer 1

Bueno, no puedo decir exactamente por qué las personas que escribieron LWUIT tomaron esa decisión, pero hay varias razones por las que tiene sentido.

Cuando un formulario contiene varios comandos, se agrupan en un menú. Cada vez que el usuario se expande, colapsa el menú, se ejecuta un máximo de un comando. Como tal, los Comandos están conceptualmente más vinculados entre sí que los Botones, especialmente porque no es raro reutilizar las subclases de Botón de un Formulario a otro.

También podría haber una preocupación sobre hacer que la API del Formulario LWUIT se parezca mucho al Formulario LCDUI en la especificación MIDP.

También me gusta que el código muestra una consecuencia positiva de la decisión:

Ya tiene 2 clases internas no identificadas (las subclases ActionListener) en el código. Si cada comando tuviera su propio ActionListener, probablemente habría escrito 3 clases internas sin nombre. Los desarrolladores tienden a hacer eso mucho aunque, cuando haya dedicado más tiempo a buscar trazas de código que contengan varias clases internas sin nombre, se dará cuenta de que es una mala práctica tener más de uno en cada clase.