Home » Java » Conceptos básicos para programar en Java (y antes de programar)

Conceptos básicos para programar en Java (y antes de programar)

 
Antes de comenzar a codificar nuestro primer applet es preciso que conozcamos ciertos detalles que se podrían denominar de "culturilla general" para saber en qué terreno nos adentramos. Así es como hemos visto la problemática del tiempo de descarga del applet y de su tiempo de proceso. También hemos visto que es necesario tener muy clara la estructura del programa y los objetos que utilizará: todo esto nos ayudará a crear un programa más fácil de entender, de ampliar y de mantener.

 

En este artículo analizaremos las particularidades de los entornos de funcionamiento de una aplicación Java y las limitaciones que debemos tener presentes:

Muchos programadores tienen la sensación de que cuando no están codificando no están siendo productivos. No es poco habitual ver a un programador codificando mientras está aún recibiendo los requerimientos del usuario. Ese software aparentemente altamente productivo (al menos esa es la impresión que se suele llevar el asombrado usuario ante la demostración técnica del programador) suele acabar en la papelera ya que se creó sin la debida abstracción del problema.  
 
Java es un lenguaje POO y por lo tanto nuestros programas estarán compuestos por objetos que interactúan entre sí. Mucho antes de abrir nuestro editor de código fuente preferido tendremos que haber decidido cuáles serán los objetos principales y cómo se relacionarán con el resto de los objetos. Ahorraremos mucho tiempo si esquematizamos los objetos y decidimos sus interfaces (el modo en que se relacionan con el exterior)  y si revisamos  ese esquema a conciencia antes de pensar en el código Java. Se debe evitar en lo posible caer en la tentación de pensar "este tema lo dejo abierto para decidirlo mientras codifico".
A medida que se empieza a codificar vamos perdiendo, sin darnos cuenta, la libertad de pensar y nos enfrascamos en los detalles: el momento de pensar libre y globalmente es antes de codificar. Esta recomendación es válida para casi todos los casos, quizá con la excepción de los programas de lógica extremadamente simple.
 

Poniéndose en el lugar del usuario 

La utilización de nuestros programas genera reacciones en los usuarios. Todo lo que se ve en la pantalla y los sonidos que se oyen conforman la experiencia del usuario de la interfaz que hemos diseñado, es fundamental que al diseñar primero nos sepamos colocar en el lugar del usuario en lugar de darle prioridad a los detalles técnicos de cómo vamos a resolver nuestro problema. Debemos tener en cuenta que no siempre nuestros gustos coinciden con el de los usuarios y, salvo aplicaciones web muy específicas, es preferible ser cautelosamente innovador.  
Como las preferencias de los usuarios son muy variadas, siempre que en la interfaz añadamos elementos adicionales, como fondo de sonido, o cierto tipo de animación, debemos tener la delicadeza de incluir una opción de desactivación de lo prescindible: no podemos asumir que a todos les encanta oir una música determinada mientras navegan por nuestra página. El modo en que se ofrezca la opción de desactivación debe ser fácil de encontrar: nada molesta más que no poder desactivar algo que resulta desagradable, este pecado nos puede hacer perder muchas visitas a un sitio web.
Existen varios aspectos generales que debemos considerar al analizar cómo se navegará en nuestra página: por ejemplo, cómo se controlará el ratón, cómo nos apoyaremos en el uso del teclado para determinadas acciones, etc. 

Ratón

El control del ratón puede parecer una obviedad, pero no su funcionalidad no es la misma en una aplicación de escritorio que en una aplicación web. Para empezar, Java no brinda un soporte directo al doble clic, por lo que uno de los principales mecanismos de comunicación usuario-aplicación merece un pequeño análisis. Java detecta sin problemas el clic simple, el movimiento del ratón y la liberación del botón de la operación de arrastrar y soltar, pero si queremos emplear el doble clic tendremos que estructurar una función (o buscarla en las bibliotecas Java) para que detecte el tiempo transcurrido entre dos clics y determine que ha sido un doble clic, algo farragoso, especialmente para implementar algo que en el mundo web no es habitual.  

