Desarrollo Fase

En esta fase incluimos mejoras tanto visuales como de funcionalidad. Como se muestra en la figura 4.3.23, la nueva pantalla cuenta con el logotipo de la aplicación, con lo que se planea atraer al usuario con un diseño universitario y moderno.

50 En la pantalla de registro, implementamos el nuevo diseño y mejoras acerca de la navegación, las cuales permiten al usuario una transición más sencilla entre pantallas.

Figura 4.3.24 Pantalla final de acceso

En la figura 4.3.25, se muestra la pantalla final de registro de usuario, el cual ahora

podrá iniciar una conexión a Facebook, que permite enlazarse a una cuenta y obtener

los datos de esta red social acelerando el proceso de registro.

51

En el segundo nivel, la interfaz de usuario se encuentra mejorada, así como una nueva

estructura de base de datos la cual permite que la velocidad entre requerimiento y

envío de datos sea más rápida.

Figura 4.3.26 Pantalla final del segundo nivel de registro

En la lista de materias a seleccionar, que se muestra en la imagen 4.3.27 agregamos

el diseño correspondiente, a nivel de base de datos se descargan por perfil y por

materia las competencias, esto al momento de finalizar el registro. También con la

finalidad de que el registro sea completo, es solo al final que se almacena en la base de datos los registros de los dos niveles anteriores, para prevenir duplicados o errores de relaciones, en el caso en que el usuario cancele su proceso de registro.

52

El menú de la aplicación se simplifico utilizando solo los accesos a las funcionalidades

necesarias, e incluyendo un visor en el cual se muestran las imágenes

correspondientes a las competencias del usuario, se incluye un cierre de sesión con lo

cual se brinda la oportunidad a un diferente usuario de entrar a su cuenta.

Figura 4.3.28 Pantalla final del menú principal.

La imagen 4.3.29 muestra la pantalla del horario que ahora más dinámica y limpia,

eliminando el elemento pop-up y agregando una nueva ventana como se muestra en la imagen 4.3.30, permitiendo al usuario un mejor registro de eventos agregando campos como prioridad y tipo de evento.

53

Figura 4.3.30: Pantalla final generación de evento.

La captura de imágenes se sustituye por la línea de tiempo que se muestra en la

imagen 4.3.31 que permite la captura de imágenes o la utilización de imágenes directo

de la galería, así como una mejora en la interfaz de dibujo que se muestra en la

imagen 4 3.32 por medio de la pantalla táctil, y la incorporación de notas y el envío a

través de bluetooth.

54

Figura 4.3.32 Pantalla interfaz dibujo táctil..

La figura 4.3.33 muestra la captura de las evaluaciones dependiendo el periodo,

contenidas en tres diferentes tabuladores lo cual minimiza la transición entre

actividades y con la visibilidad de los porcentajes en cada materia que el usuario ha registrado.

55

Conclusiones

La presente tesis tuvo como objetivo diseñar y programar una aplicación móvil desarrollada en el sistema operativo android.

Para llevarlo a cabo primero se realizo un análisis de las aplicaciones actuales, observando que el flujo de información se encuentra limitado en simples datos del usuario almacenando información pero no reutilizándola y observando por datos de las tiendas de aplicaciones que el uso de las mismas para productividad, demanda más y mejor atención por parte de los desarrolladores.

Definitivamente se observo que los flujos de información se están haciendo menos cíclicos y sin ningún fin, lo que quiere decir que las funcionalidades no llegan más allá de las expectativas del usuario.

El hecho de las nuevas tendencias en el desarrollo de aplicaciones móviles, brindan una portabilidad, así como una programación más personalizada dificultando las diferentes condiciones con las cuales se deben contar.

En términos más técnicos se concluye que el análisis de la base de datos externa, fue tan primordial como confusa; la relación entre más de tres tablas fue la solución. Esto a su vez permitió una relación más profunda entre cada campo, pero a su vez, el acceso a datos específicos requirió de un número más grande de parámetros y que los datos fueran cuidadosamente seleccionados dependiendo del tipo de uniones en las consultas. La agilidad aumentó al ahora para ingresar a más de tres tablas por medio de una sola consulta.

Es importante notar que, el desempeño de la base de datos remota montada en un servidor local, se comporta de manera totalmente diferente si esta es puesta en un servidor externo y para accesar a ella, se necesita de una conexión a internet. En cuando a la misma base, el lenguaje SQL, el sistema de montaje de base de datos así como el motor MySQL, facilitan mucho el trabajo, es tan simple como exportar un tipo de archivo y por medio del sistema montarlo y hacer las pruebas de ejecución y consulta permitentes para asegurarnos de su correcto funcionamiento.

No solo basta con cambiar la ubicación de nuestra base de datos, si no de los procesos que interactúan con ella, no olvidar que el lenguaje de programación que se eligió para realizar las diferentes consultas tiene la ventaja de ejecutarse en el servidor, así que ahí deben ser colocados nuestros servicios.

