sábado, 21 de agosto de 2010

Parte 3.- Java Me Basico

Bien ahora pasemos a un pequeño tutorial de java me para móviles y posiblemente ahora se haga la pregunta ¿Y por que java me? ¿Hay otras formas de programar en móviles como con HTML 5 y php?.

Bueno con java podemos modelar un diseño de clases hacer modelos de testing, es decir poder hacer desde una aplicación sencilla hasta una compleja usando diferentes metodologías y técnicas, y si podemos hacer una pagina y que se vea en un browser pero pues al ser una pagina web se debe renderizar siempre o bien tratar de usar ajax para lo mismo, es decir lidiar con la interfase del sistema cuando en realidad deberíamos concentrarnos en el negocio, también el usar una aplicación web no es offline como una aplicación nativa, o bien tratar de usar Widgets con HTML y java script pero no es algo que se modele a raiz de una clase ahí ya es programación estructurada.

Los Widgets son pequeñas aplicaciones de web independientes que puedes instalar y usar en tu teléfono. Esas aplicaciones ofrecen las funciones específicas y frecuentemente usadas, como pronósticos del tiempo o noticias en la Internet. Para usar los Widgets, tu aparato debe tener el soporte necesario.

Las aplicaciones nativas permiten una manipulación de APIS de manera nativa y directa.

En realidad me parece que depende del objetivo de la aplicación como se puede diseñar, por ejemplo si es informativa igual y es con Html 5 o bien con un Widget, pero si es de un proceso de negocio complejo como ventas, con Gps, e imprime y cobra con tarjeta como que es mejor con algo nativo como java igual tomar en cuenta el crecimiento de la aplicación.
En resumen pueden ser de 3 tipos los desarrollos móviles y depende de el enfoque del negocio lo que deberíamos usar, posteriormente se mostraran mas información de otras tecnologías:
  • Nativas.
  • Widgets.
  • Html 5 
Algunas tecnologías móviles y herramientas comunes pueden ser:  
  • Java ME, Netbeans y Eclipse.
  • Blackberry con Java ME y Java nativo de blackberry, Visual Studio(plugin) y Widgets.
  • Iphone con cocoa y monotouch(c#).
  • Android con Motodev, Eclipse y proximanente Monodroid(c#).
  • Widgets java script y html con Aptana.
  • Phone gap con java script, multiplataforma.
  • Windows Phone con Silverlight y Expression.
  • Windows Mobile(Descontinuado ahora es el Windows Phone)

Mi recomendación es siempre conocer y revisar las necesidades del cliente, crecimiento y no enfocarse en una moda o lo que nos parece que es lo más sencillo pero es muy limitado en cuanto al crecimiento a veces lo barato sale caro.

1) Tipos de Aplicaciones.

Pago único. Se hace un único pago y no hay problema de gestionar licencias.
Renta. Acá se pone énfasis en tener el control y poder gestionar las licencias y pagos cada cierto tiempo, mediante un sistema de gestión de licencias.
Patrocinio. Acá se pone énfasis en poder gestionar contenido de publicidad como puede ser imágenes o videos.

2) Características de móviles.

Uso de envío de datos a través de la red del Carrier.
Manejo de Web services.
Manejo de Web client.
Manejo de Sockets.
Uso de envío de datos a través de WiFi.
Uso del GPS.
Uso de los mapas.
Uso de la cámara.
Uso de la multimedia para reproducir video.
Uso de la multimedia para reproducir música.
Uso de la multimedia para grabar video.
Uso de la multimedia para grabar música.
Uso del envío/recepción de sms.
Uso del envío/recepción de msm.
Uso del envío/recepción de mail.
Uso del envío/recepción de pin.
Uso del teléfono para hacer una llamada o recibirla.
Almacenamiento de datos usando SQL Lite si lo permite u algun otro metodo.
Uso de periféricos externos:
Código de barra.
Impresoras.
Lector de tarjeta de cobro.

3) Java 2 ME.