Otro detalle que se debe tener en cuenta es que aunque en Java se tiene acceso a las acciones de los tres botones del ratón los usuarios web tienden a utilizar sólo el botón principal. Como alternativa, para dar más funcionalidad a la entrada por ratón, se puede combinar el clic del ratón con la pulsación de la tecla Mayús o CTRL.  

Teclado

Java no nos permite codificar applets con soporte para los botones adicionales del ratón, por lo que debemos apoyarnos en el uso del teclado para posibilitar entradas alternativas con el ratón. Cuando llega el momento de decidir qué teclas se eligen para acompañar al clic del botón principal del ratón no es conveniente que nos apartemos de las clásicas teclas: Mayús y CTRL. No conviene sorprender a los usuarios con otras combinaciones.

Fuentes

Muchas veces diseñamos cuidadosamente una interfaz de usuario eligiendo la fuente más elegante o impactante y con el resultado quedamos orgullosos por la elección. Pero al desarrollar para un entorno Web y multiplataforma las cosas no son tan simples: no todas las fuentes están instaladas en todos los equipos y para evitar sorpresas en la  presentación del texto debido a una sustitución automática de fuentes debemos determinar si la fuente elegida está disponible en los sistemas en donde queremos utilizarlas. Obviamente, si utilizamos las fuentes comunes (Arial, Times New Roman, Courier, y alguna más) no tendremos ningún problema.

Los límites del ancho de banda

En Java resulta muy fácil producir páginas con imágenes y sonidos: tan fácil que se suele sobrecargar la página con estos elementos como si se tratase de un agujero negro que lo puede absorber todo.
 
A veces se prueba una página en un equipo local y parece que su rendimiento es aceptable, la sorpresa viene luego en el entorno real. En primer término, no todos los usuarios web tiene la suerte de contar con una conexión T1 o ADSL, y en segundo término, no nos interesa en absoluto perder mercado de usuarios porque nuestras páginas tardan minutos en cargarse. 
Cuando probemos el rendimiento de nuestras páginas deberíamos hacerlo eligiendo el entorno más habitual de nuestra red de usuarios. En España, actualmente el ADSL se está imponiendo progresivamente pero es más realista pensar que el usuario promedio accede a la web utilizando un módem de 56 kbps. Esto dependerá totalmente de quienes serán los destinatarios de nuestras aplicaciones, especialmente se debe tener en cuenta su ubicación regional (hay países en donde la conexión ADSL o el cable sigue siendo un privilegio de pocos).  
Los applets en sí mismos son extremadamente pequeños y se descargan por la red sin causar el más mínimo problema; las cosas cambian radicalmente cuando se trata de gráficos y sonidos. Afortunadamente existen algunos consejos para disminuir al mínimo el tiempo de descarga de esta clase de archivos.

Sonido

Los sonidos permiten llamar la atención de los usuarios de nuestra página y es indudablemente un buen mecanismo para estos fines siempre que no se abuse de él. Y no sólo por el ancho de banda que ocupan sino por la reacción negativa del usuario, tal como se mencionó en la sección anterior. 
Java trabaja con archivos de sonido con formato au, lo que nos obliga a convertir nuestras grabaciones a este formato para poder oirlas en un applet. Este tipo de formato ocupa relativamente menos espacio que los otros formatos de sonido, pero esto lo logra perdiendo calidad. 
 
Todos los archivos de sonido incluyen al principio y al final unos segundos mudos, estos segundos aunque sean mudos ocupan ancho de banda en la descarga, por lo que es aconsejable recortarlos. La desventaja de este recorte es que el sonido puede comenzar muy bruscamente causando una sensación desagradable y a veces lo mejor es suavizar el comienzo con una entrada progresiva (fade-in) y suavizar también el final (fade-out).
 
