You are on page 1of 12

INSTITUTO TECNOLOGICO SUPERIOR

DE ALVARADO

INGENIERÍA EN SISTEMAS
COMPUTACIONALES

Materia:
BASES DE DATOS PARA DISPOSITIVOS MOVILES

Semestre-Grupo:
8 “U”
Producto Académico:
INVESTIGACIÓN – UNIDAD 1 – ELEMENTOS
PARA DESARROLLO DE APPS MÓVILES

Presenta:
CRUZ LÁZARO CARLOS ALEXIS
<146Z0752>

Docente:
MRI. HERMINIO CARLIN QUEVEDO

H. Y G. ALVARADO, VER. FEBRERO - JUNIO 2018

Página | 1
Carrera Plan de Estudios Clave Asignatura
Ingeniería en Sistemas ISIE-TWR-2007-01 BDM-1301 Bases de Datos
Computacionales para Dispositivos
Móviles

Practica No. Nombre de la Practica Unidad Duración (Horas)


1 Criterios Para el Desarrollo de 1 1
Aplicaciones Móviles.

Página | 2
1. INTRODUCCION

El presente documento contiene una recopilación de información referente a los criterios


más señalados para el desarrollo de aplicaciones destinadas a los dispositivos móviles.

Página | 3
Elementos Para el Desarrollo de Aplicaciones
Móviles

Página | 4
En este espacio se identificarán cuáles son los principales puntos a considerar al buscar
desarrollar una solución que funcione sobre dispositivos móviles.

Conectividad
Una solución móvil en una empresa jamás es una solución aislada. Normalmente es una
extensión de los sistemas empresariales existentes, como ERPs o CRMs. Por lo tanto, es
fundamental entender las opciones de
conectividad disponibles en el mercado y el
impacto que tienen en nuestra posible aplicación.

En primer lugar, podemos clasificar las


aplicaciones móviles en línea y fuera de línea.
Una aplicación fuera de línea es aquella que se
sincroniza mediante una conexión física
ocasional, ya sea cuando el personal móvil regresa a la empresa o a través de un modem.
Por otro lado, una aplicación en línea puede ser de gran ancho de banda (Wi-Fi) o bien de
bajo ancho de banda (GPRS).

Para una aplicación de gran ancho de banda podemos elegir el utilizar una interfaz web
optimizada para el formato pequeño del dispositivo móvil, si es que el navegador nos ofrece
la flexibilidad de diseño que necesitamos.

En los demás patrones, lo más recomendable es una arquitectura ocasionalmente


conectada donde planeamos la aplicación para que funcione con o sin conectividad, aunque
algunos de nuestros servicios estén restringidos en el segundo caso. De esta manera no
dejaremos a nuestros usuarios abandonados cuando no tengan una conexión a la mano.

Página | 5
Sincronización de Datos
Precisamente para una aplicación ocasionalmente conectada, se vuelve crucial contar con
una buena estrategia de sincronización de datos. Lo más recomendable es aprovechar la
infraestructura de sincronización existente en motores de base de datos ya maduros. Entre
las mejores opciones encontramos a Microsoft SQL Server Mobile, Oracle Lite y SQL
Anywhere Studio. A mi juicio, la experiencia más completa e integrada para desarrollar
aplicaciones móviles con sincronización de datos es ofrecida por la combinación de
Microsoft SQL Server Mobile, SQL Server 2005 y Visual Studio 2005.

Estas herramientas se encargan de resolver los aspectos más importantes para sincronizar
datos en una solución móvil y nos ahorrarán mucho trabajo. Comprimen la información para
ambientes de bajo ancho de banda, particionan nuestra base de datos maestra para cada
usuario móvil, y se encargan de replicar los cambios entre el servidor y los dispositivos
móviles. Adicionalmente, nos permiten monitorear el estatus de la sincronización y resolver
problemas. Finalmente, nos ofrecen una forma de programar basada en SQL en el
dispositivo móvil.

