REPORTE DEL PROYECTO DE INGENIERIA ELECTRONICA

División de Ciencias Básicas e Ingeniería

Ingeniería Electrónica

Reporte Del Proyecto De Ingeniería Electrónica:

“Desarrollo De Aplicaciones en Java Para Pda’s”

Por:

Villa Ramos Francisco Asesor: Rodríguez Flores Eduardo

PROYECTO DE INGENIERÍA ELECTRÓNICA

II

A mis padres, por darme la oportunidad y la confianza de terminar la licenciatura. Este logro es más suyo que mío. Gracias. A mi asesor por toda la paciencia que me ha tenido. Gracias Eduardo.

Francisco Villa Ramos


III

PRÓLOGO

Hoy en día, Java se esta convirtiendo en el lenguaje de referencia obligatorio. Cada vez, en la universidad, se imparten mas cursos utilizando este lenguaje como herramienta de programación. Lo cual nos lleva a pensar si ya ha pasado el tiempo en que la principal excusa para no utilizar Java era la velocidad. Y ahora, al utilizarlo, podemos acceder a las características que siempre se nos han mencionado: la tan mencionada (y anhelada) portabilidad, y la programación orientada a objetos, entre las más importantes.

En la industria de software Java también esta teniendo gran aceptación, en particular en programación Web del lado del servidor (JSP´s, Servlet´s) o en programación de componentes distribuidos como los Enterprise JaveBean´s. Al utilizar estos servicios, los problemas de velocidad de ejecución y desempeño, pasan a segundo término, ya que por lo regular las máquinas donde estos se ejecutan, tienen una gran cantidad de recursos disponibles.

Existe otro sector en el cual se están dando los primeros pasos en construir sistemas de tipo comercial en Java, este es el mercado de los dispositivos móviles. En los dispositivos móviles (pda’s), es un buen lugar para probar al máximo las capacidades de la plataforma de desarrollo Java, ya que estos dispositivos están limitados en recursos (memoria, velocidad de procesador, etc.).

Hasta ahora, los principales desarrollos para pda’s, solo han sido aplicaciones con bajos requerimientos de recursos como lo son: juegos, pequeñas agendas, directorios, etc. Pero empecemos a pensar en aplicaciones con mayores necesidades: conexiones a servidores externos, conexión a bases de datos, pantallas sobrecargadas. Estos son los requerimientos básicos de una aplicación comercial.

¿Estará Java preparado para entrar a este mercado? Esta es una de las discusiones que se quieren comenzar en este proyecto.


IV

ÍNDICE INTRODUCCION ..................................................................................................................................... 1

APRENDER JAVA .................................................................................................................................... 1 DECISIÓN DE HERRAMIENTAS A UTILIZAR. ........................................................................................... 2 CLIENTE FTP ......................................................................................................................................... 2 MÓDULO DE PEDIDOS ............................................................................................................................. 3

CAPITULO 1: DECISIÓN DE LAS HERRAMIENTAS A UTILIZAR.............................................. 4 1.1 MAQUINA VIRTUAL JEODE. ................................................................................................... 4 1.2 BASE DE DATOS POINTBASE................................................................................................. 4 1.3 SERVIDOR DE PRUEBAS FTP CESARFTP ................................................................................ 5 1.4 IDE DE DESARROLLO JBUILDER ............................................................................................. 5

CAPITULO 2: CLIENTE FTP PARA POCKET PC. ........................................................................... 6 2.1 REQUERIMIENTOS.................................................................................................................... 6 2.2 IMPLEMENTACIÓN ..................................................................................................................... 6

GUI: Interfaz Gráfica de Usuario..................................................................................................... 7 AWT ................................................................................................................................................... 7 Limitaciones en J2ME ...................................................................................................................... 9 Comunicaciones ................................................................................................................................. 9

2.3 RESUMEN................................................................................................................................ 11 CAPITULO 3: MÓDULO DE PEDIDOS: NADRO............................................................................. 12

3.1 TRANSFORMACIÓN DE LA BASE DE DATOS. ........................................................................... 13 3.2 INTERFAZ DE USUARIO........................................................................................................... 14

Utilizando componentes AWT......................................................................................................... 15 Dibujando nuestros propios botones............................................................................................... 17

3.3 BÚSQUEDA EN LA BASE DE DATOS........................................................................................... 23 3.4 SOLUCIONES A LA BÚSQUEDA.................................................................................................. 25

Solución básica................................................................................................................................ 25 Solución dinámica ........................................................................................................................... 27 Solución dinámica + busquedas selectivas ..................................................................................... 28 Propuestas de soluciones................................................................................................................. 28

3.5 PEDIDOS ................................................................................................................................. 29 3.6 CAPITULO 4: RESUMEN FINAL ......................................................................................... 32


1

INTRODUCCIÓN

En la actualidad la programación para dispositivos móviles es dominado por lenguajes como C++ o Visual Basic. Lenguajes como C++ cumplen los requisitos indispensables para las necesidades de este mercado como lo es el explotar al máximo las capacidades limitadas de estos dispositivos. Entonces ¿Por qué pensar en Java?

Creemos que uno de los motivos de mayor peso es la portabilidad, la famosa frase de “desarróllalo una vez, ejecútalo donde quieras”, da un gran atractivo a proponer a Java como la plataforma de desarrollo. Y si se puede llegar a un alto desempeño en aplicaciones de mucha demanda, Java se convierte entonces en la opción más interesante.

En este proyecto se tratará de analizar si la tecnología Java esta preparada para este tipo de requerimientos. Esto se plantea lograrlo desarrollando aplicaciones con necesidades parecidas a las que tienen las aplicaciones de tipo comerciales como lo son: comunicación, conexión a base de datos, etc.

En lo particular, a lo largo de los 2 trimestres que tiene por duración el proyecto terminal, las actividades realizadas fueron las siguientes:

• Aprender Java. • Decisión de herramientas a utilizar. • Cliente FTP. • Modulo de pedidos.

Aprender Java