Otro modo inteligente de dar sonido a una página sin tener que pagar demasiado peaje por el tiempo de descarga es utilizar bucles de sonido que se repiten indefinidamente hasta que se lo detiene. El secreto es saber elegir el fragmento de sonido para que éste no resulte cansador y para que su reiteración no resulte molesta para los usuarios con sentido musical. Dado que es posible superponer dos o más sonidos, se puede crear una combinación escalonada de sonidos en donde la repetición pasa desapercibida.

Gráficos

Dada la frecuencia de su utilización, en comparación con los sonidos, los archivos gráficos son los principales culpables del tiempo de descarga de las páginas. Java soporta desde su origen el uso de archivos GIF (Graphic Interchange Format) y JPEG (Joint Photographic Experts Group) y podremos utilizarlos en nuestros applets. Independientemente del formato utilizado las imágenes gráficas son todas consumidoras de ancho de banda. Si nuestro problema es tener que reducir el ancho de banda utilizado por una página con imágenes tenemos varias alternativas.
  • El primer paso para la reducción del tiempo de descarga  del gráfico es ajustar su tamaño a lo estrictamente necesario mediante herramientas de recorte que se pueden encontrar en cualquiera de los programas de gestión de imágenes (PhotoShop, IQuick, etc.).
  • El segundo paso para la reducción del tiempo de descarga del gráfico es disminuir la cantidad de colores en la visualización de la imagen. En lugar de utilizar una paleta completa de colores, se puede definir una paleta reducida con los colores más utilizados y con ello se logran tiempos de descarga más reducidos.

Al utilizar una paleta reducida se fuerza a la imagen a que utilice el color más aproximado, perdiendo fidelidad en los colores a cambio de menor tiempo de descarga, siempre se trata de buscar un punto de equilibrio.  

Las imágenes de formato GIF  poseen ciertas ventajas muy valiosas, además de ser imágenes almacenadas con un buen grado de compresión permiten la transparencia, que es la capacidad de definir un color de la imagen como transparente, y el entrelazado, que es la capacidad de ir apareciendo en la pantalla a medida de que se va transmitiendo (en contraposición de la aparición brusca de la imagen completa al finalizar toda la transmisión). Por su parte, las imágenes JPEG tienen un grado de compresión mayor y permiten una mayor cantidad de colores que los gráficos GIF, pero no admiten transparencia. El entrelazado es una capacidad muy importante ya que tranquiliza al usuario que está observando la descarga de una página, ya que le permite comprobar visualmente que la transmisión de datos se está efectuando y evaluar el tiempo faltante de la descarga.
La elección del formato de los gráficos no permite una regla fija: todo dependerá de lo que se está visualizando, la cantidad de kilobytes de las imágenes originales, de la cantidad de colores realmente necesarios  y de la cantidad de imágenes. Es muy común llegar a la conclusión de una elección combinada: algunas imágenes se visualizan bien con GIF y en otras es necesario apelar a JPEG. 
Hace unos años la cantidad de colores más habitual que se podía representar en una pantalla era de 256 colores, por lo que producir imágenes con mayor cantidad de colores representaba un esfuerzo sin recompensa; sin embargo, actualmente lo habitual es que las pantallas de los ordenadores puedan representar millones de colores, por lo que la restricción de colores no la determina la incapacidad del equipo del usuario medio para representar esos colores sino en el tiempo de descarga de las imágenes.

Las imágenes y la plataforma

Java es un lenguaje independiente de la plataforma. Esto significa que nuestro programa se utilizará en diversos sistemas operativos y ya se sabe por experiencia que las imágenes no se muestran de igual manera en las distintas plataformas, ni incluso en distintos equipos de una misma plataforma. A medida que Java se implanta en nuevas plataformas más variedad de presentación de una misma imagen tendremos. Éste es un problema que se combate adhiriéndonos lo más posible a paletas básicas de colores consolidados. De poco valdrá nuestro esfuerzo por buscar un color determinado, éste seguramente se verá como queremos en algunas plataformas y en el resto quedará modificado por un color parecido.  

