viernes, 28 de noviembre de 2008

Cantidad de Visitas al Articulo:

Applets - Ayudando el Deployment

Para complementar el artículo anterior acerca de JTwain, es que escribo este nuevo, incorporando varios tips importantes en el momento de poner en producción un applet, especialmente si éste debe tener acceso a ciertos recursos locales de la máquina cliente, o ejecutar acciones que requieran de permisos especiales.

También abordo temas como el empaquetado (en archivos JAR) con librerías externas, y un método fácil y rápido de testing y debug, utilizando la consola de Java standard.

Primero - Packaging (Empaquetado)

JAR Cuando terminamos de desarrollar un applet, y debemos empezar a probarlo dentro del contexto de la aplicación de negocios, se hace necesario empaquetarlo en un archivo JAR (no entraré en detalles de porqué, dado que hay mucha información al respecto). Lo que ocurre normalmente, es que en nuestro ambiente de desarrollo, el applet funciona perfectamente, pero cuando lo empaquetamos y lo colocamos en un sitio, comienzan los problemas. Uno de los errores mas comunes es que en el empaquetado nos olvidemos de hacer referencia a las librerías externas utilizadas en el desarrollo y que se necesitan en tiempo de runtime.

Para solucionar esto, y evitar que el JAR generado sea muy grande, se pueden colocar las librerías mencionadas (JAR de éstas) en una ubicación específica en el mismo sitio, y hacer referencia a ellas en nuestro applet a través del archivo MANIFEST.MF, incluyendo la ruta en la propiedad Class-Path. Por ejemplo el archivo quedaría:

Manifest-Version: 1.0
Main-Class: MiEspacioDeNombres.MiClase.class
Class-Path: lib_externa1.jar lib_externa2.jar lib_externa3.jar