Uno de nuestros grandes retos en la realización de este proyecto fue aprender a programar en un nuevo lenguaje: Java. Ya que, al principio del proyecto nuestro conocimiento sobre esta plataforma de desarrollo eran totalmente nulos.

Aprender la sintaxis de este nuevo lenguaje no fue problema, ya que en su mayoría, la sintaxis de Java así como sus palabras reservadas son muy parecidas a las del lenguaje C.

El verdadero reto fue la programación orientada a objetos. Ya que para alguien que siempre ha programado con una metodología de programación estructurada, los cambios que surgen con el enfoque orientado a objetos, no son fáciles de asimilar. Esto se nota ampliamente en los primeros desarrollos que se realizaron, ya que conceptos como: herencia, polimorfismo,


2

encapsulamiento, etc., aun no eran comprendidos completamente y por ello tampoco eran utilizados.

Conforme se fue avanzando en el proyecto y con práctica en Java, se puede notar como estos conceptos se van aterrizando y se comienzan a utilizar de forma natural.

Para este proyecto nos centramos en Java ME que es la parte de la plataforma Java que se encarga de solventar las necesidades de aplicaciones Java destinadas a ejecutarse en dispositivos con pocos recursos, principalmente teléfonos móviles y PDAs. Decisión de herramientas a utilizar.

De acuerdo a las necesidades y a los recursos disponibles, este capitulo trata de las herramientas que utilizamos y una breve explicación de las características que nos hicieron inclinarnos por ellas.

Las necesidades que se tenían que cubrir eran las siguientes:

• Máquina Virtual • Base de datos • Servidor de pruebas FTP • IDE de desarrollo

Cliente FTP

Los sistemas de software actuales tiene la necesidad de comunicarse con otros sistemas. Esta comunicación no es trivial, ya que de ella puede depender el correcto funcionamiento del sistema. Esto se complica cuando la comunicación se tiene que llevar a cabo entre dos sistemas que no se encuentran en la misma máquina, o peor aun, sistemas que no se encuentran en el mismo lugar físico.

FTP es un protocolo de transferencia de archivos por medio de una red. A través de el podemos transferir archivos de configuración, bases de datos, o cualquier información que pueda ser codificada en forma binaria.

Este desarrollo se realizo para determinar que tan fácil es lograr una comunicación en una aplicación Java.


3

Módulo de pedidos

Una aplicación regular por lo general tiene la siguiente estructura:

1. Contenedor estático de información: Esto es, una base de datos, un archivo de configuración, etc., en la cual se puede guardar los datos que son necesarios para la ejecución de la aplicación.

2. Una interfaz gráfica de usuario: Por medio de la cual, el usuario puede crear, modificar o eliminar información del sistema.

Esto es algo que se realiza comúnmente en una aplicación comercial. Las

cosas se empiezan a complicar cuando la cantidad de datos que se quiere revisar, modificar o eliminar, es muy grande, ó cuando la interfaz grafica empieza a ser muy complicada (navegación de pantallas intrincada, muchos controles por pantalla, etc.).


4

CAPITULO 1: DECISIÓN DE LAS HERRAMIENTAS A UTILIZAR

Una de las primeras tareas que se tuvieron que realizar fue la de buscar las herramientas necesarias para comenzar a hacer nuestros primeros programas de prueba. 1.1 Maquina virtual JEODE.

En el mercado de las máquinas virtuales Java para la plataforma Pocket PC, existen pocas opciones a elegir. Por lo regular versiones nuevas de dispositivos móviles, ya traen incluida su propia máquina virtual. En nuestro caso la labor consistió en escoger entre dos o tres productos y decidir por el que mas se adaptara a las necesidades que se tenían. Al final, se opto por la que mostraba una mejor documentación ya que, en cuanto a prestaciones técnicas, eran casi idénticas.

Jeode es un producto de Insignia™ que es totalmente compatible con la especificación PersonalJava 1.2 de Sun Mycrosystems1. Sabiendo esto, podemos acceder a toda la documentación necesaria del API de clases que tenemos disponible. 1.2 Base de datos POINTBASE.

Al igual que en la máquina virtual, las opciones en bases de datos comerciales a elegir son pocas. En lo particular, nosotros solo tuvimos 2 propuestas: pointbase y codebase. Se opto tomar pointbase en una versión demo que esta disponible en su sitio Web de forma gratuita.

1 Para mayor información sobre esta especificación se puede visitar: http://java.sun.com/products/personaljava/index.jsp


5

La decisión de utilizar pointbase fue en gran parte porque es una base completamente desarrollada en java. Esto nos pareció muy atractivo ya que no importa donde se desarrolle la base de datos, se puede portar a cualquier plataforma sin tener que hacer modificaciones a los datos.

La forma en que se nos presenta pointbase es un paquete de clases, con lo cual, para acceder al API necesario, simplemente se tiene que importar dicho paquete y con ello ya se puede hacer un completo uso de esta base de datos.

El programa de instalación contiene también una consola para la administración de bases de datos, muy básica, pero con la funcionalidad necesaria para ser una herramienta muy útil a la hora de hacer pruebas en nuestros programas y entrar a la base de datos por la “puerta trasera”. 1.3 Servidor de pruebas FTP CesarFTP

CesarFTP 0.99g

Para la parte de comunicaciones se necesito un servidor de FTP. Buscando

en la red encontramos este pequeño servidor. Es muy sencillo de utilizar y fácil de instalar. Es por eso que se decidió utilizarlo como servidor de pruebas de nuestros programas de comunicaciones. 1.4 IDE de desarrollo JBuilder

Hoy en día, el gran tamaño en los desarrollos de software, hace que, enfrentarlos sin herramientas sea muy difícil de lograr. El IDE de desarrollo es una de las primeras cuestiones que se tiene que resolver ya que se necesita un tiempo para adaptarse a las herramientas que nos ofrece. Borland™ tiene a disposición del publico una versión gratuita de su producto JBuilder que es un IDE para desarrollos en Java.


6

CAPITULO 2: CLIENTE FTP PARA POCKET PC.

La primera tarea de nuestro proyecto además de aprender a programar en java fue el desarrollo de un cliente FTP que funcionara en la plataforma Pocket PC.