J2ME es la plataforma para el desarrollo de aplicaciones móviles.
Existen dos tipos de aplicaciones en J2ME las CDLC y las MIDP
Las aplicaciones CDLC es concebido como una base para otras plataformas como MIDP. Su funcionalidad es escasa
Las aplicaciones MIDP (Mobile Information Device Profile) cuenta con una mayor funcionalidad y puede ser utilizado en prácticamente cualquier PDA

4) MIDlet.

Este paquete permite a las aplicaciones MIDP (midlets) interactuar con el entorno, sobre el cual la aplicación se está ejecutando.
Un midlet siempre heredará de la clase javax.microedition.midlet.MIDlet
Las aplicaciones MIDP deben contar con al menos un MIDlet.

5) Ciclo de vida de un midlet.

Cuando un MIDlet se termina de cargar el estado que toma es el pausado.
Ya que se inicializa el MIDlet este pasa al estado activo.
El MIDlet puede pasar del estado activo al pausado a través de sus propios métodos o que el sistema operativo lo pause para responder a una llamada.
El MIDlet puede ser destruido independientemente de su estado activo o pausado.

6) Metodos de un MIDlet.

Las clases que heredan de javax.microedition.midlet.MIDlet deben implementar los tres métodos abstractos que tiene la clase MIDlet
startApp
pauseApp
destroyApp
Estos métodos pueden ser declarados como protected o como public si van a ser llamados desde otro elemento.

7) startApp()

Este método cambia el estado del MIDlet a activo.
Definición:
protected abstract void startApp ()
Un MIDlet inicia su carga con el constructor y de no haber un error pasa al estado pausado.
Con este método se inicia la ejecución del MIDlet hasta que regrese al estado pausado o destruido.

8) pauseApp()

Cambia el estado del MIDlet a pausado
Sintaxis: protected abstract void pauseApp ()
Guarda la información del estado actual de nuestra aplicación y libera los recursos que ella pudiera estar ocupando.
Al reactivarse nuestra aplicación se llama al método startApp.
Nota: es muy recomendable que en el método startApp pueda distinguir cuando es ejecutado por primera vez, de las veces que es reanudado el sistema.

9) destroyApp()

Es el método al cual se llama cuando la aplicación debe terminar.
Sintaxis:
protected abstract void destroyApp (boolean unconditional)
Este método cambia el estado del MIDlet a destruido.
El MIDlet puede pedir que no quiere entrar en el estado Destruido lanzando una excepción MIDletStateChangeException. Lo cual evita que la aplicación no termine. Para concluir con la aplicación, ignorando cualquier excepción que se diere durante la ejecución de este método; establecemos a true el parámetro unconditional.

10) Otros metodos.

Existen otros tres métodos para el cambio de estado de un MIDlet.
El llamado a cualquiera de ellos no causa la ejecución de los métodos que anteriormente fueron descritos.
Estos métodos son:
public void notiyPaused ();
public void notiyDestroyed ();
public void resumeRequest ();
Para cambiar al estado de pausado, destruido y activo respectivamente.

11) Ejemplo de un MIDlet.

//Usamos la clase MIDlet
import javax.microedition.midlet.*;
//Nuestra clase debe de heredar de la clase MIDlet
public class MiMIDletEjemplo extends MIDlet
{
  //Constructor
  public Ejemplo1( )
  { }

  //Método que se llama cuando pasamos de Pausado a Activo
  protected void startApp( )
  { }

  //Método que se llama cuando pasamos de Activo a Pausado
  protected void pauseApp( )
  { }

  //Método que se llama cuando se destruye el midlet
  protected void destroyApp(boolean incondicional)
  { }
}

12) Display.

Representa el controlador lógico de la pantalla del dispositivo, donde el Midlet colocará su interfaz.
El objeto Display no se crea, se obtiene con el método getDisplay().
Por cada MIDlet sólo existe una instancia del objeto Display.
Sólo un MIDlet podrá tener el control de la pantalla.
El método getDisplay, generalmente, se ejecuta una vez y se guarda la referencia del objeto Display.
public static Display getDisplay (MIDlet midlet);