Algunos detalles importantes son que la separación de los JAR debe ser con espacios, la lista NO debe ser en una sola línea si hay varios JAR (el largo de cada fila no debería superar los 80 caracteres, y cuando pasamos a la fila de abajo, debemos dejar un espacio inicial para que sea reconocida. Un ejemplo completo se puede descargar de aquí. En este ejemplo las librerías se deberían ubicar en el mismo directorio del JAR de nuestro applet.

Segundo - Permisos de Ejecución

Si el applet no accede a ningún recurso local de la máquina cliente donde ejecuta, no habrá problemas con los permisos de ejecución, de otra forma, es necesario agregar esos permisos en el archivo java.policy, ubicado en el directorio C:\Archivos de programa\Java\jre<version>\lib\security (obviamente si la distribución del sistema operativo es en inglés será C:\Programs Files). Allí se deben agregar los permisos necesarios de acuerdo a nuestras necesidades. En ésta página encontrarán detalles de suma utilidad para este tema. Por supuesto que una salida rápida es agregar permisos para todo de la forma:

permission java.security.AllPermission;

Esto soluciona rápidamente el problema de funcionamiento, pero abre la puerta a potenciales ataques malintencionados. Mi recomendación es que se tomen el trabajo de ir probando (si al menos no tienen claro que permisos necesitan) y habilitando solo lo necesario. Para este trabajo es útil el siguiente punto de testing y debug.

Tercero - Testing y Debug

Cuando desarrollamos un applet utilizamos una versión específica de Java. Otro problema común es que no sabemos cual es la versión instalada en la máquina cliente que lo ejecutará. Para evitar malos resultados, es necesario entonces probar el applet con diferentes versiones JVM.

Para esto es muy útil:

  1. Habilitar la consola de Java en tiempos de ejecución
  2. Ir cambiando la versión de java, con la que el navegador utilizado en las pruebas, ejecutará el applet.

Para lo primero se debe ingresar a Panel de Control > Java > Avanzado y habilitar la consola de la forma:

Consola

Para lo segundo, en Panel de Control > Java > Java, se habilita o deshabilita la versión que deseamos utilizar con el navegador, de la forma:
Consola_Ver

Nota: Es necesario cerrar el navegador cada prueba que hagamos para que no use caché.

Luego, cuando ejecutamos el applet desde el navegador, llamando a la página donde se encuentra, Java abre automáticamente la Consola y muestra allí cualquier excepción que se produzca, tanto por falta de permisos como por fallas del funcionamiento propio del applet (faltas de librerías externas, etc.).
Consola_Debug

So far, so good!

Images by Tinypic

Leer más...

viernes, 7 de noviembre de 2008

Cantidad de Visitas al Articulo:

Comparación de Navegadores

Logos Desde hace buen tiempo que vengo probando los 3 navegadores mas usados últimamente en Windows, o al menos los 3 mas nombrados: Internet Explorer - IE (Microsoft), Firefox (Mozilla) y Chrome (Google).

Como siempre ocurre, existen pro y contras en cada uno, y aquí enumeraré algunas de esas características, como ayuda para seleccionar uno de los 3, de acuerdo a cada necesidad.

Tabla comparativa

Esta tabla comparativa permite tener una idea rápida de los pro y contras de cada navegador:

CaracterísticaChrome Firefox IE
ok GráficaDiseño minimalista. Cambio algunos conceptos arraigados de otros navegadores.Permite personalizar el diseño gráfico a través de plantillas que se descargan del site.No permite cambios además de los colores básicos desde Windows.
okSoporte AppletSi - Pero solo versión de java versión 1.6.0_10-rc-b28 (mas adelante explico por que).Si - Desde versión 1.3 probé que funciona bien.Si - Desde versión 1.3 probé que funciona bien.
okSoporte ActiveXNoNoSi
okSoporte PDFSiSiSi
okSoporte FlashSiSiSi
okRapidez (de 1 a 10)978
okUsabilidad (de 1 a 10)7 (Cambió algunas convenciones ya establecidas por los demás navegadores)99
okLengüetasSiSiSi (pero desde versión 7 en adelante)
okRobustez (de 1 a 10)899
okEstabilidad (de 1 a 10)97Versión 6 - 9
Versión 7 - 7
Versión 8 - 6

El análisis podría seguir, con varios puntos mas, pero con estos desarrollados creo que se pueden sacar algunas conclusiones.

Temas Importantes

Un tema importante que agregó Chrome, es que cada lengüeta se ejecuta como un thread separado, lo que permite que si alguna de las lengüetas falla, no es necesario cerrar las demás, solo se cierra esa. Ese es el motivo por el cual fue desarrollado y permite ejecución de applets con la última versión de JRE (versión 1.6.0_10-rc-b28). Esta versión hace factible esta característica. De todas formas, "no todo lo que brilla es oro". Me pasó algunas veces que al fallar una lengüeta, igualmente tuve que cerrar todas las demás. Otro tema destacable es que es Open Source, por lo que puede ser descargado el código fuente para generar una versión de navegador personalizada.

Otro tema relevante de mencionar es el soporte de ActiveX. No se la causa, aunque se me ocurre que es netamente comercial (licenciamiento), por el que Firefox (Mozilla) o Chrome (Google) NO soportan ActiveX. La realidad indica que existen varias soluciones web que se basan en ActiveX, lo que hace que estos navegadores pierdan mercado con respecto al IE (Microsoft). Quizá alguien pueda comentarme cual es el motivo real de este tema.

Conclusiones

Si el objetivo del navegador es para acceso a webmail, lectura de diarios on line, búsqueda de información en general, Chrome es una buena opción, dado que es un navegador liviano, rápido, y con su diseño minimalista (y opciones reducidas también), hace la vida fácil a los usuario inexpertos. Una vez que se acostumbran a la nueva propuesta de diseño, es fácil de manejar y configurar.

Si usa Windows como sistema operativo, IE (Microsoft) viene incluido en él. Por lo que al instalar el sistema operativo, también se configura el navegador. Esto hace que no se necesite descargar ni instalar nada externo. Facilita la instalación y soporta tanto Applet como ActiveX.

Si es un fanático de la imagen, Firefox (Mozilla) le dará a través de los temas y complementos, gran variedad de opciones para jugar.

Ahora, decida y disfrute.

So far, So good!

Imágenes by Tinypic

Leer más...

miércoles, 5 de noviembre de 2008

Cantidad de Visitas al Articulo:

JTwain - Utilizando el scanner desde Java

Con motivo de una consulta, estuve probando y analizando librerías, algunas gratuitas y otras licenciadas, para el manejo de scanners en Java. Todas ofrecen características similares y permiten manejar un scanner bajo el standard TWAIN, claro que con algunas diferencias sustanciales, las cuales son relevantes en momento de seleccionar la correcta para nuestro proyecto.

Aquí expongo algunas experiencias de la librería seleccionada en mi caso y comparto información útil y ejemplos, para aquellos que necesiten desarrollar alguna aplicación basada en este tema. Además dejo referencias de otras librerías, y temas relacionados, como el reconocimiento de códigos de barras de las imágenes capturadas y OCR.

Librerías

Algunas librerías que puedo mencionar, son:

LibreríaDescripción
image mmscomputingEs una librería Open Source, que además del manejo de scanner para Windows, implementa Sane (manejo de scanner para Linux), fax, etc. Está disponible para Java y funciona perfectamente con JRE 1.4.2 o superior. Tiene un foro bastante completo y el coordinador (Michael Meiwald) responde muy rápidamente ante consultas. Sus respuestas son de gran ayuda. Además, existen ejemplos de uso de la librería muy completos y operativos, que ayudan mucho en el momento de armar nuestra solución.
imageJTwainEs licenciada, y permite el manejo del scanner, además de tratamiento de imágenes TIFF multipágina. El valor depende del modo de licenciamiento, dentro del rango de USD 198 a Euros.
imageMorenaEs el sucesor de JavaTwain. También cubre tanto Twain como Sane. Es una librería licenciada

Existen algunas mas, que no las probé, pero que cubren aproximadamente los mismos temas.

Trabajando con el standard

Todas las librerías permiten seleccionar el scanner con el que deseamos trabajar, así como el formato de imagen a capturar (JPG, TIFF, etc), calidad y tamaño de la misma.

En el caso de la librería que finalmente recomendé, mmscomputing, se debe implementar una interface en donde existe un método llamado negotiate, donde se realizan todos los ajustes de calidad de imagen, tamaño, y algunos otros, de acuerdo al standard TWAIN y las características soportadas de éste en el scanner seleccionado. Por ejemplo:

private void negotiate(ScannerIOMetadata metadata) {
ScannerDevice sd = metadata.getDevice();
try {
//Anulo pantalla de configuracion del scanner
sd.setShowUserInterface(false);
//Seteo que muestre barra progreso del scanner
sd.setShowProgressBar(true);
//Seteo area de escaneo
sd.setRegionOfInterest(TopLeft,TopRigth,Width,Heigth);
sd.setResolution(dDPI);
} catch (Exception e) {
addToLog("Error configurando scanner [" + e.getMessage() + "]",true);
metadata.setCancel(true);
}

if (metadata instanceof TwainIOMetadata) {
TwainSource source = null;
try {
source = ((TwainIOMetadata) metadata).getSource();
} catch (Exception ex) {
if (source!=null) source.setCancel(true);
}

try {
/* Habilito esto si deseo saber que está implementado del standard para
este scanner
TwainCapability[] cap = source.getCapabilities();
for (int h = 0; h < cap.length; h++) {
System.out.println(cap[h].getName());
}
*/

source.setShowProgressBar(true);
source.setCapability(TwainConstants.ICAP_UNITS, TwainConstants.TWUN_INCHES);

//Seteo colo de la imágen a capturar

if
(isColor) {
source.setCapability(TwainConstants.ICAP_PIXELTYPE, TwainConstants.TWPT_RGB);

} else if (isGrayScale) {
source.setCapability(TwainConstants.ICAP_PIXELTYPE, TwainConstants.TWPT_GRAY);
} else if (isBW) {
source.setCapability(TwainConstants.ICAP_PIXELTYPE, TwainConstants.TWPT_BW);
}
} catch (Exception e) {
if (source!=null) source.setCancel(true);
addToLog("Error configurando scanner [" + e.getMessage() + "]",true);
e.printStackTrace();
}
}

Formatos de Salida

Si la necesidad es escanear imágenes de una página, lo mejor es utilizar JPG, que guarda una buena relación entre tamaño y calidad (es una imagen comprimida con pérdida).

Si la necesidad es escanear imágenes multipágina, es necesario entonces usar TIFF.

Un problema que encontré, es que varias de ellas están generando archivos archivos .TIFF pero de la versión mas nueva (6.0) pero el visualizador de Windows, NO lo reconoce, porque por alguna razón nunca se actualizó a ese formato. Conclusión, si se desea visualizar la imagen generada en TIFF, ya sea multipágina o no, se debe usar otro software. Por ejemplo yo uso IrfanView, que es gratuito.

Por último, es bueno mencionar, que existen otras opciones de generación que no sean imágenes. Por ejemplo, una opción es PDF. Si usamos por ejemplo, una librería gratuita llamada iText, podemos generar documentos PDF multipáginas, con el agregado que en este caso podemos incluir imágenes de distintos tamaños, colores y calidades, contrario al caso de TIFF donde no es factible.

OCR y Códigos de Barras

Cuando lo que escaneamos es un formulario por ejemplo, que contiene uno o más códigos de barra, a veces es útil reconocerlos, y con el valor obtenido, hacer un control para nuestra aplicación. Para ello es necesario otras librerías como por ejemplo Aspose (es licenciada con un valor aproximado entre 390 y 1200 Euros, dependiendo del tipo de licenciamiento). Esta librería permite reconocer en una imagen JPG o TIFF un código de barras de diferentes tipos (CODE128, PDF417, etc).

El funcionamiento es muy sencillo, dado que existen primitivas para generar y reconocer códigos, así como también letras (OCR), con una buena calidad final.

Comentario Final

Son varias las opciones existentes, y se pueden combinar de muchas maneras, de tal forma que el proyecto en curso tenga final feliz.

So far, So good!

Imágenes by TinyPic

Leer más...
 
Este Weblog, InforMateando..., está licenciado bajo Licencia Creative Common - por Gustavo Suhit