Este desarrollo, además de la finalidad de un sistema de comunicaciones básico, tenia el objetivo de mostrar cuales eran los avances obtenidos en Java y en las herramienta proporcionadas hasta ese momento. 2.1 Requerimientos

La estructura del sistema era simple y la única necesidad que se tenía que satisfacer mostraba los siguientes requerimientos:

1. Conectarse a un servidor FTP predispuesto. 2. Navegación en las carpetas disponibles del servidor. 3. Selección del archivo o directorio a descargar. 4. Descarga del archivo a la Pocket PC.

Usuario

Descarga

Servidor FTP

Sistema de Comunicaciones

Figura 1

Tal y como se muestra en la figura 1, el sistema solo tiene una acción disponible para el usuario. 2.2 Implementación

El desarrollo de esta aplicación se puede dividir en 2 partes fundamentales las cuales se muestran en la figura 2:


7

GUI

COMUNICACIONES

Figura 2 Partes del sistema de comunicaciones.

GUI: Interfaz Gráfica de Usuario

Esta parte es la encargada de mostrar al usuario los controles necesarios para realizar las acciones que se requieren para la descarga de archivos.

El desarrollo es muy simple ya que todo se realiza en una sola ventana en la cual, al seleccionar la acción de descarga del menú único FTP, aparece una lista de los archivos presentes en el servidor. De ahí se pueden seleccionar y al presionar el botón descarga, el archivo o la carpeta seleccionado son traídos a un directorio de la Pocket PC. La secuencia se muestra en la figura 3.

Figura 3 Toda la acción de la descarga se realiza en una sola pantalla. AWT

Para realizar entornos gráficos en J2ME2 se tiene como paquete gráfico AWT. Este paquete es un subconjunto del paquete del mismo nombre para la version J2SE3 y solo contiene los controles básicos.

2 A partir de este momento esa será la abreviatura que se utilizara para referirse a Java 2 Micro Edition. 3 J2SE: Java 2 Standard Edition


8

Esta aplicación se desarrollo en una sola clase: FrameDeInicio la cual es responsable de mostrar al cliente la ventana del programa. Los pasos a seguir para desarrollar esta GUI se enuncian a continuación.

1. Importar el paquete awt en el cual están definidos todos los controles, clases de apoyo e interfaces que se necesitan para desarrollar una ventana: import java.awt.*;

2. Declarar los componentes que formaran parte de la ventana: private MenuBar barraDeMenu; private Menu ftp; private MenuItem salir; private MenuItem descarga; private MenuItem archivos; private MenuItem directorios;

3. Definir las acciones que se realizaran cuando el usuario realice un evento: descarga.addActionListener(new AccionDescarga());

salir.addActionListener(new AccionCerrar()); 4. Agregar los componentes, definir el tamaño de la ventana y hacerla

visible: f.agregar(f, descarga, 0); f.agregar(f, salir, 0); f.setSize(200, 250); f.setResizable(false); f.setVisible(true);

Estos mismos pasos pueden ser utilizados para desarrollar entornos gráficos de tipo general.

Aunque esta parte del sistema de comunicaciones es muy simple, fue la primera vez que programamos ventanas para Pocket PC y las impresiones que quedaron al terminar este trabajo son las siguientes:


9

Limitaciones en J2ME

Cuando se empezó a desarrollar esta aplicación se partió de la utilización de plataforma SE, en ella se desarrollo todo el proyecto. Sin embargo, al principio no éramos consistentes de las limitaciones que se tenían al transportar nuestros programas al verdadero entorno donde se tenían que ejecutar las aplicaciones ( la Pocket PC).

Al no tener en cuenta que J2ME era limitado en comparación con su hermano mayor, J2SE, los errores mas comunes que se tenían surgían de falta de las herramientas que utilizábamos en J2SE y que no estaban disponibles en java ME.

Por herramientas nos referimos a clases, métodos e incluso API’s completos que dado las limitación de hardware que se tiene en un sistema móvil como el utilizado, no se pueden implementar.

Para resolver este tipo de problemas la forma en la que los enfrentamos fue apoyándonos en la documentación de java. Los pasos que seguíamos eran al principio prácticamente los siguientes:

1. Programas la aplicación en una PC de escritorio. 2. Probar la funcionalidad de la aplicación en este ambiente. 3. Una vez que se sabía que la aplicación no tenía errores, transportarla a

la Pocket Pc. 4. Realizar pruebas del programa en este ambiente y en este paso se

obtenían los errores, producidos en su mayoría por clases o métodos no encontrados.

En base a los resultados obtenidos en los pasos anteriores comúnmente se buscaba en la documentación las clases o métodos que realizaran una funcionalidad semejante a la que se necesitaba. Pero, a veces, este método no existía, o en el mejor de los casos, existía, pero tenia una funcionalidad diferente o limitada En estos casos lo único que quedaba por hacer era utilizar como base la clase encontrada y desarrollar la parte faltante.

Comunicaciones

Esta es la parte mas pesada de la aplicación ya que, se encarga de realizar la comunicación con el servidor FTP, así como enviar y transmitir los comandos de FTP.


10

PocketPC ServidorFTP

Enviar solicitud

Recibir respuesta

identificarse

Transferencia de archivos

Figura 4 Modelo de Comunicaciones

Esta parte de la aplicación requiere de conocimientos en diversas áreas:

1. Programación de Sockets en Java. 2. Operación interna del protocolo FTP. 3. Traslado de errores de FTP a errores en Java.

De estas 3 la que mas nos preocupaba era la operación interna del

protocolo FTP ya que dicho protocolo, solo lo habíamos usado a nivel de usuario.

Durante un periodo (alrededor de 2 a 3 semanas) tratamos de solucionar este problema pero los resultados que se obtenían eran poco alentadores. El protocolo FTP era demasiado grande para nosotros por el conocimiento y por el tiempo del que disponíamos.