Una opción muy interesante para los servicios en línea (por ejemplo, para checar un nivel
de inventario a través de GPRS) son los servicios web basados en SOAP (Simple Object
Access Protocol) mediante los cuales es muy sencillo realizar una transacción simple contra
nuestros sistemas empresariales.

Soporte
Por definición, es muy probable que nuestros usuarios se
encuentren dispersos geográficamente y que sea complicado
darles soporte. Actividades como la actualización de nuestra
aplicación, o otorgar apoyo para resolver un problema,
pueden resultar complicadas y costosas, elevando
innecesariamente el costo total de propiedad de la solución.

Por esta razón, es indispensable contar desde un inicio con una estrategia de soporte
basada en herramientas que nos permitan administrar fácilmente nuestros dispositivos de
forma remota. Debemos ser capaces de actualizar nuestra aplicación de forma remota, de
obtener información de fallas de forma automática y de atender remotamente a nuestros
usuarios y a sus dispositivos.

Página | 6
Interfaz de Usuario
Uno de los errores más comunes cuando un programador que viene del mundo de las
computadoras personales aborda un proyecto para dispositivos móviles, es subestimar las
diferencias en la interfaz de usuario. Los dispositivos móviles están restringidos en el área
de la pantalla y en las formas en que aceptan entradas de sus usuarios. Esto implica que
debemos pensar siempre en una interfaz lo más sencilla posible y parecida a la de las
demás aplicaciones que existen en la PDA o en el SmartPhone.

Debemos limitar la información presentada a aquella que sea indispensable. También


minimizar el número de entradas que deba hacer el
usuario, aprovechando los métodos de entrada que
nos ofrezca el dispositivo. Nuestra aplicación debe
estar preparada para que el dispositivo se apague
o encienda en cualquier momento sin pérdida de
información.

Plataforma
Las plataformas más comunes para desarrollo de aplicaciones móviles son J2ME (Java 2
Micro Edition), y el .NET Compact Framework para Windows Mobile. Personalmente, para
el desarrollo de aplicaciones corporativas, he elegido especializarme en este último, ya que
considero que ofrece varias ventajas sobre las alternativas disponibles:
• Capacidad de rehusar el conocimiento de desarrollo existente en lenguajes .NET para el
escritorio.
• Excelente desempeño y velocidad de desarrollo.
• Facilidad para interactuar con aplicaciones corporativas gracias a una infraestructura muy
completa para manejo de XML y desarrollo de clientes SOAP.
• Integración simple con SQL Server CE.
• Posibilidad de desarrollar en Visual Studio .NET

Herramientas de Desarrollo
Las opciones de IDE dependen de la elección de plataforma: CodeWarrior es una
herramienta muy popular para aplicaciones en PalmOS, NetBeans parece ser la opción
default en el caso de J2ME, y para el .NET Compact Framework, la mejor opción la ofrece
Visual Studio.

Página | 7
Componentes Básicos de Una Aplicación

Existe una serie de elementos clave que resultan imprescindibles para desarrollar
aplicaciones en Android. En este apartado vamos a realizar una descripción inicial de
algunos de los más importantes. A lo largo del curso se describirán con más detalle las
clases Java que implementan cada uno de estos componentes.

Vista (View)

Las vistas son los elementos que componen la


interfaz de usuario de una aplicación: por ejemplo,
un botón o una entrada de texto. Todas las vistas van
a ser objetos descendientes de la clase View, y por
tanto, pueden ser definidas utilizando código Java.
Sin embargo, lo habitual será definir las vistas
utilizando un fichero XML y dejar que el sistema cree
los objetos por nosotros a partir de este fichero. Esta forma de trabajar es muy similar a la
definición de una página web utilizando código HTML.

Layout

Un layout es un conjunto de vistas agrupadas de una determinada forma. Vamos a disponer


de diferentes tipos de layouts para organizar las vistas de forma lineal, en cuadrícula o
indicando la posición absoluta de cada vista. Los layouts también son objetos
descendientes de la clase View. Igual que las vistas, los layouts pueden ser definidos en
código, aunque la forma habitual de definirlos es utilizando código XML.

Actividad (Activity)

