A esta conclusión se llegó probando la parte lectora, la cual lanza el navegador con los datos leídos. En simulación el navegador no se lanzaba o el terminal se quedaba colgado, pero en depuración y operando instrucción a instrucción, esto no pasaba.
Cuando ocurren cosas así, todo indica que estamos ante un problema de tiempos. Posiblemente algo que no le da tiempo a refrescar, pero, dónde?
Al observar paso a paso la ejecución en el método process() se podía ver que en mitad del mismo, se saltaba al método processToolkit() al ocurrir evento Proactive_handler_available. Esto era un poco extraño, ya que en ningún momento se estaba registrando dicho evento, por lo que se hicieron los siguientes cambios:
1. Registrar el evento cuando se acaben de recibir todos los datos de la etiqueta. (El developer lo resgistraba cada vez que pasabamos por el método process())
2. Crear una variable booleana para identificar en el escuchador cuándo se quiere lanzar el navegador realmente.
3. Poner esperas entre cada envío de comando.
Se hicieron varias pruebas con diferentes valores y lugares donde poner la espera, y finalmente la mejor forma (o al menos la que funciona) es dejarlo en el processToolkit() y en este lugar:
for(int i = 0; i< 1000000000; i++) {}
proHdlr = ProactiveHandlerSystem.getTheHandler();
proHdlr.init( PRO_CMD_LAUNCH_BROWSER , (byte) 0, DEV_ID_TERMINAL);
proHdlr.appendArray(temporaryBuffer, (short) 0, (short) (2+urlDatos.length));
proHdlr.send();
clearBuffer();
reg.clearEvent((byte) EVENT_PROACTIVE_HANDLER_AVAILABLE);
Sí, la espera es un for de muchas vueltas. En simulación esta clase de cosas se pueden hacer, nadie las va a ver. Pero si realmente hace falta esta espera en la tarjeta, y todo indica que sí, habría que meterse con timers, lo que incrementará el tamaño del proyecto...
PD: Sigo esperando mis etiquetas de TID..
0 comentarios:
Publicar un comentario