Para dar respuesta a este gran problema, uno de nuestros principales apoyos fue los foros de discusión que existen por todo el mundo a través de Internet, aunque la mayoría de ellos se encuentra en inglés, también encontramos muchos buenos foros en español dedicados a la plataforma Java. En ellos, realizamos muchas consultas sobre que podíamos hacer para acceder al protocolo FTP desde Java. Las respuestas fueron rápidas y encontramos mucha gente que estaba haciendo cosas parecidas o que simplemente estaba interesada.

En uno de estos foros, un usuario regaló a la comunidad su código fuente de clases que realizaban conexión a FTP pero solo implementaba los comandos simples de este protocolo.


11

Estas clases utilizaban el API Standard de Java, con lo cual la transferencia a la plataforma J2ME no tuvo ningún problema ya que eran perfectamente compatibles.

Con este ejercicio, se utilizaron características que se quieren lograr en el desarrollo de sistemas y que, con otros lenguajes distintos de Java, es muy difícil de lograr. Estas características son: la reutilización de código y la portabilidad. Ya que no hubo necesidad de realizar adaptaciones a las clases que se nos proporcionaron para que fueran correctamente ejecutadas en el sistema Pocket PC. 2.3 Resumen

Este desarrollo nos dejó un grato sabor de boca ya que se demostró que construir un sistema de comunicaciones en Java, no es una tarea complicada de realizar. Y, aunque gran parte de la funcionalidad principal de este sistema fue adquirida de un tercero, con ello también se demuestra una de las virtudes de Java, la portabilidad.

Uno de los defectos que desde esta aplicación comenzamos a notar fue que el API gráfico de J2ME: AWT, es demasiado limitado ya que solo posee controles simples y en ocasiones la carga de pantallas no es tan rápida.


12

CAPITULO 3: MÓDULO DE PEDIDOS: NADRO

Este fue el desarrollo central de nuestro proyecto. La conexión a bases de datos, es una tarea muy común de las aplicaciones comerciales. Pero esta no es la necesidad principal que se quiere solventar.

En realidad, el problema principal, es la velocidad de respuesta de una aplicación a acciones del usuario. Y, aunque por lo regular estas acciones desemboquen en peticiones a base de datos, el problema termina hasta que estos datos son procesados para después ser mostrados al usuario. ¿Por qué debe de tener este proceso una rápida ejecución?

Este tipo de tarea es de uso cotidiano en este tipo de aplicaciones, un

producto que no logra un cierto grado de rendimiento requerido, esta imposibilitado para competir contra otros que si lo logran. La respuesta rápida viene a ser entonces el mayor de los requerimientos en estas aplicaciones. Este es el reto al cual vamos a someter a J2ME, intentar llegar a un grado de respuesta que sea comparable al que se ha logrado obtener en aplicaciones que utilizan otros lenguajes como C o C++.

El sistema que se desarrolló, implantaba el módulo de pedidos de una aplicación ya existente: NADRO4. Las principales operaciones que se llevan a cabo en este módulo son las siguientes:

• Búsqueda de un producto por nombre o por clave. • Levantamiento del pedido.

Cabe destacar que la base de datos de los productos sobrepasaba los

diez mil registros, fue ahí donde se centraron todos los esfuerzos ya que, se supuso que este sería uno de los grandes problemas en el desarrollo.

Las herramientas que utilizamos para realizar esta parte del proyecto fueron SQL y JDBC. SQL

Hasta comenzar el proyecto, nuestra experiencia en bases de datos era nulo, ya que nunca habíamos siquiera interactuado con programas que hicieran uso de ellas. Por tanto, lo que sabíamos de SQL y de su sintaxis era mínimo.

Como no contábamos con el suficiente tiempo para documentarnos o conseguir cursos completos de SQL, lo que hicimos fue buscar en la red manuales básicos y, conformarnos con comprender la sintaxis junto con las sentencias básicas de SQL. 4 NADRO: Sistema de punto de venta para farmacias con una cartera de mas de 10,000 productos.


13

JDBC

Este paquete es el encargado de la relación de Java con bases de datos. Aunque no conocíamos en si el funcionamiento de este paquete, como ya se mencionó anteriormente la documentación proporcionada por SUN hace que el manejo y la utilización de JDBC se hagan intuitivos una vez que ya se conoce el lenguaje de programación JAVA de manera general. 3.1 Transformación de la base de datos.

La base de datos con la que cuenta la aplicación NADRO, es un archivo de texto indexado, con lo cual, para poder utilizarlo desde una aplicación Java, se tuvo que realizar una conversión a la base de datos que se utilizaría.

Base de datos NADRO

Transformador

Base de datos en PointBase

Figura 6: Transformación de la base de datos Tener un archivo de texto indexado nos facilito mucho el trabajo ya que

solo consistió en leer línea por línea el archivo y después separar las partes de la cadena obtenida para obtener los valores que se requerían.

Suponiendo como ejemplo la siguiente línea: Los primeros diez

caracteres representan la clave, los siguientes 15 el precio y los últimos caracteres hasta el fin de cadena representan el nombre.

VRTRDSDFDF$40.00 ALCOHOL1LT

Clave Precio Nombre


14

La tarea realizada fue la siguiente:

1. Crear la base de datos que se utilizaría. 2. Leer una línea del archivo de texto. 3. Identificar y obtener los valores de acuerdo a los índices. 4. De acuerdo a los valores obtenidos agregar una nueva entrada a la base

de datos. 5. Repetir desde el paso 2 mientras no se llegue al final del archivo.

Al terminar lo que se obtuvo fue una base de datos con una tabla llamada Producto que tenía los siguientes elementos:

Producto

PrecioNombreClave

Figura 7: Tabla Producto

Esta base de datos ya es compatible con JDBC con lo cual ya podemos

acceder a ella a través de una aplicación Java.

Interfaz de usuario

La primera tarea que realizamos en esta parte del proyecto fue la de desarrollar la interfaz gráfica de usuario que emularía a la interfaz de NADRO. Dado que, desde la aplicación de comunicaciones FTP, se venían notando ligeros retrasos en la carga de pantallas que contenían una cantidad considerable de controles, supusimos que este problema se presentaría mas gravemente en esta aplicación ya que, revisando la aplicación Nadro, observamos que existían algunas pantallas en las que el numero de controles eran demasiados en comparación con los que hasta ahora había cargado a pantallas de nuestras aplicaciones.