La primera complicación que se presentó es al accesar a esta información, ya que a pesar de que la base está constituida de la misma manera, los prefijos en las consultas que antes se necesitaban ahora causan complicaciones; la forma de corregirlo fue suprimir estos detalles y dejar las consultas de la manera más simple. Sin duda el manejador de base de datos utilizado facilita la exploración de la base de datos, es por eso que la vinculación de este con la nueva base por medio de una nueva conexión fue necesaria, pero estas conexiones resultaron complejas y sin éxito, debido a que nuestro servicio de host donde está montada la base de datos es ajeno, así que no contábamos con los permisos necesarios. Con esto pudimos deducir que toda la accesibilidad es más factible si se cuenta con un espacio propio de pruebas.

56 Se determinó que las diferentes consultas a ejecutar serian más simples por medio de servicios externos en las nuevas actualizaciones que se tenían que montar en la aplicación, notamos una gran ventaja de estar usando diferentes plataformas para diferentes áreas; el área que utiliza el recurso solo se preocupa por la forma en la que recibe el paquete de datos, no de donde lo obtiene, por lo tanto el cambio de localidad de la base de datos no afecto en la aplicación más que en el cambio de dirección del cual lo obtendrá.

En cuestión al desarrollo, el sistema operativo móvil android funcionó a nuestro favor, debido a que es el más usado y cuenta con diferentes fuentes de información, así mismo permite su accesibilidad para realizar diferentes pruebas, aunque como cualquier sistema cuenta con limitaciones o dificultades.

Las consultas de bases de datos internas se realizaron accesando a los datos del emulador, trabajando con una base de datos de solo lectura, alentando en análisis diseño y depuración de la estructura de la base así como de los métodos de la aplicación que accesan a ella sea cual sea la operación.

Los diferentes tamaños de dispositivos en el mercado representan una gran complejidad, tomando en cuenta que existen más de tres mil modelos diferentes con este sistema operativo y a pesar de que entre ellos mismos cuentas con tamaños de pantallas similares algunos varían dependiendo la resolución, esto causo un gran problema en la toma de decisión de en que dispositivo desarrollar la primera versión, ya que los diferentes libros que hablan de la experiencia de usuario y la interfaz de usuario, es recomendable empezar a programar bajo una resolución, por lo cual escogimos una pantalla que se adaptara a una tableta de 7 pulgadas, debido a que las funcionalidades serian más accesibles, y el diseño quedaría mejor desarrollado.

Una variable mas en el desarrollo a considerar fue la versión de sistema operativo, ya que hasta ahora se cuenta con más de diez diferentes versiones, las cuales en orden cronológico muestran mejoras, a pesar de eso según las gráficas mostradas en capítulos anteriores el 90 por ciento del mercado solo usa dos diferentes sistemas operativos.

Con esto es definitivo que optar por una versión más antigua del sistema es la mejor opción en el caso de esta aplicación, ya que se necesitan las operaciones, funcionalidades y elementos nativos a los cuales se accesan, pueden ser utilizando con la versión 2.3 del sistema operativo, así como las últimas versiones sin tener nada depreciado, y con esto abarcamos los dos diferentes sistemas superiores a la versión mencionada, ya que se evita reducir el mercado.

La accesibilidad como desarrollador a otras plataformas con las cuales la plataforma coexista es indispensable, por eso concluimos que desarrollar una aplicación ya sea móvil web o de escritorio necesita más de un lenguaje.

En este caso la característica que java presenta al ser software libre, funciono al integrar los otros elementos del sistema como bases de datos y servicios web.

Es importante notar que al momento de empezar a desarrollar una aplicación móvil requiere un análisis en este caso más extenso que el de una aplicación de escritorio.

57 Como pudimos deducir después de consultar nuestras fuentes en torno al desarrollo necesitábamos establecer un flujo que fuera apropiado para la cantidad de recursos que íbamos a consumir, ya que el uso correcto de la aplicación depende de una conexión a internet.

Este diseño aporta estabilidad y mejores resultados considerando que esto implica un menor uso de memoria el cual sabemos que por el tipo de dispositivos está limitado. Manejar el flujo natural que debería tener la aplicación de manera gráfica, recuerda lo complejo o natural que puede ser, a pesar que el sistema cuenta con diferentes implementaciones por defecto, para el desarrollo y la interfaz de usuario esto fue una complicación y hubo que modificar el comportamiento natural.

De esta forma se puede concluir que la interfaz gráfica de usuario sirve como medio para la comunicación con un sistema. El diseñador cumple una función primordial como constructor de mensajes. Todo proyecto de diseño implica un proceso pensado y consiente que puede tener variaciones, todo depende de diversos factores entre ellos del cambio y evolución que tenga el medio electrónico-digital para lograr que ésta sea eficaz, de fácil uso y memorización y que incluso provoque emociones en el usuario, en beneficio directo del mismo.

