gvSIG blog

En el articulo anterior “Hilos y gvSIG: Estructura de nuestro proceso (3 de 4)” vimos cómo podíamos estructurar la lógica de nuestro proceso. En este ultimo articulo vamos a ver cómo podríamos hacer para interactuar con la interface gráfica desde él.

Cuando estamos trabajando en java con swing y múltiples hilos de ejecución tenemos que tener algo de cuidado al interactuar con el interface de usuario. En una aplicación swing el acceso a los elementos gráficos debe realizarse desde el hilo que controla el manejador de eventos de swing. Si desde otro hilo intentamos acceder a los elementos graficos podemos tener resultados inesperados. La librería de swing aporta varias funciones de utilidad para poder sincronizar nuestras operaciones con las que swing hace en su hilo de ejecución. Nos vamos a quedar con tres de ellas:

• SwingUtilities.isEventDispatchThread, que nos dice si ya estamos ejecutándonos en el hilo de swing
• SwingUtilities.invokeLater(Runnable action) que se encarga de encolar la ejecución de “action” en el hilo de swing para que se ejecute cuando este pueda.
• SwingUtilities.invokeAndWait(Runnable action) que se encarga de encolar la petición en el hilo de swing y esperar a que esta se ejecute.

Usando estos tres métodos podemos asegurarnos que las partes de código que tienen que ver con el GUI se ejecuten en el hilo del manejador de eventos de swing.

Por ejemplo, si quisiésemos mostrar un cuadro de diálogo del estilo de showMessageDialog podríamos hacer algo como:

if (!SwingUtilities.isEventDispatchThread()) {
  try {

    SwingUtilities.invokeAndWait(new Runnable() {
      public void run() {

        JOptionPane.showMessageDialog(null, "Éste sería el mensaje a mostrar");
      }
    });

  } catch (InterruptedException e) {
    logger.info("Can't show message dialog ", e);

  } catch (InvocationTargetException e) {
    logger.info("Can't show message dialog ", e);

  }
} else {
  JOptionPane.showMessageDialog(null, "Éste sería el mensaje a mostrar");

}

Aunque de esta manera podemos asegurarnos que nuestros mensajes se presentan al usuario de forma correcta aunque estemos en un hilo distinto al del manejador de eventos de swing, suele resultar bastante engorroso, por eso disponemos de algúnas funciones en gvSIG para acceder a algunos de los diálogos standard. Los siguientes métodos de gvSIG nos permiten presentar algunos de los cuadros de diálogo de la clase JOptionPane sin preocuparnos de esto:

• ApplicationManager.messageDialog nos muestra un mensaje similar a JOptionPane.showMessageDialog
• ApplicationManager.confirmDialog nos muestra un mensaje similar a JOptionPane.showConfirmDialog
• ApplicationManager.inputDialog nos muestra un mensaje similar a JOptionPane.showInputDialog

Además de estos métodos disponemos de un método ApplicationManager.message que nos permitirá presentar un mensaje en la barra de estado de gvSIG, y que también realiza las comprobaciones adecuadas para asegurarse que funciona aunque no estemos en el hilo de swing.

Con estos cuatro métodos junto con el mecanismo del TaskStatus podemos dotar a nuestros procesos de algo de interacción con el usuario sin necesidad de encargarnos nosotros mismos de sincronizarnos con el hilo de swing. Si precisamos una interacción más rica, por ejemplo presentar nuestros propios cuadros de diálogo desde nuestro hilo de ejecución, disponemos de dos métodos más en el ApplicationManager:

• createComponent, que pasándole la clase que implementa un componente de AWT se encarga de crearlo en el hilo de swing.
• Y showDialog(final Component contents, final String title), que recibe nuestro JPanel, normalmente instanciado con createComponent y se encarga de mostrarlo a modo de diálogo modal respecto a nuestro hilo.

Y por último comentar que se está realizando un esfuerzo para que la gran mayoría de los métodos del API de andami y el plugin de gvSIG se comporten de forma segura respecto a su ejecución desde otros hilos distintos al del controlador de eventos de swing.

Bueno… con estas utilidades en nuestra caja de herramientas volvamos a nuestra clase MyProcess. En el articulo anterior habíamos visto cómo podría ser la estructura de nuestra clase que implementase nuestro proceso. Habíamos visto también ya que en algún momento se presentaba un cuadro de diálogo al usuario para informar de algún error, pero no nos habíamos centrado en ello.