Nuestra respuesta a este problema fue crear nuestros propios

componentes, en particular los botones, ya que estos son, por lo regular, los que mas se tienen en una ventana. Pero, además, son de fácil implementación ya que la única acción que nos interesa que genere un evento es el de clic sobre él.

Vamos a mostrar una aplicación de ejemplo utilizando el mismo

procedimiento que se siguió en las aplicaciones del proyecto en las cuales se dibujaron botones. Primero mostraremos como se realiza con los botones que nos proporciona el API AWT y después, la implementación con botones desarrollados por nosotros.


15

Los requerimientos de nuestra aplicación ejemplo serán los siguientes:

1. Se requiere una pantalla con 10 botones, cada uno con la etiqueta de un número entre el 0 y el 9.

2. Se dispone también de un área de texto en la cual, al presionar sobre alguno de los botones debe presentarse el siguiente mensaje: El botón presionado fue: <# del botón presionado>

3. Para hacer mas laboriosa la aplicación se tendrá también un botón de borrar el cual limpia el área de texto, y un botón de salir el cual termina la aplicación.

Utilizando componentes AWT Los pasos a seguir son los que comúnmente se realizan para cualquier

aplicación que solo utiliza componentes predefinidos. Los pasos son: crearlos, agregarlos y mostrarlos. Vamos a detallar estos pasos a continuación:

Declarando la clase: Public class ImplementarBotones extends Frame Extiende de Frame que es la clase principal de ventana para

componentes gráficos de AWT. Declarando los componentes que vamos a utilizar: private Panel panelBotones; private TextField txtMensajes; private Button [] botonesNumeros; private Button btnSalir, btnBorrar; El panel es el área en donde estarán alojados nuestros botones. El siguiente método inicializa la ventana que vamos a mostrar,

estableciendo las medidas y los componentes que contendrá. En lo particular nos interesa el método que agrega los botones: agregarBotones().

private void jbInit() throws Exception { setSize(new Dimension(200,200)); panelBotones = new Panel(new FlowLayout()); txtMensajes = new TextField(); txtMensajes.setEnabled(false); agregarBotones(); add(txtMensajes, BorderLayout.NORTH); add(panelBotones, BorderLayout.CENTER); }


16

Con este método agregamos los botones al panel de la manera como comúnmente se hace.

private void agregarBotones() {

Definiendo nuestros botones, como los botones de número realizan una acción muy parecida al presionarlos entonces se puede realizar un arreglo de botones.

this.botonesNumeros = new Button[10]; En este ciclo creamos los botones, establecemos su ActionListener y

lo agregamos al panel. for(int i = 0; i<10; i++) { botonesNumeros[i]=new Button(Integer.toString(i));

botonesNumeros[i].addActionListener(new ActnBtnNumero(this, Integer.toString(i)));

panelBotones.add(botonesNumeros[i]); } Los botones de borrar y salir los realizamos aparte ya que su

funcionalidad es diferente, pero como podemos ver los pasos a seguir son idénticos que con los otros botones: crear, establecer ActionListener y agregar.

btnBorrar = new Button("Borrar"); btnBorrar.addActionListener(new ActnBtnBorrar(this)); panelBotones.add(btnBorrar); btnSalir = new Button("Salir"); btnSalir.addActionListener(new ActnBtnSalir(this)); panelBotones.add(btnSalir); } Con estos pasos ya tenemos una ventana con los botones agregados tal

y como se muestra en la figura 8.

Figura 8 Aplicación de ejemplo con componentes AWT.


17

Lo único que nos falta ahora es definir la acción que va a realizar cada botón cuando sea presionado.

Los botones de número solo actualizan lo que se muestra en el área de texto. public void actnBtnNumero(ActionEvent e, String msj){ txtMensajes.setText("Se presiono el boton: "+msj); }

El botón de borrar solo limpia el área de texto. public void actnBtnBorrar(ActionEvent e){ txtMensajes.setText(""); }

El botón de salir termina la aplicación public void actnBtnSalir(ActionEvent e){ System.exit(0); }

Con esto terminamos la aplicación. Como se puede observar el

desarrollo es rápido y no es complicado, el precio que se paga es que mientras mas componentes se tengan mayor será el tiempo de carga de la ventana. En la figura 9 se muestran algunas ventanas de la aplicación es ejecución.

Figura 9 Ventas de la aplicación de ejemplo en ejecución. Dibujando nuestros propios botones.

Esta técnica la utilizamos para solventar el problema que se tenía con la carga de las ventanas. Consiste en tomar un componente (por lo regular un Panel) y modificar su aspecto para que dentro de el se simulen áreas que serán consideras como espacios de botones. La dificultad esta en como establecer las delimitaciones que tendrán estas áreas y cual será la respuesta del sistema a eventos que sucedan sobre esas áreas.


18

Área de boton

Área general

Figura 9 Solo en el espacio amarillo (área de botón) debe de registrarse una acción, en

cualquier otro lado no debe de pasar nada.

Declarando la clase: Public class ImplementarBotones2 extends Frame Al igual que la clase anterior, extiende de Frame que es la clase principal

de ventana para componentes gráficos de AWT. Declarando los componentes que vamos a utilizar: private PanelBotones panelBotones;

private TextField txtMensajes; En esta ocasión solo existe el área de texto y el panel. Ya no hay ningún botón, estos serán implementados dibujándolos en el panel de botones. En el método de inicialización ahora solo tenemos que agregar el panel, y registrar su MouseListener que será el encargado de capturar las acciones que se realizan sobre el panel. private void jbInit() throws Exception { setSize(new Dimension(200,200)); panelBotones = new PanelBotones(); panelBotones.addMouseListener(new AccionBotones(this)); txtMensajes = new TextField(); txtMensajes.setEnabled(false); add(txtMensajes, BorderLayout.NORTH); add(panelBotones, BorderLayout.CENTER); } Hasta este punto el desarrollo de las 2 aplicaciones parece idéntico. Pero a partir de aquí vamos a mostrar las diferencias. Comenzaremos por la clase PanelBotones, la cual extiende de la clase Panel. public class PanelBotones extends Panel Aquí es donde tenemos que comenzar a trabajar, para que esta clase se muestre en pantalla tal y como queremos tenemos que sobrescribir su método paint() que es el encargado de dibujar el componente.