Una aplicación en Android va a estar formada por un conjunto de elementos básicos de


visualización, coloquialmente conocidos como pantallas de la aplicación. En Android cada
uno de estos elementos, o pantallas, se conoce como actividad. Su función principal es la
creación de la interfaz de usuario. Una aplicación suele necesitar varias actividades para
crear la interfaz de usuario. Las diferentes actividades creadas serán independientes entre

Página | 8
sí, aunque todas trabajarán para un objetivo común. Toda actividad ha de pertenecer a una
clase descendiente de Activity.

Fragmentos (Fragment)

La llegada de las tabletas trajo el problema de que las aplicaciones de Android ahora deben
soportar pantallas más grandes. Si diseñamos una aplicación pensada para un dispositivo
móvil y luego la ejecutamos en una tableta, el resultado no suele resultar satisfactorio.

Para ayudar al diseñador a resolver este problema, en la versión 3.0 de Android aparecen
los fragments. Un fragment está formado por la unión de varias vistas para crear un bloque
funcional de la interfaz de usuario. Una vez creados los fragments, podemos combinar uno
o varios fragments dentro de una actividad, según el tamaño de pantalla disponible.

El uso de fragments puede ser algo complejo, por lo que recomendamos dominar primero
conceptos como actividad, vista y layout antes de abordar su aprendizaje. No obstante, es
un concepto importante en Android y todo programador en esta plataforma ha de saber
utilizarlos. En la última unidad de este curso aprenderemos más sobre fragments.

Servicio (Service)

Un servicio es un proceso que se ejecuta “detrás”, sin la necesidad de una interacción con
el usuario. Es algo parecido a un demonio en Unix o a un servicio en Windows. En Android
disponemos de dos tipos de servicios: servicios locales, que son ejecutados en el mismo
proceso y servicios remotos, que son ejecutados en procesos separados.

Página | 9
Intención (Intent)

Una intención representa la voluntad de realizar alguna acción; como realizar una llamada
de teléfono, visualizar una página web. Se utiliza cada vez que queramos:

- Lanzar una actividad


- Lanzar un servicio
- Enviar un anuncio de tipo broadcast
- Comunicarnos con un servicio

Los componentes lanzados pueden ser internos o externos a nuestra aplicación. También
utilizaremos las intenciones para el intercambio de información entre estos componentes.

Receptor de anuncios (Broadcast Receiver)

Un receptor de anuncios recibe anuncios broadcast y reacciona ante ellos. Los


anuncios broadcast pueden ser originados por el sistema (por ejemplo: Batería baja,
Llamada entrante) o por las aplicaciones. Las aplicaciones también pueden crear y lanzar
nuevos tipos de anuncios broadcast. Los receptores de anuncios no disponen de interfaz
de usuario, aunque pueden iniciar una actividad si lo estiman oportuno.

Proveedores de Contenido (Content Provider)

En muchas ocasiones las aplicaciones instaladas en un terminal Android necesitan


compartir información. Android define un mecanismo estándar para que las aplicaciones
puedan compartir datos sin necesidad de comprometer la seguridad del sistema de ficheros.
Con este mecanismo podremos acceder a datos de otras aplicaciones, como la lista de
contactos, o proporcionar datos a otras aplicaciones.

Página | 10
Conclusión

En conclusión, es normal que se encuentren estandarizados los aspectos más relevantes


en cuanto a los elementos para dar vida a una aplicación móvil se refiere; esto nos
proporciona una guía que nos certifica la fidelidad de los componentes del proyecto a
desarrollar, y por ende, cumplir con los criterios y normativas de calidad para la elaboración
de un programa de ésta índole, dándole mayor crédito, confiabilidad, y sobre todo seguridad
entre la comunidad de usuarios, o en un caso particular, del cliente.

Página | 11
Fuentes de Información

- https://sg.com.mx/content/view/490

- http://www.androidcurso.com/index.php/tutoriales-android/31-unidad-
1-vision-general-y-entorno-de-desarrollo/149-componentes-de-una-
aplicacion

Página | 12