13) Metodos de Display.

Los métodos más usados del objeto Display son:
Displayable = getCurrent(); Retorna el objeto Displayable que actualmente se muestra en pantalla para dicha aplicación Midlet.
Display = getDisplay(MIDlet m); Obtiene la instancia del objeto Display.
Boolean = isColor(); Indica si el Display del dispositivo soporta colores.
Int = numColors(); Regresa el número de colores que el dispodivo soporta.
Void = setCurrent(Alert alert, Displayable nextDisplayable); Muestra un objeto Alert y el objeto Displayable cuando el objeto Alert desaparezca.
Void = setCurrent(Displayable nextDisplayable); Establece el objeto Displayable en el Display. Muestra el objeto Displayable en la pantalla.
Boolean = vibrate(int duration); Solicita la operación de vibrar al dispositivo.

14) Objeto Displayable.

Este tipo de objetos contiene la información que va a ser visualizada.
Exiten dos tipos de objetos Displayable
Screen – Clase base para utilizar el API de alto nivel del interfaz de usuario.
Canvas – Estructuras que pueden acceder a eventos de bajo nivel.

15) Tipos de screen.

Existen dos tipos de Screen:
Screen con estructura predefinida: Alert, List y TextBox, que encapsulan componentes de interfaz complejos y que las aplicaciones no pueden enriquecer con nuevos componentes.
Screen genérica: Form, las aplicaciones pueden llenar este tipo de pantalla con texto, imágenes u otros componentes de interfaz de usuario.

16) Objeto Alert.

Esta clase permite mostrar un mensaje (y opcionalmente una imagen) al usuario.
Es como un pop-up o un MessageDialog.
Los constructores de la clase Alert son:
public Alert(String title);
public Alert(String title, String alertText, Image alertImage, AlertType alertType);
Por defecto el tiempo que permanece un Alert en pantalla está determinado por el dispositivo o puede ser cambiado usando el método setTimeout() que especifica el tiempo en milisegundos (o usando la constante Alert.FOREVER)

17) Objeto List.

Esta clase hereda de Screen.
Con ella podemos mostrar una lista de opciones seleccionables.
Existen tres tipos de selección en un List:
EXCLUSIVE – Cada elemento de la lista cuenta con una opción de selección. Cuando el usuario selecciona un elemento, el elemento anteriormente seleccionado deja de estarlo.
MULTIPLE – Cada elemento de la lista cuenta con un cuadro de selección, el usuario puede marcar cuantos elementos desee.
IMPLICIT – Este tipo de selección es parecida a la EXCLUSIVE en el sentido que sólo un elemento puede ser seleccionado. Pero su selección es automática con tan sólo poner el foco en el elemento.

18) Constructores de List.

El objeto List cuenta con los siguientes constructores:
List(String title, int listType)
List(String title, int listType, String[] stringElements, Image[] imageElements)
El objeto List tiene un comando por defecto (SelectCommand), el cual sirve para cuando deseamos seleccionar un elemento de la lista y sólo se activa si la lista cuenta con al menos un elemento.

19) Commands.

Los commands son constructores que encapsulan la semántica de una acción.
Para crear un comando iniciamos con la declaración de una variable de tipo command
Command exitCommand;
Creamos la instancia:
exitCommand = new Command("Salir", Command.EXIT,2);
Los parámetros que se pasan al momento de crear la instancia son:
Título o etiqueta del command
Tipo del Command
Prioridad del Command

20) Tipos de Commands.

OK – Confirma una selección
CANCEL – Cancela la acción actual
BACK – Traslada al usuario a la pantalla anterior
STOP – Detiene una operación
HELP – Muestra una ayuda
SCREEN – Tipo genérico para uso del programador referente a la pantalla actual
ITEM – Tipo genérico para uso del programador referente a un elemento de la pantalla actual