19

public class PanelBotones extends Panel { public void paint(Graphics g){ int x, y; String [] etiqueta = {"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "C", "S"}; x = this.getWidth(); y = this.getHeight(); for (int i = 0; i < 3; i++) { for (int j = 0; j < 4; j++) { g.setColor(Color.YELLOW);

g.fillRect((2 * j * x / 9) + x / 9, (2 * i * y / 7) + y / 7, x / 9, y / 7);

g.setColor(Color.BLACK); g.drawRect((2 * j * x / 9) + x / 9, (2 * i * y / 7) + y / 7, x / 9, y / 7); g.drawString(etiqueta[(i * 4) + j], (2 * j * x / 9) + x / 9 + (x / 18),

(2 * i * y / 7) + y / 7 + (y / 10)); } } } }

Las etiquetas de los botones, todos los botones tendrán el mismo tamaño, así que tendremos que utilizar símbolos para representar el botón de borrar(C) y el de salir(S). String [] etiqueta = {"0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "C", "S"}; Tenemos que obtener el tamaño del componente ya que en base a estas medidas es como obtendremos los lugares en donde se tienen que dibujar los botones. Esto evita que si el componente cambia de tamaño, se distorsionen nuestros dibujos de los botones. x = this.getWidth(); y = this.getHeight(); En estos ciclos es en donde realizamos los dibujos, serán dibujados por fila y columna, por eso se necesitan 2 ciclos. for (int i = 0; i < 3; i++) { for (int j = 0; j < 4; j++) { g.setColor(Color.YELLOW);


20

g.fillRect((2 * j * x / 9) + x / 9, (2 * i * y / 7) + y / 7, x / 9, y / 7);

g.setColor(Color.BLACK); g.drawRect((2 * j * x / 9) + x / 9, (2 * i * y / 7) + y / 7, x / 9, y / 7); g.drawString(etiqueta[(i * 4) + j], (2 * j * x / 9) + x / 9 + (x / 18),

(2 * i * y / 7) + y / 7 + (y / 10)); } } }

Con este método establecemos el color que tendrá el botón, en este

caso será amarrillo. g.setColor(Color.YELLOW);

El método fillRect junto con drawRect se encargan de dibujar un rectángulo relleno en los puntos que se les indique. Como podemos ver la formula es un poco compleja y tiene que ver con el tamaño del componente(x,y), y de la fila y columna en la que se desea pintar(i,j). Usando este método, antes de comenzar a dibujar se debe de tener claro cuantas filas y cuantas columnas de botones se necesitan. En nuestro caso escogimos que hubiera 3 filas y 4 columnas. g.fillRect((2 * j * x / 9) + x / 9, (2 * i * y / 7) + y / 7, x / 9, y / 7); g.setColor(Color.BLACK); g.drawRect((2 * j * x / 9) + x / 9, (2 * i * y / 7) + y / 7, x / 9, y / 7); Ahora trataremos de poner en el centro de cada botón una etiqueta para simular el nombre que tienen los botones. g.drawString(etiqueta[(i * 4) + j], (2 * j * x / 9) + x / 9 + (x / 18),(2 * i * y / 7) + y / 7 + (y / 10)); Igual que el anterior, calcular la posición de la etiqueta tiene que ver con el tamaño del componente, la fila y la columna.


21

El panel que se obtiene tiene la forma siguiente:

Figura 10 Panel con botones dibujados

No es igual de vistoso que el panel con botones de AWT pero cumple con los requerimientos que se solicitan.

Pero hasta este momento, el panel que hemos realizado, es solo un dibujo ya que aun no tiene registrada la acción de presionar un botón. En este caso, se procede implementando el MouseListener del panel y separando las áreas para que se realice la operación correcta. Esto se realiza en el método accionBotones. public void accionBotones(MouseEvent e) { int x, y, xPanel, yPanel, numeroAccion = -1; x = e.getX(); y = e.getY(); xPanel = panelBotones.getWidth(); yPanel = panelBotones.getHeight(); for (int i = 0; i < 3; i++) { for (int j = 0; j < 4; j++) { if ( x > (2 * j * xPanel / 9) + xPanel / 9 &&

x < (2 * j * xPanel / 9) + (2 * xPanel / 9) && y > (2 * i * yPanel / 7) + yPanel / 7 && y < (2 * i * yPanel / 7) + (2 * yPanel / 7)) { numeroAccion = i * 4 + j; break; } } } if( numeroAccion >= 0 && numeroAccion <10) {

this.txtMensajes.setText("Se presiono el boton: " + numeroAccion);

}else if( numeroAccion == 10) { this.txtMensajes.setText(""); }else if (numeroAccion == 11)


22

{ System.exit(0); } }

Utilizando las coordenadas del lugar en donde se realizo el click con el putero obtenemos un número de acción con el cual podemos saber que botón debe de responder o si el click se dio fuera de todos los botones. if ( x > (2 * j * xPanel / 9) + xPanel / 9 && x < (2 * j * xPanel / 9) + (2 * xPanel / 9) && y > (2 * i * yPanel / 7) + yPanel / 7 && y < (2 * i * yPanel / 7) + (2 * yPanel / 7)) {

numeroAccion = i * 4 + j; break;

} Al igual que en la clase PanelBotones, el calculo de las coordenadas

es complicado y se ven involucradas las variables tamaño, columna, renglón, y las coordenadas del clic del puntero.

Ahora solo falta indicar cual es la rutina que se realizará de acuerdo al número de acción obtenido.

if( numeroAccion >= 0 && numeroAccion <10) {

this.txtMensajes.setText("Se presiono el boton: " + numeroAccion);

}else if( numeroAccion == 10) { this.txtMensajes.setText(""); }else if (numeroAccion == 11) { System.exit(0); } Con esto terminamos la aplicación utilizando botones dibujados, en la

