Pregunta

Estoy escribiendo una aplicación J2ME. Una de las piezas es algo que sondea periódicamente el contenido de un directorio y, si hay algo nuevo, lo pinta en la pantalla. He hecho esto haciendo que el formulario de la interfaz de usuario inicie un hilo de sondeo con un puntero de vuelta a sí mismo, y cuando el hilo de sondeo encuentra algo, vuelve a llamar al formulario y llama a un método sincronizado para actualizar su pantalla. Esto parece funcionar bien.

La pregunta que tengo es esta. En C # /. NET sé que no es bueno tener subprocesos que no sean de UI actualizando la UI, y la forma correcta de manejar esto es delegarlo en el subproceso de UI.

Por ejemplo. lo siguiente:

public void DoSomeUIThing()
{
    if (this.uiComponent.InvokeRequired)
    {
        this.uiComponent.Invoke(someDelegateThatCallsBackToThis);
    }
    else
    {
        this.uiComponent.Text = "This is the update I want to happen";
    }
}

¿Existe un equivalente J2ME para cómo administrar este proceso? ¿Qué tal Java? ¿O Java / J2ME simplemente juega mejor con respecto a esto? Si no, ¿cómo se hace esto?

[EDITAR] Parece que Swing admite lo que estoy preguntando a través de los métodos SwingUtilities.invokeLater () e invokeAndWait (). ¿Existe un marco equivalente para J2ME?

¿Fue útil?

Solución

Con respecto a Java, lo que está describiendo parece un SwingWorker (hilo de trabajo) .

Cuando un programa Swing necesita ejecutar una tarea de larga duración, generalmente usa uno de los hilos de trabajo, también conocidos como hilos de fondo.

Un programa Swing incluye los siguientes tipos de hilos:

  • Subprocesos iniciales, los subprocesos que ejecutan el código de aplicación inicial.
  • El subproceso de envío de eventos, donde se ejecuta todo el código de manejo de eventos. La mayoría del código que interactúa con el marco Swing también debe ejecutarse en este hilo.
  • Subprocesos de trabajo, también conocidos como subprocesos en segundo plano, donde se ejecutan tareas en segundo plano que requieren mucho tiempo.

Regla de un solo hilo :
Una vez que se ha realizado un componente Swing, todo el código que pueda afectar o depender del estado de ese componente debe ejecutarse en el hilo de despacho de eventos.

Cuando se usa en un contexto J2EE, debe tener cuidado cuando haciendo referencia a un SwingWorker desde un EJB .

Con respecto a J2ME , depende si está desarrollando su aplicación como un MIDlet estándar que se ejecutará en cualquier dispositivo habilitado para MIDP, o por ejemplo como RIMlet, una aplicación basada en CLDC que utiliza API específicas de BlackBerry y, por lo tanto, solo se ejecutará en dispositivos BlackBerry.

Debido a que, a diferencia de las clases de interfaz de usuario de MIDP, los RIM son similares a Swing en el sentido de que las operaciones de interfaz de usuario se producen en el subproceso de eventos, que no es seguro para subprocesos como en MIDP. Para ejecutar el código en el hilo del evento, una aplicación debe obtener un bloqueo en el objeto del evento, o usar invokeLater () o invokeAndWait () - trabajo adicional para el desarrollador, pero la sofisticación viene con una etiqueta de precio.

Pero para LCDUI , puede acceder a un formulario desde varios hilos .

Otros consejos

Hay muchos perfiles de Java ME. Si te refieres a MIDP, entonces Display.runSerially es lo que quieres.

Para AWT (Swing) usaría EventQueue.invokeLater ( SwingUtilities.invokeLater solo es necesario debido a que Java 1.1 no tiene el EventQueue método: 1.2 está a punto de celebrar su décimo cumpleaños). Para la Common DOM API, use DOMService.invokeLater .

No importa qué afirmaciones pueda hacer una API GUI sobre seguridad de subprocesos, probablemente estén equivocadas (algunas de las afirmaciones de Swing se eliminan en JDK7 porque no son implementables). En cualquier caso, es poco probable que el código de la aplicación sea seguro para subprocesos.

Para las aplicaciones j2me, probablemente quieras que sea simple. Lo principal es tocar los componentes de la interfaz de usuario solo en el hilo del evento. La forma directa de hacerlo es usar invokeLater o invokeAndWait . Dependiendo de sus bibliotecas, no tendrá acceso a nada más que eso. En general, si no se proporcionan en su plataforma, probablemente equivale a que no hay soporte de hilos y no es un problema. Por ejemplo, el blackberry lo admite .

Si desarrolla bajo SWT, esto se logra mediante el método asyncExec () del objeto Display. Pasa un objeto que implementa Runnable para que el hilo de la IU ejecute los cambios realizados en otro hilo.

Éste es un ejemplo tomado de aquí

public void itemRemoved(final ModelEvent me)
{
   final TableViewer tableViewer = this.viewer;

   if (tableViewer != null)
   {
      display.asyncExec(new Runnable()
      {
         public void run()
         {
            tableViewer.remove(me.getItem());
         }
      }
   }
}

Puedo dar fe de que el kit de herramientas de la interfaz de usuario MIDP es realmente seguro para subprocesos, ya que tengo MIDlets grandes con GUI compleja ejecutándose en millones de teléfonos fabricados por casi todos los fabricantes, y nunca he visto un problema al respecto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top