21) Listener de comandos.
Para agregar un Command a un objeto Screen:
screen.addCommand(exitCommand);
Finalmente, para poner al objeto Screen a la “Escucha” de la selección de los comandos, ejecutamos el método setCommandListener.
screen.setCommandListener(this);

22) CommandListener.

Todo Screen que vaya usar Commands requiere de la implementación de la interfaz CommandListener.
public class HelloWorld extends MIDlet implements CommandListener
Al impletar dicha interfaz debemos redefinir el método commandAction.

public void commandAction(Command c, Displayable s)
{
  // Salir
  if (c == exitCommand)
 {
    destroyApp(false);
    notifyDestroyed();
  }
}

23) La clase Form.

La clase Form es una subclase de Screen, que contiene un número arbitrario de Items, como imágenes, texto y listas de selección.
La clase Form tiene dos constructores:
Form(String title)
Form(String title, Items[] items)
El número de Items que se encuentran contenidos en un Form se obtiene ejecutando el método size() de la forma.

24) Metodos para manejar los items de un form.

int append(Image img)
int append(Item item)
int append(String str)
void delete(int itemNum)
void insert(int itemNum, Item item)
void set(int itemNum, Item item)
Item get(int itemNum)
void deleteAll()

25) Clase Item.

Es la superclase usada por todos los componentes que pueden formar parte de un Form.
La clase Item es una clase abstracta por lo que sólo puede ser instanciada a través de sus clases derivadas.
Todos los ítem tiene un campo label o etiqueta, que es una cadena que va con el ítem.
Para ver y poner esta etiqueta tenemos dos métodos:
public void setLabel(String label)
public String get Label()

Parte 2.- EL Testing

Aca se presenta un poco de información hacerca de los test y tratar de hacer conciencia de probar las cosas de manera adecuada.

1) Definiciones - Testing.

Según IEEE standards 1999. “El testing de software es el proceso de analizar un producto de software para detectar las diferencias entre el comportamiento real y el pretendido, y para evaluar las funcionalidades y características no funcionales del software”

2) ¿Por qué es necesario el testing?
  • Identificar fallos
  • Reducir defectos en producción
  • Mejorar la calidad de la aplicación de los usuarios
  • Incrementar la fiabilidad
  • Para asegurar que los fallos no impactan a los costes y a la rentabilidad
  • Para asegurar que los requisitos son satisfechos
  • Para asegurar que los requisitos legales son conocidos
  • Proveer una medida de calidad 
3) El gran axioma del testing.

Axioma: “El Testing sólo puede mostrar la presencia de defectos, no su ausencia” (Dijkstra).

Corolario: Un test sólo es exitoso si encuentra errores.

4) Conceptos: Casos vs datos de test.
  • Casos de test: descripciones de condiciones o situaciones a testear.
  • Según IEEE standards 1999: “Es un conjunto de condiciones de ejecución sobre los valores de entrada y resultados esperados generadas para satisfacer un objetivo particular”
  • Crear casos de test es un proceso creativo.
  • Datos de test: lotes de datos necesarios para ejecutar un caso de test.
  • Crear datos de test es muy laborioso... Y poco creativo.
5) Casos de test.
  • Lo ideal sería probar el programa en todas las situaciones posibles
  • Una de las mayores dificultades es encontrar un conjunto de tests adecuado:
  • Suficientemente grande para abarcar el dominio y maximizar la probabilidad de encontrar errores
  • Suficientemente pequeño para poder ejecutar el proceso de testing con cada elemento del conjunto y minimizar el costo del testing  
6) Equipo de trabajo.

Líder de proyecto
  • Definición de la estrategia de testing
  • Elaboración del plan
  • Control del proyecto
  • Interacción con el cliente
Tester Diseñador
  • Definición de los casos de prueba
  • Poblado de las condiciones de prueba
Tester ejecutor
  • Ejecución de los casos de prueba
  • Detección y registro de incidentes