figura 11 podemos apreciar la aplicación en ejecución.

Figura 11 Aplicación con botones dibujados.


23

Con esta sencilla aplicación mostramos cual fue nuestra respuesta al problema de la sobrecarga de pantallas. Aunque el resultado no es muy vistoso, el tiempo de carga es muy rápido lo cual nos hace inclinarnos por esta solución.

Figura 12 Comparación visual de las 2 soluciones.

3.3 Búsqueda en la base de datos

El último problema al que nos enfrentamos en el proyecto. Lograr el máximo performance en una búsqueda a una base de datos con más de diez mil registros. Aunque este objetivo no se pudo concluir totalmente por falta de tiempo, se explicará aquí los problemas iniciales y las soluciones que se dieron.

Como ya se ha mencionado, el acceso a base de datos fue, por todas

las razones ya descritas lo mas difícil y tardado de realizar. Una vez que se resolvieron los problemas de la interfase de usuario, empezamos a darle funcionalidad. En especial nos centramos en la ventana de búsqueda la cual es la que esta directamente asociada con el problema de velocidad de respuesta. En ella se tiene la necesidad de acceder a la base de datos y realizar consultas. A continuación mostraremos cual es la funcionalidad requerida para esta parte del desarrollo (Fig. 13).


24

1.Busqueda capturando nombre óID de producto 2.Busqueda utilizando un

teclado auxiliar

3.Botones Arriba(UP)Abajo(DN)

Para desplazarse porlos productos

Figura 13 Esta es una de las partes del desarrollo mas importante ya que es en esta ventana en donde se realizan las búsquedas de productos de distintas maneras.

1. Búsqueda capturando nombre del producto.

Se dispone de un área de texto en la cual el usuario puede teclear el nombre ó la clave de producto. A partir de los caracteres que se vayan introduciendo el área de búsqueda de productos debe de irse modificando mostrando solo los productos que coincidan con lo que hasta el momento ha introducido el usuario. Mientras mas caracteres se introduzcan menos productos deben de mostrarse hasta llegar al punto en que lo introducido por el usuario solo coincida con un producto. Por ejemplo: si se escribe una letra ‘a’, la lista se tiene que actualizar a todos los productos que comiencen con la letra a. Así sucesivamente hasta que en el área de texto se tenga el nombre de algún producto y la búsqueda solo tenga una posible respuesta. Si el usuario introduce una secuencia de caracteres que no coincide con ningún producto, entonces en el área no se deben de mostrar productos. 2. Búsqueda utilizando teclado.

La aplicación dispone de un teclado para ayudar a realizar la búsqueda (Fig. 14). En esta pantalla el usuario presiona una secuencia de caracteres por medio de los botones que se tienen. En el área de texto debe de irse presentando el producto que mas coincida con lo que se ha introducido. Si el producto que se muestra es el mismo que el cliente que esta buscando entonces puede presionar el botón aceptar (>) y el sistema debe de regresar a la pantalla principal mostrando como selección el producto que selecciono el cliente.


25

Figura 14 Pantalla de teclado para realizar búsqueda de productos

3. Botones de desplazamiento.

La aplicación cuenta también con botones para desplazarse por toda la cartera de productos.

Aunque parecen distintas funciones, al final todas realizan una búsqueda a

la base de datos de acuerdo a los nombres de productos que vayan coincidiendo con lo que el usuario ingresa. Entonces para nosotros el problema central fue realizar una búsqueda a base de datos que nos arrojara este tipo de resultados. Los problemas y las soluciones que tratamos de dar a esta parte del proyecto se describen en la sección siguiente.

3.4 Soluciones a la búsqueda

En lo primero que se centro los esfuerzos fue en la parte de la búsqueda por medio del área de texto ya que supusimos que esa seria la parte más difícil. Solución básica

La primera propuesta que implantamos fue realizar una consulta a la base de datos trayendo todo el contenido de una tabla por medio de un objeto.

Esta consulta se realizo utilizando la sentencia “LIKE” de SQL la cual se puede utilizar para obtener todos los productos que coincidan con el o los caracteres que se asocian al LIKE.

Como al principio no se contaba con la base de datos completa, las

pruebas de este procedimiento se hicieron con una base de datos realizada por nosotros en la que, a lo más, se tenían 250 productos.


26

Con este número de productos esta solución se comportaba muy bien, lo

cual nos hizo suponer erróneamente que así se seguiría comportando aun aumentando el número de registros.

Al tener en la mano la base de datos real, esta solución dejo de ser buena, y empezó a comportarse realmente mal. Cada búsqueda se torno lenta al tardarse alrededor de 2 minutos en completarse. Esto hizo que se buscara otra solución ya que esta en definitiva no nos funciono.

Búsquedas selectivas eliminando LIKE

Otra solución que se implemento y en la que invertimos mucho tiempo fue programar búsquedas muy selectivas sin utilizar la sentencia LIKE. Estas búsquedas se implementaron con sentencias de SQL verdaderamente rebuscadas y ciclos for o while dentro del código (Fig. 14).

Esta forma de búsqueda mejoro en mucho los resultados obtenidos con

la solución básica. Aunque aun los tiempos de respuesta de la búsqueda aun no eran lo “bastante” buenos para la aplicación, La reducción de tiempos fu verdaderamente notoria ya que paso de los 2 minutos que se tenían a búsquedas de alrededor de 1-5 segundos. Estos resultados nos hacen pensar que tal vez con algoritmos de búsqueda más complejos tal vez se pueda llegar a un tiempo de respuesta óptimo para cada búsqueda.


27

Figura 14: Fragmento de código en el que se muestra lo compleja que fue la programación de esta búsqueda.

Solución dinámica

Una solución completamente diferente hasta las ahora intentadas fue hacer

uso de las clases de utilidad de JAVA: “ArrayList”. Lo que se nos ocurrió fue realizar una sola petición a la base de datos la cual trajera todos los productos que se encuentran en el catalogo.