Tiempo de procesamiento

Cuando desarrollamos un applet, además del ancho de banda que requiera su ejecución,  también se debe tener en cuenta el tiempo de procesamiento. Lo normal es que los usuarios de nuestra página Web posean equipos menos potentes que los que empleamos para el desarrollo de software: esto significa que los tiempos de respuesta que obtenemos en nuestro entorno de desarrollo será en general y salvo excepciones bastante menor que el tiempo real en producción en los equipos de los navegantes. Otro dispositivo que también presentará diferencias será la pantalla.
Por lo tanto, no debemos perder de vista que estamos desarrollando para los usuarios y no para nuestro equipo de gama alta: los tiempos de respuesta válidos tendremos que valorarlos en la ejecución en equipos medios o lentos con conexiones de módem estándar, no en nuestro equipo que seguramente contará con un procesador de última generación (o casi). Si el applet funciona bien en esos equipos medios podremos quedarnos tranquilos.
 

La animación y el procesamiento

La animación forma parte de los elementos que suelen capturar la atención de los navegantes de la Web, por ese motivo su uso cada vez se extiende más en el diseño de páginas web. Es difícil escapar al embrujo de una animación bien lograda. Ahora bien, debemos tener en cuenta que la animación exige capacidad de procesamiento y no tendrá el mismo atractivo si se ejecuta en un equipo de la gama alta de procesamiento que si se ejecuta en un equipo antiguo. Pero el mismo problema lo tenemos al revés: una animación diseñada para un equipo poco potente prácticamente volará en un equipo moderno.
¿Qué hacer ante este dilema? ¿Diseñamos para todos o sólo para un sector del mercado? 
Para ser coherentes deberíamos tratar de diseñar para el mercado más amplio de usuarios.  Afortunadamente podemos controlar el ritmo de visualización de los frames y ajustarlo, insertando demoras si es necesario, a la velocidad del procesador que nos toque en suerte. En Java esto se implementa de modo muy simple mediante un bucle que simplemente verifica si es el momento de dibujar un nuevo frame o si hay que seguir mostrando el anterior. Esta solución es válida pero no nos exime del intento de reducir al máximo el proceso que se realiza dentro de la rutina de animación y del ajuste del tamaño de cada imagen al mínimo posible. Todo lo que hemos explicado anteriormente sobre la optimización del tratamiento de imágenes tiene validez aquí: cada detalle que haga que las imágenes sean más ligeras no sólo favorecerá al ancho de banda disponible sino que también contribuirá a descargar la tarea del procesador. 
Las rutinas de animación son firmes candidatas a resolverse mediante subprocesos para distribuir mejor el procesamiento. Java afortunadamente es un lenguaje que implementa el uso de subprocesos con relativa facilidad y de esa manera podemos tener varias tareas en ejecución simultánea.  

Piense, piense, piense luego codifique

Como regla general es preferible hacer un esquema de la interfaz de usuario antes de codificar nada y pensar profundamente en el aspecto y en las acciones que se podrán efectuar desde la interfaz. Por supuesto ese esquema inicial se modificará varias veces antes que nos satisfaga plenamente como usuario y que satisfaga también al usuario real. Cuando ya estamos satisfechos con la interfaz de usuario ha llegado el momento en pensar en los objetos que necesitará el programa.  
Es cierto que no habremos escrito aún ni una línea de código pero nos sorprenderá todo lo que sabremos sobre nuestro programa. Lo que no resultará ninguna sorpresa es que los programas diseñados de esta manera resultarán más limpios, claros, flexibles, estructurados y fáciles de mantener y, pese a que empezaremos a codificar mucho después que siguiendo la nada recomendable técnica de codificar ahora y pensar después, estarán realmente terminados mucho antes.
izq sup der
Java No Comment

Deja una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.