7) Testing de Unidades.
  • Se trata de probar módulos sueltos
  • Fase informal previa:
  • Ejecutar pequeños ejemplos
  • Hay herramientas que analizan automáticamente la sintaxis de los programas (¡e incluso “opinan” sobre fuentes potenciales de error!)
  • Fase de prueba sistemática:
  • Pruebas de caja blanca (o transparente): Se mira con lupa la estructura del código escrito
  • Pruebas de caja negra: Se prueba la funcionalidad del módulo sin atender a su contenido 
8) Testing de Integración.
  • Involucran varios módulos
  • Pueden ser estructurales o funcionales
  • Estructurales: como las de caja blanca, pero analizando llamadas entre módulos
  • Funcionales: como las de caja negra, pero comprobando funcionalidades conjuntas
  • Se siguen utilizando clases de equivalencia y análisis de valores frontera
  • Las pruebas finales consideran todo el sistema, cubriendo plenamente la especificación de requisitos del usuario
9) Testing del Sistema.

Realiza una batería de pruebas completa del sistema para tener información fiable de que el software cumple los requerimientos de prestaciones y funcionales solicitados.
Ejemplos:
  • Pruebas de Desempeño
  • Pruebas de Carga
  • Pruebas de Stress
10) Testing de regresión.
  • Repetir las pruebas tras cada modificación
  • Repetir sólo pruebas de verificación
  • Pruebas de unidades
  • Pruebas de integración
  • Conservar y actualizar los programas de prueba  
11) Plan de Testing.

Es un conjunto de pruebas
Cada prueba debe:
  • Dejar claro qué tipo de propiedades se quieren probar
  • Dejar claro cómo se mide el resultado
  • Especificar en qué consiste la prueba
  • Definir cuál es el resultado que se espera
  • Las pruebas “angelicales” carecen de utilidad 
12) TDD (Desarrollo guiado por pruebas, o Test-driven development).

Es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En Primer Lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

14) Metodologías basados en pruebas.

TDD

DDD

BDD

Se puede encontrar mas información de estos temas en las VAN de Alt Net Hispano, en donde se han tratado y mostrado ejemplos de los mismos.

Parte 1 - Conceptos generales

A continuacion se presentan un curso de formación de programacion en java para moviles, si bien se basa en java me, en el curso de formación tambien se adentra dentro del mundo de la calidad y estandarización para tener un estandar en el desarrollo, tambien se omite la parte del uml puesto que se pueden documentar en muchos lugares con esa información.

1) Conceptos generales.

  • Estándares. Son normas y protocolos internacionales que deben cumplir productos de cualquier índole para su distribución y consumo por el cliente final.

  • Calidad. Herramienta básica para una propiedad inherente de cualquier cosa que permite que esta sea comparada con cualquier otra de su misma especie.

  • Normas. Es un documento, establecido por consenso y aprobado por un organismo reconocido (nacional o internacional), que proporciona para un uso común y repetido, una serie de reglas, directrices o características para las actividades de calidad o sus resultados, con el fin de conseguir un grado óptimo de orden en el contexto de la calidad.

  • Metodología. Forma de organización y trabajo en equipo, como puede ser XP, Scrum, RUP.