Después de realizar la petición, ya se tiene cargados en memoria todos los

productos y, los algoritmos de búsqueda que se programaron anteriormente se pueden seguir utilizando solo con ligeras modificaciones. Cabe aclarar que una vez que se tienen cargados los productos, los tiempos de búsqueda son en definitiva los mejores que obtuvimos en todo el proyecto.

Aunque al principio supusimos que ese número de elementos saturaría la

memoria de la Pocket PC, esto no fue así ya que el sistema no presento ninguna lentitud.

El único inconveniente fue que el tiempo de carga de toda la base de datos

en memoria consumía demasiado tiempo. En la primera prueba que se realizo con este método el tiempo de carga fue desalentador: 25 mins. Este tiempo en definitiva hizo que pensáramos en dejar a un lado esta solución.


28

Solución dinámica + búsquedas selectivas

De lo que se trataba ahora era de tratar de mejorar al máximo el tiempo de carga de la base de datos. Una de las acciones que se propusieron, y la que dio mejores resultados hasta el momento, fue hacer una mezcla de la solución dinámica junto con los algoritmos que ya se habían desarrollado de búsquedas selectivas.

Esta solución se puede describir de la siguiente manera: En vez de tratar

de traernos todos los registros con una sola sentencia SQL (SELECT * FROM TABLA), optamos por utilizar sentencias que trajeran la base de datos por pedazos pequeños. Al final el resultado seria el mismo, todos los productos cargados en memoria.

Aunque los algoritmos que quedan al final de esta implementación son

difíciles de entender, los resultados que arrojaron fueron la mejor solución que se pudo obtener.

Al final, se pudo reducir el tiempo de la carga de los registros a un tiempo

mucho mejor que al que se obtuvo en la primera prueba (30 m.). El tiempo que logramos con esta opción fue de 30-50 s. Propuestas de soluciones

Por falta de tiempo la implementación de estas propuestas no se llevo a cabo pero las queremos mencionar.

• Threads: Programar la carga de la base de datos en un thread

diferente del thread principal con lo cual esperamos que mientras el sistema esta ocupado realizando otras tareas, el thread de carga de datos termine su trabajo resultando en un proceso transparente a las otras partes del sistema.

• Una solución drástica que se puede proponer es cambiar de base de datos. Hasta el momento hemos descrito todas las técnicas que utilizamos. Y pensamos que este software se “exprimió” al máximo con lo cual, si no se esta a gusto con los resultados hasta ahora obtenidos, el cambio de base de datos puede dejar de ser una solución trivial.


29

Pedidos

Lo último que nos falta describir es la interfase de usuario para levantar un pedido. En ella se tiene una cartera de clientes a los cuales se les puede agregar un pedido, cancelar o modificar uno que se haya echo con anterioridad. Esta parte no presentó un grado de dificultad para implementar alto, ya que todo es realizar una secuencia de pantallas. La funcionalidad principal como ya se ha dicho anteriormente es la pantalla de búsqueda. A continuación mostraremos las pantallas principales y una breve descripción de su funcionamiento. Pantallas Principales

En este menú se puede seleccionar un cliente de la lista y pasa al menú principal del Cliente.

Aquí se muestran las opciones que tiene disponible cada cliente: levantar un pedido o eliminar pedido.


30

Si el cliente cuenta con pedidos anteriores el sistema despliega la cantidad de productos que ha pedido, de lo contrario pasa directamente al menú principal de búsqueda.

En este menú se realizan operaciones como son: búsqueda de productos, mostrar detalle de productos y agregar productos al pedido.

Esta pantalla muestra en detalle datos del producto como son: la clave, el nombre, su precio al cliente y el precio máximo al público.


31

Esta pantalla se pueden realizar operaciones como son: consultar datos detallados de cada producto, modificar la cantidad de unidades adquiridas, eliminar productos del pedido, agregar más productos al pedido y generar el pedido.

Esta pantalla se puede modifica la cantidad de unidades de un producto de la lista de productos capturados.


32

CAPITULO 4: RESUMEN FINAL

La finalidad de este proyecto es la de hacer un análisis de J2ME y junto con ello el desarrollo para dispositivos móviles, el cual es un mercado que apenas esta comenzando a descubrirse.

El reto principal de J2ME es enfrentarse a un mercado con innovaciones

tecnológicas muy rápidas, con los que, fijar estándares como se ha hecho con sus hermanos mayores (J2SE, J2EE) y que tan buenos resultados ha dado, se vuelve muy complicado ya que no queda tiempo para tratar de unificar criterios por parte de los productores de hardware de este sector. De todas maneras los productores saben, porque lo han visto en el mundo Web, que la estandarización y las asociaciones tienen sus beneficios. Ponerse de acuerdo ha sido, creemos, uno de los motivos principales de la lentitud de desarrollo del mundo J2ME. Pero todo nos hace pensar que el futuro de J2ME es prometedor, las limitaciones de recursos han pasado a segundo término, y ahora solo falta consolidar la especificación y dotarla de la flexibilidad que este mercado requiere. Las aplicaciones que en este proyecto se realizaron así lo demuestran. La velocidad y la facilidad de desarrollo que se alcanzó son muy buenas tomando en cuenta que al inicio del proyecto no se tenía ninguna experiencia con J2ME. Tal vez, aun haya algunas cuestiones que se necesiten pulir para que esta tecnología, sea la mejor candidata para ser tomada en cuenta en desarrollos de alta demanda, pero se sigue trabajando para optimizarla. Así lo demuestra SUN que en estos momentos se encuentra definiendo lo que será la nueva especificación de J2ME, ya que, la especificación con la que se realizó este proyecto, ha entrado en su ciclo de EOL (End Of Life), para dar entrada a las nuevas especificaciones que vendrán a suplantarla y esperemos, a mejorarla. Creemos que el auge de este mercado aún no ha llegado, y que uno de los principales protagonistas de este auge será Java.

REPORTE DEL PROYECTO DE INGENIERIA ELECTRONICA

Documents

Transcript of REPORTE DEL PROYECTO DE INGENIERIA ELECTRONICA