Pudimos observar que un menor uso de pantallas facilitaba el manejo de la aplicación tanto para el usuario como para el desarrollador, ya que en el caso del sistema se usan aproximadamente tres clases por actividad.

En cuestión a consumo haciendo pruebas con los dos diferentes sistemas de manejo de conjuntos de datos como XML y JSON, fue definitivo que el segundo presentaba características más útiles para nuestro caso. Como la construcción automática por medio del servicio así como el uso de solo una etiqueta y su interpretación en android más simple.

Es claro que las validaciones en un sistema operativo son más necesarias, complejas y variadas, salen del marco que originalmente ha sido establecido.

El manejo de los elementos gráficos en la aplicación se han usado de las dos maneras existentes, estáticos y dinámicos, de lo anterior podemos concluir que el análisis es necesario para identificar que vista va a ser completamente necesaria construir a través de código cada elemento, ya que el manejo de su información, su construcción así como su transformación posterior es más fácil, pero no podemos olvidar que se necesitan diferentes parámetros como coordenadas, tamaño y contenido por cada uno de estos elementos.

El manejo de estos mismo cualquiera que sea su origen es de las principales complejidades con las que nos encontramos, ya que el contenido tiene que estar cambiando constantemente lo haya decidió o no, siempre se está adaptando a la nueva información introducida.

Con todos estos cambios realizados notamos que la mejor manera de construir un elemento en nuestro caso es de forma dinámica, ya que todo morfológicamente está cambiando como se menciono en el párrafo anterior dependiendo el contenido de la aplicación, y considerando que es usada por más de un usuario.

58 Como en cualquier software es importante considerar que almacenamiento de los datos depende únicamente de aquel que el desarrollador implemento. En desarrollo móvil pudimos contar con diferentes opciones de almacenamiento y notamos que los diferentes datos a pesar de tener el mismo contexto no se relacionaban de la misma manera. En cuanto al almacenamiento de los datos se usaron tres diferentes formas notando las siguientes ventajas y desventajas.

 Base de Datos Interna (SQLite).

La creación y manejo se realiza directamente desde código, esto permite mayor manejo de datos y tablas a su vez es más complejo el desarrollo y los errores tienden a aumentar. Como la creación y manejo son una clase más se puede accesar a esta por medio de programación orientada a objetos lo cual permite que la conexión se realice por medio de una instanciación y llamado de un método.

La inserción extracción y demás manejo de datos se hacen por medio de métodos manejo y retorno de parámetros lo cual agiliza el manejo de estos ya que todos estos registros se muestran como elementos propios del lenguaje de programación haciendo más fácil la tarea de involucrarlos en la aplicación sin requerir un método de parseo u otro parecido.

Al ser una base de datos interna, no se cuenta con un manejador en tiempo real, lo cual dificulta las consultas de prueba o de rectificación de guardado o actualización. El acceso a la base de datos no es practico ya que se tiene que extraer de la memoria del emulador lo cual dificulta el proceso de depuración.

 Archivos

El más complejo de los tres usados, con más validaciones y más propenso a errores ya que está limitado a la capacidad de memoria externa del dispositivo.

El usuario tiene acceso a estos archivo los cuales modificados pueden causar errores de aplicación.

Se guardan diferentes tipos de texto e imágenes no dependiendo de un registro. La cantidad de texto no está limitada como en un registro de base de datos.

La generalización es más compleja, en el caso de la aplicación por cada tipo de archivo a guardar en un método diferente.

 Preferencias

Principalmente se usa para validaciones y datos pequeños ya que su acceso y guardado es el más sencillo de todos, por lo cual es muy rápido para comparaciones de registros anteriores.

Solo guarda pocos tipos de datos, lo cual limita a menos de que se cuente con una transformación de tipo de dato.

Estos datos no fueron de fácil extracción así que cuentas con nivel de protección más alto que el método de guardado de archivos.

59 Con todo esto mencionado se establece que el propósito de analizar, diseñar y desarrollar un sistema capaz de generar un perfil por medio de un asistente escolar ha sido exitoso.

Con una primera fase de desarrollo ha sido posible replicar las principales funcionalidades que un estudiante llega a utilizar durante sus ciclos escolares, reutilizando la información existente en los sitios de internet y creando un ecosistema el cual permita el flujo de datos de la manera más natural, utilizando diferentes recursos explotando las características con las cuales estos fueron diseñados.

Con un número limitado de pruebas pudimos observar que lo usuarios se encuentran en un entorno agradable rápido y conciso en la aplicación.

Ingresando de una forma rápida fluida, con lo cual se logra una aplicación de bolsillo, poderosa y rápida.

60