2) Objetivos a cumplir en el desarrollo.

  • Reutilización de código o artefactos, al encapsular distintos componentes se pueden reutilizar en posteriores desarrollos, agilizando el tiempo de desarrollo y de mantenimiento.

  • Rapidez en el desarrollo, el uso de librerías base y métodos que maximicen la productividad y tiempos de respuesta. 

  • Calidad, el tener inspecciones así como normas asegura el desarrollo en base a un estándar lo que facilita el mantenimiento y la comprensión del sistema aun que hallan diferentes programadores.

  • Los anteriores puntos se alcanzan con las siguientes herramientas.

  • Uso de estándares de codificación (notaciones, documentación del código, herramientas a usar).

  • Uso de refactorización, y el uso de librerías. En una clase no puede haber código repetido, se debe buscar la refactorización, si es usado en más de una clase o bien más de un proyecto se encapsula en una librería.

  • Desarrollo en capas desacopladas.

  • El uso de inspecciones se refiere al echo de verificar periódicamente que se cumpla con los estándares no se hace un testing el cual se hace al fin de un modulo sino se busca que el producto cumpla con los estándares de programación, se busca mantener separado la inspección del testing para que no impacte al desarrollo al trabajar en parejas se busca que las inspecciones y los testing sean entre los elementos de los equipos, obviamente al hacer un testing se hace una inspección rápida pero ya con la certeza de que el código cumple un estándar.

  • Uso de documentos y checklist usados en todo el proceso para ir validando el proceso de desarrollo y testing.

  • Un modelo en espiral es mas dinámico y cambiante que uno en cascada, en cada ciclo se hace una retroalimentación y cambio principalmente en la parte de diseño de la aplicación y la interfaz de usuario, lo que se busca es el producto final sea lo que necesita el cliente para automatizar sus procesos además de cumplir con los lineamientos de usabilidad.

  • Los objetivos fundamentales son: la aplicación debe dar el resultado esperado por el cliente y debe de funcionar sin errores. 
3) Objetivos a cumplir hacia el cliente, ¿Qué espera un cliente?

  • Como empresa de desarrollo de software el objetivo es automatizar procesos y evitar duplicidad de tareas, por ejemplo automatizar una nomina, y evitar que el trabajador y el contador lleven cuenta de lo mismo, agilizando el proceso y descargando de funciones que no corresponden a diferente personal. 

  • Cumplir con los constraints (requerimientos) especificados del cliente, mismos que deben estar por escrito, los cambios deben ser notificados y aprobados para poder ser ejecutados.
4) Proceso de desarrollo por versión.

  • Análisis: obtención del domino de los procesos de los clientes a través de entrevistas, reuniones, cuestionarios (usando formatos para recavar información), así como definir requerimientos y especificaciones, si un cliente pide un elefante rosa en su sistema, debe llevar ese requisito, ni mas ni menos. 

  • Diseño: Diseño y modelado del sistema con UML.

  • Programación: En base a un diseño se procede a programar el sistema.

  • Implementación: Una vez que se ha revisado que no tenga errores y cumpla con los requisitos, se procede a implementar, capacitar y revisar que el sistema funcione y sea usado en la empresa.

  • Mantenimiento: Es la fase en la cual se da mantenimiento a posibles Bugs y adecuaciones de los clientes.
5) Generalizando.
  • La idea de la estandarización es análoga a la ISO 9000.
  • La idea básica de la ISO es que en un macroproceso tienes mini procesos y que estos deben tener conexión entre si y si todo el macroproceso funciona siempre de la misma manera sin desviación, obtienes siempre el mismo resultado.
  • Las normas más importantes en el software son:
  • CMMI.
  • ISO.
  • Moprosoft (norma mexicana).

6) Análisis y diseño. 
  • La documentación minima para tener un sistema es el diagrama de la base de datos, e nuestro caso usamos siempre como herramienta el Erwin data modeler, por su capacidad de exportar en diferentes motores los esquemas diseñados. 
  • Los diagramas UML para tener una documentación minima y práctica son los siguientes (Usando la herramienta Enterprise Architect):
  • Diagrama de casos de uso.
  • Diagrama de clases.
  • Diagrama de estados.

7) Otras herramientas hacia el cliente.

Cuestionarios sobre el negocio hacia el cliente para conocer a gran nivel como es su proceso de negocio, no estamos modelando simplemente conocer como es su proceso del cliente.

¿Cuantos vendedores tiene?
¿Los vendedores manejan rutas?
¿Manejan listas de precios?
¿Maneja un almacen mobil?
¿Cuantos productos manejan?
¿Formas de pago que manejan (Efectivo, Crédito Cheque u otro)?