Así por ejemplo, al final de nuestro bucle en el método run teníamos algo como:

...
  this.postPrecess();
  if (status.isCancellationRequested()) {

    status.cancel();
    return;
  }
  application.message("Process terminated", JOptionPane.INFORMATION_MESSAGE);

} catch (Exception e) {
  logger.info("Error in process", e);

  if (status != null) {
    status.abort();

  }
  application.message("Process error", JOptionPane.WARNING_MESSAGE);
  application.messageDialog(

          "Se ha producido un error realizando el proceso y éste terminará de forma inesperada.\n\n"
              + e.getMessage(), this.getName(),
          JOptionPane.WARNING_MESSAGE);

} finally {

...

En donde podemos ver cómo se invoca a un par de métodos que interactúan con el usuario. Por un lado tenemos la llamada:

application.message("Process terminated", JOptionPane.INFORMATION_MESSAGE);

Que se encarga de mostrar en la barra de estado de gvSIG un mensaje informándonos que ha terminado la ejecución de nuestro proceso. Nótese que como estamos usando el método message del ApplicationManager no es preciso sincronizar su ejecución con el hilo de swing, como hemos comentado antes.

Y un poco más abajo, cuando se atrapan los errores, se muestra un diálogo al usuario informando de ello:

application.messageDialog(
        "Se ha producido un error realizando el proceso y éste terminará de forma inesperada.\n\n"

            + e.getMessage(), this.getName(),
        JOptionPane.WARNING_MESSAGE);

Con todo esto, vamos a ver qué podía hacer nuestro proceso, más para ilustrar el uso de estas funciones que para hacer algo real. Así nuestro proceso se limitará ha hacer un sleep a cada iteración, y además:

1. Cuando lleve recorridos el 10% de los elementos presentará un mensaje de tipo informativo en la barra de estado informando de ello, además de mostrarlo en el indicador de progreso usando el taskstatus:

   status.message("10%");
   
   application.message("this is the row " + i,
       JOptionPane.INFORMATION_MESSAGE);

2. Cuando lleve recorridos el 20% de los elementos presentará un mensaje de tipo advertencia en la barra de estado informando de ello, además de mostrarlo en el indicador de progreso usando el taskstatus:

   status.message("20%");
   application.message("this is the row " + i,
   
       JOptionPane.WARNING_MESSAGE);

3. Cuando lleve recorridos el 30% de los elementos presentara un mensaje de tipo error en la barra de estado informando de ello, además de mostrarlo en el indicador de progreso usando el taskstatus:

   status.message("30%");
   
   application.message("this is the row " + i,
       JOptionPane.ERROR_MESSAGE);

4. Cuando lleve el 40% presentara un mensaje del tipo ShowMessageDialoginformando de ello:

   status.message("40%");
   application.messageDialog("Just procesing "+i+" items",
   
       this.getName(), JOptionPane.INFORMATION_MESSAGE);

   Aquí el proceso se interrumpirá hasta que el usuario pulse en el botón aceptar, tras lo cual continuara con su ejecución.

5. Cuando lleve el 50% informará de ello al usuario, y preguntará si éste desea interrumpir nuestro proceso:

   status.message("50%");
   int confirm = application
       .confirmDialog("Quiere cancelar el procesp?",
   
           this.getName(), JOptionPane.YES_NO_OPTION,
           JOptionPane.QUESTION_MESSAGE);
   
   if (confirm == JOptionPane.YES_OPTION) {
     status.cancelRequest();
   
   }

   En caso de que el usuario responda que si quiere cancelar la ejecución, llamamos al método cancelRequest y ya lo procesaremos a la siguiente entrada en nuestro bucle.

6. Por ultimo, cuando el proceso lleve el 60%, pediremos al usuario que entre una cadena, que luego mostraremos en la barra de estado:

   status.message("60%");
   
   String value = application.inputDialog("Introduce un valor",this.getName());
   if (value != null) {
   
     application.message("Entered: " + value,
         JOptionPane.INFORMATION_MESSAGE);
   
   } else {
     application.message("Input cancelled",
         JOptionPane.INFORMATION_MESSAGE);
   
   }

Pongamos todo esto junto y veamos como nos quedaría nuestro método processItem:

private void processItem(int i) throws InterruptedException {

  ApplicationManager application = ApplicationLocator.getManager();
  SimpleTaskStatus status = (SimpleTaskStatus) this.getTaskStatus();

  switch ((100 * i) / this.maxValue) {

  case 10:
    status.message("10%");
    application.message("this is the row " + i,

        JOptionPane.INFORMATION_MESSAGE);
    break;
  case 20:
    status.message("20%");

    application.message("this is the row " + i,
        JOptionPane.WARNING_MESSAGE);

    break;
  case 30:
    status.message("30%");

    application.message("this is the row " + i,
        JOptionPane.ERROR_MESSAGE);

    break;
  case 40:
    status.message("40%");

    application.messageDialog("Just procesing "+i+" items",
        this.getName(), JOptionPane.INFORMATION_MESSAGE);

    break;
  case 50:
    status.message("50%");

    int confirm = application
        .confirmDialog("Quiere cancelar el procesp?",
            this.getName(), JOptionPane.YES_NO_OPTION,

            JOptionPane.QUESTION_MESSAGE);
    if (confirm == JOptionPane.YES_OPTION) {

      status.cancelRequest();
    }
    break;
  case 60:

    status.message("60%");
    String value = application.inputDialog("Introduce un valor",this.getName());

    if (value != null) {
      application.message("Entered: " + value,

          JOptionPane.INFORMATION_MESSAGE);
    } else {
      application.message("Input cancelled",

          JOptionPane.INFORMATION_MESSAGE);
    }
    break;
  }
  Thread.sleep(this.sleepTime);

}

No se trata de un código real, solo sirve para ilustrar el uso de las funciones más simples a nuestra disposición para interactuar con el usuario. Soy consciente que el control de los porcentajes puede provocar que se muestre algún diálogo más de una vez, pero prefiero no complicar el control de eso y dejar el código de la forma más simple, ya que lo importante creo que es ilustrar cómo podemos invocar a nuestros diálogos de forma simple.

Veamos ahora como podríamos añadir a nuestro proceso algún cuadro de diálogo personalizado. Supongamos que al iniciar nuestro proceso deseamos presentar al usuario un cuadro de diálogo preguntando algunos datos, y por la razón que sea ya no nos encontramos en el hilo del controlador de eventos de swing. Supondremos que tenemos una clase MyDialog que implementa un panel de swing, JPanel, y queremos mostrarla y esperar a que el usuario introduzca algún dato para que pueda continuar nuestro proceso. Nuestro panel MyDialog, espera recibir en su constructor una instancia de MyProcess, para acceder a los parámetros que éste tiene y poder mostrarlos al usuario y luego recuperarlos.

Lo primero que haremos sera añadir a nuestro MyProcess unos setters y getters para acceder a las propiedades privadas que nos interese:

public int getMaxValue() {
  return maxValue;
}

public void setMaxValue(int maxValue) {
  this.maxValue = maxValue;

}
public long getSleepTime() {
  return sleepTime;

}
public void setSleepTime(long sleepTime) {
  this.sleepTime = sleepTime;

}

Luego para mostrar nuestro diálogo, primero crearemos nuestro panel:

Component panel = application.createComponent(MyDialog.class, this);

Notar que no hemos creado el panel directamente invocando a:

Component panel = new MyDialog(this);

Ya que es podría provocar algún efecto extraño al no estar en el hilo de swing. LLamando a createComponent nos aseguramos que la creación de nuestro componente se hará en el hilo de swing, y que nuestro hilo esperara a que éste sea creado y nos lo devolverá.

Y luego para mostrar un cuadro de diálogo con ese panel llamaremos a:

application.showDialog(panel, this.getName());

Que se encargará de presentar una ventana de gvSIG con el panel indicado, y con el título que le hayamos dicho, en este caso el nombre de nuestro hilo, y esperará a que ésta sea cerrada para devolver el control a nuestro hilo.

Todo esto junto en el método preProcess quedaría:

private void preProcess() {
  SimpleTaskStatus status = (SimpleTaskStatus) this.getTaskStatus();

  status.setTitle("Getting parameters");
  Component panel = application.createComponent(MyDialog.class, this);

  application.showDialog(panel, this.getName());
}

En cuanto al método postProcess que hemos comentado en el articulo anterior, en nuestro caso quedaría vacío:

private void postPrecess() {
  // In this example do nothing
}

Con esto más o menos quedan cubiertas las principales acciones que podemos querer hacer desde nuestro hilo y qué funciones aporta gvSIG para ayudarnos en ello.

Respecto a nuestra clase MyDialog podría ser algo como:

public class MyDialog extends MyDialogLayout {
  private static final long serialVersionUID = 1919826881234125305L;

  private MyProcess process = null;

  public MyDialog(MyProcess process) {

    super();
    this.process = process;
    this.inputSleepTime.setValue(this.process.getSleepTime());

    this.inputMaxIterations.setValue(this.process.getMaxValue());
    this.buttonAcept.addActionListener(new ActionListener() {

      public void actionPerformed(ActionEvent arg0) {
        doAcept();
      }

    });
    this.buttonCancel.addActionListener(new ActionListener() {

      public void actionPerformed(ActionEvent arg0) {
        doCancel();
      }

    });
  }
  private void doAcept() {
    this.process.setSleepTime(((SpinnerNumberModel) inputSleepTime.getModel()).getNumber().intValue());

    this.process.setMaxValue(((SpinnerNumberModel) inputMaxIterations.getModel()).getNumber().intValue());

    this.closeWindow();
  }
  private void doCancel() {

    this.process.cancelRequest();
    this.closeWindow();
  }

  private void closeWindow() {
    this.setVisible(false);

  }
}

Lo más importante es el método closeWindow. El método showDialog del ApplicationManager espera a que el componente pasado sea ocultado para interpretar que se quiere cerrar la ventana, así que desde nuestro panel, lo único que hacemos es poner visible a false para indicar que queremos cerrar la ventana. Al respecto de MyDialog comentar que suelo separar la creación del GUI de la lógica de éste, así que la clase MyDialog extiende a MyDialogLayout que contiene la creación y posicionamiento de todo los controles, que son usados desde MyDialog. No creo que tenga gran misterio la creación y posicionamiento de los controles, así que no la voy a incluir en este articulo.

Como nota final, me gustaría hacer hincapié en un idea. Aunque aquí haya comentado cómo podemos hacer para desde nuestro proceso interactuar con el usuario, es una mala política hacerlo. No recomiendo hacerlo más allá de interactuar con el componente TaskStatus para ir informando del progreso de nuestro proceso. Solo en caso de que sea necesario hacerlo deberíamos interactuar con el GUI desde un proceso que se espera que esté haciendo algún tipo de tarea en segundo plano.

Espero que haya servido para ilustrar cómo estructurar este tipo de tareas en gvSIG, y qué recursos tenemos a nuestro alcance para facilitarnos hacerlas.

Un saludo

Joaquin

En el articulo anterior, “Hilos y gvSIG (2 de 4): TaskStatus“, vimos las funcionalidades relacionadas con la utilidad TaskStatus, ahora vamos a ver cómo podríamos hacer para crear un proceso y ejecutarlo como un hilo de ejecución independiente de gvSIG que nos permita dejar al usuario seguir interactuando con el resto de la aplicación mientras éste se esta ejecutando. Para eso crearemos dos clases, MyExtension, que será una extensión de gvSIG encargada de lanzar el proceso y MyProcess, que estará implementado mediante un hilo de java.

En lo que respecta a nuestra extensión tendremos que tener encuenta algunas cosas:

• Cada vez que el usuario lo solicite lanzará la ejecución de nuestro proceso en un hilo aparte.
• Si se intenta ejecutar y el proceso ya está en ejecución presentará un mensaje al usuario indicando que en estos momentos ya está en ejecución nuestro proceso indicando que no podrá ejecutarlo hasta que éste termine.
• La herramienta estará visible siempre, pero solo estará activa si no está nuestro proceso en ejecución.

Para esto nuestra extensión guardará una referencia a nuestro proceso, y en el método isEnabled comprobará si tenemos una instancia de nuestro proceso y si esta está viva a través del método isAlive de la clase Thread. Así mismo, en el execute se realizará una comprobación similar antes de lanzar la ejecución del proceso.

Veamos cómo seria el código de nuestra extensión:

public class MyExtension extends Extension {

  @SuppressWarnings("unused")
  private static Logger logger = LoggerFactory.getLogger(MyExtension.class);

  private MyProcess process = null;

  public void initialize() {

    // Do nothing
  }
  public void execute(String actionCommand) {

    if ("tools-devel-my-process".equalsIgnoreCase(actionCommand)) {
      if (process != null && process.isAlive()) {

        ApplicationManager application = ApplicationLocator.getManager();
        application.messageDialog(
            "Process already running. Wait to terminate.",

            "Test task", JOptionPane.WARNING_MESSAGE);
        return;
      }
      process = new MyProcess();

      process.start();
    }
  }
  public boolean isEnabled() {

    if (process != null && process.isAlive()) { 
      return false;

    }
    return true;
  }
  public boolean isVisible() {

    return true;
  }
}

Una vez ya tenemos preparada nuestra extensión veamos qué tendríamos en nuestra clase MyProcess. De forma general, asumiremos que nuestro proceso tendrá una serie de tareas previas, un bloque de tareas constituido por un bucle en el que a cada pasada se van ejecutando nuestro proceso y una serie de tareas a ejecutar a la finalización de éste. Así mismo, para el caso de ejemplo, voy a suponer que sé el número de iteraciones que va a hacer el proceso, lo que me permitirá informar a través del TaskStatus del avance del proceso. Tendremos definidos los siguientes métodos:

• run, se tratará del hilo principal de ejecución. Contendrá el código principal de nuestro proceso haciendo las veces de main de éste.
• preProcess, el método en el que englobaremos las tareas previas al bloque principales de nuestro proceso.
• processItem, que será el encargado de procesar cada uno de los ítems de nuestro proceso.
• postProcess, que realizará las tareas de finalización de nuestro proceso.

Los pasos a hacer en el método run serian:

1. realización de la tareas previas:

   this.preProcess();

2. Comprobar si se ha solicitado la cancelación del proceso:

   if (status.isCancellationRequested()) {
     status.cancel();
     return;
   
   }

3. inicializar el status con el número de iteraciones que va a tener nuestro proceso:

   status.setRangeOfValues(1, this.maxValue);

4. Iterar, comprobando al comienzo de cada iteración si se ha solicitado la cancelación
   del proceso y estableciendo el estado de progreso:

   for (int i = 1; i < this.maxValue; i++) {
   
     // Si ha sido solicitada la cancelacion de la tarea
     // la marcamos como cancelada y salimos del proceso.
     if (status.isCancellationRequested()) {
   
       status.cancel();
       return;
     }
     // Informamos del progreso de la tarea
     status.setCurValue(i);

   A cada iteración realizaremos las tareas propias de nuestro proceso:

   this.processItem(i);

5. Realizar las tareas de post-proceso:

   this.postPrecess();

6. Comprobar si se ha solicitado la cancelación durante la ejecución de las tareas
   de post-proceso:

   if (status.isCancellationRequested()) {
     status.cancel();
   
     return;
   }

7. A la terminación de nuestro proceso marcar el status como terminado.
   Normalmente esto lo haremos en la instrucción finally, para asegurarnos
   que a la salida de nuestro proceso siempre se actualiza el estado de
   éste:

   } finally {
   
     if (status != null) {
       // Mark process as terminate if it is running.
       if (status.isRunning()) {
   
         status.terminate();
       }
     }
   }

Es importante tener en cuenta algunas consideraciones:

• Deberemos consultar si se ha pedido la cancelación de nuestro proceso, a cada iteración de éste, o si se trata de un proceso muy pesado, con un alto número de iteraciones, cada cierto número de éstas que sea razonable en tiempo de usuario.
• Deberemos atrapar los errores de forma adecuada. Hay que tener en cuenta que si éstos se producen no se propagarán hasta el interface de usuario de la aplicación, y el usuario puede no enterarse de problemas durante la ejecución de nuestro proceso.
• Deberemos marcar nuestro proceso como terminado a su finalización, lo que normalmente haremos con la clausula finally–
• No podremos interactuar con el interface de usuario directamente. Swing no está preparado para trabajar en multihilo, así que solo podremos hacerlo a través de métodos que estén preparados para ello o utilizando los métodos invokeLater e invokeAndWait de la clase SwingUtilities de swing tal como vimos en el ejemplo de la clase MyObserver.

Con todas estas consideraciones en mente veamos como podría quedar nuestra clase MyProcess :

public class MyProcess  extends AbstractMonitorableTask {

  private static Logger logger = LoggerFactory.getLogger(MyProcess.class);

  private ApplicationManager application = null;
  private int maxValue = 100;

  private long sleepTime = 100;

  protected MyProcess() {

    super("MyProcess");
    this.application = ApplicationLocator.getManager();

  }
  public void run() {
    SimpleTaskStatus status = null;

    try {
      status = (SimpleTaskStatus) this.getTaskStatus();

      this.preProcess();
      if (status.isCancellationRequested()) {

        status.cancel();
        return;
      }
      status.setRangeOfValues(1, this.maxValue);

      for (int i = 1; i < this.maxValue; i++) {

        // Si ha sido solicitada la cancelacion de la tarea
        // la marcamos como cancelada y salimos del proceso.
        if (status.isCancellationRequested()) {

          status.cancel();
          return;
        }
        // Informamos del progreso de la tarea
        status.setCurValue(i);

        this.processItem(i);
      }
      this.postPrecess();

      if (status.isCancellationRequested()) {
        status.cancel();

        return;
      }
      application.message("Process terminated", JOptionPane.INFORMATION_MESSAGE);

    } catch (Exception e) {
      logger.info("Error in process", e);

      if (status != null) {
        status.abort();

      }
      application.message("Process error", JOptionPane.WARNING_MESSAGE);
      application.messageDialog(

              "Se ha producido un error realizando el proceso y este terminara de forma inesperada.\n\n"
                  + e.getMessage(), this.getName(),
              JOptionPane.WARNING_MESSAGE);

    } finally {
      if (status != null) {

        // Mark process as terminate if it is running.
        if (status.isRunning()) {
          status.terminate();

        }
      }
    }
  }
  private void preProcess() {

    ...
  }
  private void processItem(int i) throws InterruptedException {

    ...
  }
  private void postPrecess() {
    ...

  }
}

Tal como se han descrito las clases MyExtension y MyProcess, éstas podrían quedar como un esquema general a la hora de implementar procesos en gvSIG. Las adaptaríamos a nuestras necesidades y las podríamos utilizar de cara a construir nuestros procesos de forma que no fuesen bloqueantes respecto al interface de gvSIG.

En el próximo articulo, “Hilos y gvSIG (4 de 4): Interactuando con el usuario“, vamos a seguir viendo cómo podemos abordar algunas cosas más relacionadas con el manejo de hilos, y veremos en un ejemplo sencillo qué podemos tener en los metodos preProcess y processItem, y cómo podríamos hacer para interactuar desde ellos con el interfaz de usuario en caso de que lo necesitásemos.

Un saludo

Joaquin

En el articulo anterior, “Hilos y gvSIG (1 de 4)“, vimos una introducción a lo que podían ser la herramientas que nos ofrece gvSIG para crear nuestros propios procesos sin que estos bloqueen la interface de usuario de gvSIG.
Vamos a continuar con ello viendo las utilidades relacionadas con el TaskStatus.

Para gestionar el estado y progreso de tareas o procesos en gvSIG disponemos del mecanismo de TaskStatus, que se encuentra implementado en la librería de org.gvsig.tools. Las principales entidades relacionadas con este mecanismo que nos encontraremos serán:

• TaskStatus. Que representa el estado en el que se encuentra un proceso o tarea. Tiene métodos para consultar el estado en que se encuentra la tarea, pero no para establecerlo. Este interface es el que deben usar los procesos que quieren consultar el estado de otros procesos.
• TaskStatusManager. Hace de factoría para la creación de TaskStatus, así como mantiene un registro de éstos para poder consultar el estado de las tareas que se encuentren en ejecución.
• SimpleTaskStatus. Extiende el interface TaskStatus con métodos que nos permiten actualizar el estado de la tarea. Es usado por la propia tarea o proceso para mantener actualizado la información de su estado.
• AbstractMonitorableTask. Se trata de una clase abstracta que extiende a la clase Thread, añadiéndole métodos para obtener el TaskStatus asociado a éste. Normalmente cuando creemos nuestros procesos extenderemos de esta clase en lugar de la clase Thread.

El TaskStatus, nos da información sobre el estado del proceso, nos informa de características del proceso como:

• Si se puede determinar la duración del proceso. Es decir si es posible calcular qué llevamos y cuánto falta (isIndeterminate).
• Si el proceso es cancelable o no (isCancelable).
• Un titulo identificativo del proceso (getTitle)

También nos permite consultar el progreso de nuestro proceso:

• Consultar el porcentaje de avance de éste (getCompleted)
• O una etiqueta que identifique qué esta haciendo en un momento dado (getLabel).

Nos permite solicitar la cancelación del proceso (cancelRequest). No nos permite cancelarlo, esto es algo que el propio proceso debe decidir, desde fuera lo único que podemos hacer es pedir que cancele su ejecución.

Y por último consultar su estado:

• isRunning, el proceso está en ejecución.
• isRequestCanceled, el proceso está en ejecución y se ha solicitado su cancelación.
• isAborted, el proceso ha abortado su ejecución, normalmente debido a algún error durante la ejecución de éste.
• isCancelled, el proceso se ha cancelado por petición externa a éste, normalmente por la intervención del usuario o de algún otro proceso invocando al método cancelRequest.

El TaskStatusManager, nos permite crear instancias de TaskStatus mediante el método createDefaultSimpleTaskStatus, y añadir, consultar, o eliminar un TaskStatus de la lista de status que mantiene.

Tanto el TaskStatus, como el TaskStatusManager son observables, y permiten registrar observadores para poder seguir el estado de una tarea. Así si quisiésemos presentar información de las tareas que hay en ejecución en un momento dado solo tendríamos que registrarnos como observadores del taskStatusManager. Si lo hiciésemos tendríamos que tener la precaución de asegurarnos en el método update de nuestro observador que estamos en el hilo de ejecución de swing antes de presentar la información en el interface gráfico. Podría ser algo como:

class MyObserver implements Observer {
  public void update(final Observable observable,final Object notification) {

    if (!SwingUtilities.isEventDispatchThread()) {
      SwingUtilities.invokeLater(new Runnable() {

        public void run() {
          update(observable,notification);

        }
      });
      return;
    }
    ...
    Procesar notificacion
    ...

  }
}

Si estamos observando al TaskStatusManager recibiremos como observable a éste y como notification el TaskStatus involucrado o null. Por ejemplo, añadir un taskstatus al manager o modificar un taskstatus registrado en el manager provocará que nos llegue como notification el taskstaus añadido o modificado y cuando se elimine uno nos llegara el que queremos eliminar o null.

El otro interface importante relacionado con TaskStatus es el SimpleTaskStatus. Se trata del interface que usará un proceso o tarea para mantener actualizado su estado. Añade los siguientes métodos al TaskStatus:

• add y remove, que provocaran que el TaskStatus se registre o elimine en el manager para poder estar en la lista de tareas disponibles de forma publica.
• setAutoremove y getAutoremove, que nos permitirán consultar y fijar la propiedad autoremove, que indica si el TaskStatus deberá ser eliminado del manager al terminar su ejecución de forma automática o no.
• setCancelable para indicar si nuestro proceso es cancelable o no.
• terminate para indicar que nuestro proceso ha terminado su ejecución y además lo ha hecho de forma correcta.
• cancel para indicar que nuestro proceso ha terminado su ejecución debido a una petición de cancelación.
• abort para indicar que nuestro proceso ha terminado su ejecución debido a una condición de error.
• setRangeOfValues y setCurValue para que indiquemos, si procede, cuál va a ser la duración del proceso y en qué estado se encuentra. Estos valores serán usados para calcular el getCompleted y el isIndeterminate.
• setTitle y message para ofrecer una información textual del avance del proceso.

Normalmente no crearemos directamente un TaskStatus, sino que para crear nuestro propio proceso extenderemos de la clase AbstractMonitorableTask. Esta instanciará y registrará en el manager una instancia de TaskStatus, añadiendo los métodos:

• cancelRequest, que nos permitirá solicitar la cancelación de nuestro hilo.
• getTaskStatus, que nos permitirá obtener el TaskStatus asociado al hilo.

Con todas estas piezas a nuestra disposición vamos a ver cómo podríamos hacer una pequeña extensión para gvSIG que lance un proceso en un hilo aparte, y cómo habría que hacer en este hilo para ir informando del progreso de su ejecución a gvSIG y que éste pueda mostrar esa información.

Crearemos tres clases:

• MyExtension, que será la encargada de lanzar nuestro proceso, controlando que no se pueda volver a lanzar mientras no haya terminado la ejecución de éste.
• MyProcess, que extenderá a AbstractMonitorableTask, y tendrá el código de nuestro proceso.
• MyDialog, que representara un pequeño cuadro de dialogo con algunas propiedades que puede requerir nuestro proceso.

En el próximo articulo,”Hilos y gvSIG (3 de 4): Estructura de nuestro proceso“,  continuaremos viendo cómo estructurar nuestra extensión y nuestro proceso.

Un saludo

Joaquin

En muchas ocasiones tenemos que implementar algún proceso en gvSIG que requiere cierto tiempo, y al ejecutarlo deja bloqueada la interface de usuario. Este tipo de procesos son candidatos ideales para ejecutarlos en un hilo separado permitiendo así que el usuario pueda interactuar con otras partes de gvSIG mientras éste se esta ejecutando. Sin embargo muchas veces no lo hacemos por que esto conlleva cierta complicación añadida. Intentar acceder al interface de usuario desde un hilo que no sea el hilo principal de gvSIG puede causar efectos inesperados en ella o incluso provocar que ésta quede bloqueada. Algo tan simple como actualizar una barra de progreso o presentar un mensaje al usuario desde el hilo de nuestro proceso puede convertirse en una pesadilla.

Ahora bien, en gvSIG 2 se han introducido algunas herramientas que nos pueden facilitar estas cosas. No es que nos vayan a quitar todo el trabajo o que podamos desentendernos de los problemas inherentes a trabajar con swing y múltiples hilos de ejecución, pero si ayudarnos con algunas cosas.

Las principales dificultades que nos solemos encontrar cuando intentamos ejecutar un proceso en un hilo separado de ejecución giran alrededor de:

• Presentar al usuario un indicador del progreso de nuestro proceso.
• Dar opción al usuario a poder cancelar la ejecución del proceso.
• Poder presentar al usuario información o requerir de él información a lo largo de la ejecución del proceso. Por ejemplo durante la ejecución del proceso se produce alguna condición de error y queremos preguntar al usuario para poder continuar y no abortar la ejecución de éste.

En relación a estas tareas podemos encontrar algunas herramientas en gvSIG para ayudarnos con ellas. En la librería org.gvsig.tools nos encontraremos con:

• TaskStatus. Un mecanismo que nos permite gestionar el estado de nuestro proceso. Si se encuentra en ejecución, qué medida de progreso tiene, en qué estado del proceso se encuentra, o requerir su cancelación si fuese necesario.
• AbstractMonitorableTask. Una clase que extiende a Thread integrando con él un TaskStatus para su gestión.

Y en la clase ApplicationManager del plugin org.gvsig.app, encontraremos métodos que nos permiten:

• Presentar mensajes en la barra de estado de la aplicación
• Presentar cuadros de dialogo del tipo de showMessageDialog.
• Presentar cuadros de dialogo del tipo de showConfirmDialog.
• Presentar cuadros de dialogo del tipo de showInputDialog.
• Construir componentes de swing
• Presentar cuadros de dialogo al usuario

Todo ello asegurándose que estas tareas se ejecutan en el hilo de ejecución del manejador de swing de forma que no tengamos que preocuparnos por esto desde el hilo de nuestro proceso.

Además de estas herramientas, el entorno de andami esta pendiente de las instancias de TaskStatus que se van creando y presenta en la barra de estado de la aplicación información resumida de estas de forma automática, para que no tengamos que preocuparnos por generar interface de usuario para ellas si no queremos una presentación específica.

A lo largo de estos cuatro artículos veremos:

1. Cuáles son los principales métodos y funcionalidad que nos ofrece el artefacto TaskStatus.
2. Cuál podría ser la estructura de nuestro proceso y como lanzarlo desde una extensión.
3. Cómo podríamos interactuar con el usuario de forma simple desde nuestro proceso.

En el próximo artículo, “Hilos y gvSIG (2 de 4): TaskStatus“,  continuaremos viendo cuáles son las principales funcionalidades que nos ofrecen las utilidades de TaskStatus.
Un saludo

Joaquín