Date post: | 05-Oct-2018 |
Category: |
Documents |
Upload: | hoangthien |
View: | 212 times |
Download: | 0 times |
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 26
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3. Estado del Arte
3.1. Modelos de computación en la nube. IAAS, PAAS Y SAAS
En los inicios de la era informática, el alto precio de los ordenadores
comparado con su poca capacidad de procesamiento fomento el primer modelo
de computación basado en cliente-servidor. Era habitual que muchos terminales
sin capacidad de procesamiento se
conectaran a una unidad central o servidor al
cual enviaban sus peticiones mediante cable
de red.
El avance de la tecnología, el
abaratamiento de costes y el aumento de las
prestaciones propició que se pudiera
conseguir máquinas con alta capacidad de
procesamiento a bajo coste, que podían
trabajar de manera independiente.
De nuevo, el avance de la tecnología, en este caso, el acceso a internet,
ha llegado a tal punto que se plantean nuevos modelos de computación. Se
Figura 7: Computación en la nube
Figura 6: Modelo cliente-servidor
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 27
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
conoce como computación en la nube a un modelo de distribución de recursos
online al cual acceden los usuarios a través de internet. Se trata de un modelo
descentralizado donde el usuario no tiene acceso físico ni a la aplicación ni a los
datos, que son almacenados en servidores distintos, afín de evitar posibles
pérdidas. La gestión de los servidores y de cualquier tipo de mantenimiento lo
lleva a cabo la empresa suministradora.
Con este modelo ya no hablamos de licencia de uso sino de alquiler por
parte del usuario de una máquina, una plataforma o una simple aplicación. Esto
permite a las empresas proveedoras diferenciarse según el servicio que presten
y enfocar su negocio a un tipo de cliente específico.
Pero, ¿cuántos tipos de computación en la nube existen? Principalmente
tres, en función de qué se proporcione al cliente:
1. Infrastructure-as-a-Service (IAAS): el proveedor se compromete a
proporcionar una capacidad de proceso (CPU) y una cantidad de
almacenamiento (disco duro). El cliente puede utilizar estos recursos como
mejor le convengan, instalando sus propias aplicaciones o utilizando el espacio
disponible para guardar copias de seguridad. El proveedor se encarga de su
gestión.
2. Platform-as-a-Service (PAAS): en este caso, se contrata un servidor de
aplicaciones junto con una base de datos, todo gestionado por el proveedor.
Puede que existan una serie de restricciones a la hora de instalar aplicaciones o
desarrollarlas en este entorno. Depende de la plataforma contratada, puede
que incluya sistema operativo, asistencia técnica, soporte para lenguajes
específicos, etc…
3. Software-as-a-Service (SAAS): se paga por una aplicación, un alquiler
por usarla, así como por los módulos extra contratados (espacio en disco, bases
de datos, soporte técnico, etc…). Se trata de una aplicación final como puede
ser en nuestro caso una solución CRM.
Las ventajas de la computación en la nube son bastante claras:
escalabilidad infinita, separación evidente entre usuario y proveedor, reducción
de costes e inversión inicial, menor riesgo, aumento de la seguridad, soporte
24h, posibilidad de acceso desde cualquier dispositivo con acceso a internet y
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 28
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
desde cualquier punto, totalmente configurable a petición del usuario y al
tratarse de un entorno cerrado se asegura la eficiencia.
Por contra, las desventajas también parecen evidentes pero la más
importante es que si el usuario no tiene acceso a internet, no puede acceder a
su servicio. Al igual que si el servicio no esta disponible por un fallo en los
servidores, el usuario no podrá trabajar, con las consecuentes pérdidas
económicas.
Figura 8: Computación en la nube. Esquema SaaS
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 29
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.2. Soluciones CRM
Existen multitud de soluciones para gestionar una estrategia CRM,
soluciones abiertas y cerradas y en la nube (online, On-Demand) o en local
(offline, On-Premise). Debido al gran número de empresas dedicadas en este
sector, se ha reducido la búsqueda a las más importantes del mercado o las que
tienen mayor repercusión.
3.2.1. SugarCRM
http://www.sugarcrm.com/crm/products/editions
Desarrollado por la empresa SugarCRM Inc., se trata de una solución
basada en LAMP (Linux, Apache, MySQL y PHP) aunque también puede ser
ejecutada en una máquina con windows. Posee 5 versiones, cuatro de ellas de
pago, siendo la única funcionalidad extra en las ediciones de pago acceso desde
smartphones, alojamiento web, soporte personalizado y un acuerdo SLA
(Service-level Agreement o acuerdo de nivel de servicio). Por otra parte, la
edición gratuita, contiene todas las funcionalidades básicas y hay entorno a ella
una gran comunidad de desarrolladores libres que han creado algunas de las
funcionalidades que se ofrecen en las versiones de pago.
Esta comunidad utiliza la página sugarforge.org para ofrecer módulos y
documentación al resto de usuarios, cobrando en ocasiones por sus servicios.
3.2.2. CiviCRM
http://civicrm.org/features
CiviCRM se trata de otra solución basada en LAMP con la diferencia con
respecto a SugarCRM que para su funcionamiento necesita de un gestor de
contenidos (CMS) como puede ser Drupal, Joomla o Wordpress. Los creadores
son desarrolladores independientes a lo largo del mundo, apoyados por la
comunidad libre y por donaciones voluntarias. Principalmente es usado por
ONG’s y organizaciones sin animo de lucro porque no tiene un toque comercial.
Las funcionalidades básicas del núcleo son mantener contactos, relaciones,
actividades y grupos mientras que existen una serie de módulos externos que
permiten ampliar estas funcionalidades (CiviContribute, CiviEvent,
CiviMember,…).
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 30
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Las nuevas versiones de CiviCRM admiten varios formatos para la
integración de datos (RSS, JSON, XML o CSV) así como progamación en JSP.
3.2.3. HiperGate
http://hipergate.morfeo-project.org/
HiperGate es un software del proyecto Morfeo (relacionado con la
empresa KnowGate), creado por españoles, que se apoya en software abierto y
en la plataforma Java con base de datos PostgreSQL o MySQL. Es un proyecto
que lleva sin actualizarse desde diciembre de 2010 y la información encontrada
acerca del proyecto es anterior aun. Se considera abandonado y no se incluirá
en la comparativa 3.2.9.
3.2.4. SAP CRM
http://www.sap.com/solutions/bp/customer-relationship-
management/index.epx
Pionera en el mundo del software CRM, incluye su aplicación en una suite
que se compone de 5 módulos que ayudan a gestionar distintos aspectos de una
empresa (Gestión de stocks, recursos humanos, procesos de manufactura,
fabricantes y distribuidores y clientes en ese orden), aunque pueden ser
adquiridas por separado. La desventaja de esta solución radica en que la curva
de aprendizaje es bastante elevada si no se tiene conocimientos de otros
módulos de la compañía.
Su última versión, 6.0, usa el modelo SaaS, con una base de datos, un
servidor de aplicaciones y un cliente, aunque originalmente SAP defendió el
modelo centralizado.
3.2.5. Salesforce.com
http://www.salesforce.com/es/crm/sales-force-automation/
La empresa Salesforce.com ofrece sus productos de ventas y marketing
desde 1999, pionera en este aspecto. Actualmente es una de las empresas más
fuertes en el mercado de la computación en la nube, llegando a organizar el
mayor evento dedicado a este campo, “dreamforce”. La misma empresa tiene
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 31
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
un centro de formación online para certificarse en administrador, desarrollador
o experto en productos salesforce.com
Sales Cloud es su solución basada en CRM, según la licencia adquirida es
capaz de dar mayores funcionalidades entre las que destacan el soporte técnico,
interconexión con otros productos de la misma compañía, alojamiento web,
acceso desde smartphones, etc.
3.2.6. Microsoft Dynamics
http://crm.dynamics.com/es-es/home
Microsoft Dynamics es una línea de software ERP y CRM de propiedad y
desarrollado por Microsoft. La versión CRM 4.0 ofrece a los usuarios la gestión
de ventas, servicios y marketing desde la misma plataforma, además tiene tanto
versión offline como versión online. La versión offline se apoya en la suite
ofimática Microsoft Office para llevar a cabo su funcionamiento.
3.2.7. Oracle CRM On Demand
http://www.oracle.com/us/products/applications/crmondemand/index.html
La suite de Oracle se divide en varias líneas de productos y surgen
después de la adquisición por parte de Oracle de la empresa Siebel Systems. A
partir de entonces, entró en el mercado CRM y posteriormente unió a su suite,
UpShot CRM, con una interfaz más robusta e intuitiva. De la fusión de ambos
productos, surge Oracle CRM On Demand, cuyo despliegue es completamente
online y sus funcionalidades varían en función de la licencia adquirida.
3.2.8. Elección solución CRM
Para decidir que software CRM utilizar como base de la aplicación a
desarrollar se debe tomar un criterio. En principio todos los software CRM
ofrecen las mismas opciones en cuanto a funciones, solo los diferencia el precio
de las ediciones, el soporte técnico y detalles menores.
El criterio para elegir qué solución usar será minimizar el coste de
explotación y los costes de mantenimiento. Las soluciones cerradas ofrecen el
mismo producto que las soluciones abiertas pero incluyendo un coste mensual
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 32
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
por el uso del servicio por lo que las descartamos. De las tres soluciones
abiertas, una de ellas se encuentra en estado de abandono.
Por lo tanto, el siguiente paso será realizar una comparativa a fondo de
los dos sistemas elegidos para decidir cuál usar: SugarCRM o CiviCRM.
Otra opción a estudiar sería la programación desde cero de una
aplicación a medida aunque para ello primero habría que establecer unos
objetivos y unos requerimientos. Dado el tamaño que puede llegar a alcanzar
este proyecto parece razonable descartar esta opción y centrarse en las
soluciones libres que existen.
3.2.9. Comparativa SugarCRM y CiviCRM
Realmente es innecesario hacer una comparativa a fondo de las
soluciones SugarCRM y CiviCRM porque ambas ofrecen prácticamente las
mismas características y funcionalidades al usuario exceptuando el enfoque
final. SugarCRM está orientado a una empresa de ventas, con un enfoque
comercial, buscar nuevas oportunidades, poder ofrecer al cliente todo lo que
necesite buscando el máximo beneficio para la empresa.
En cambio, CiviCRM es un sistema que permite recaudar fondos,
orientado a fines no lucrativos, centrándose más en las relaciones existentes
entre usuarios. Otra diferencia fundamental es el hecho de que SugarCRM
funciona de manera standalone mientras que CiviCRM necesita un gestor de
contenido.
Un análisis más a fondo revela que ambas soluciones tienen soporte para
la comunicarse con un agente externo mediante las api REST y SOAP, las cuales
serán explicadas en el siguiente punto. Servirán de punto de partida para la
interconexión entre cliente (aplicación Android) y el servidor.
Finalmente, el sistema elegido es SugarCRM ya que, además de ser líder
en el mercado libre, posee un mayor carácter comercial que puede dar más
significado a una aplicación móvil (acceder a fichas de cliente o productos desde
una reunión con los implicados por ejemplo).
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 33
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.3. Servicios Web
El consorcio W3C define los Servicios Web como sistemas software
diseñados para soportar una interacción interoperable máquina a máquina
sobre una red. Los Servicios Web suelen ser APIs Web que pueden ser accedidas
dentro de una red (principalmente Internet) y son ejecutados en el sistema que
los aloja.
Interfaz de programación de aplicaciones (IPA) o API (del inglés
Application Programming Interface) es el conjunto de funciones y
procedimientos (o métodos, en la programación orientada a objetos) que ofrece
cierta biblioteca para ser utilizado por otro software como una capa de
abstracción. Son usadas generalmente en las bibliotecas (también denominadas
vulgarmente "librerías").
La definición de Servicios Web propuesta alberga muchos tipos
diferentes de sistemas, pero el caso común de uso de refiere a clientes y
servidores que se comunican mediante mensajes XML que siguen el estándar
SOAP. A continuación se exponen los tres principales estilos de arquitectura
basadas en servicios web:
A. Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los
Servicios Web basados en RPC presentan una interfaz de llamada a
procedimientos y funciones distribuidas, lo cual es familiar a muchos
desarrolladores. Típicamente, la unidad básica de este tipo de servicios es la
operación WSDL (Web Services Description Language).
Las primeras herramientas para Servicios Web estaban centradas en esta
visión. Algunos lo llaman la primera generación de Servicios Web. Esta es la
razón por la que este estilo está muy extendido. Sin embargo, ha sido algunas
veces criticado por no ser débilmente acoplado, ya que suele ser implementado
por medio del mapeo de servicios directamente a funciones específicas del
lenguaje o llamadas a métodos. Muchos especialistas creen que este estilo debe
desaparecer.
B. Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA). Los
Servicios Web pueden también ser implementados siguiendo los conceptos
de la arquitectura SOA, donde la unidad básica de comunicación es el
mensaje, más que la operación. Esto es típicamente referenciado como
servicios orientados a mensajes.
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 34
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Los Servicios Web basados en SOA son soportados por la mayor parte de
desarrolladores de software y analistas. Al contrario que los Servicios Web
basados en RPC, este estilo es débilmente acoplado, lo cual es preferible ya que
se centra en el “contrato” proporcionado por el documento WSDL, más que en
los detalles de implementación subyacentes.
C. REST (REpresentation State Transfer): Servicios Web basados en REST
intentan emular al protocolo HTTP o protocolos similares mediante la
restricción de establecer la interfaz a un conjunto conocido de operaciones
estándar (por ejemplo GET, PUT,…). Por tanto, este estilo se centra más en
interactuar con recursos con estado, que con mensajes y operaciones.
A continuación vamos a extender las definiciones de SOAP y REST para
poder elegir cuál usar en el servicio web que vamos a usar, pues ambas
opciones son posibles.
3.3.1. REST
La Transferencia de Estado Representacional (Representational State
Transfer) o REST es una técnica de arquitectura software para sistemas
hipermedia distribuidos como la World Wide Web. El término se originó en el
año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los
principales autores de la especificación del protocolo HTTP y ha pasado a ser
ampliamente utilizado por la comunidad de desarrollo.
Si bien el término REST se refería originalmente a un conjunto de
principios de arquitectura, en la actualidad se usa en el sentido más amplio para
describir cualquier interfaz web simple que utiliza XML y HTTP, sin las
abstracciones adicionales de los protocolos basados en patrones de intercambio
de mensajes como el protocolo de servicios web SOAP. Es posible diseñar
sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding
y también es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de
llamada a procedimiento remoto pero sin usar SOAP. Estos dos usos diferentes
del término REST causan cierta confusión en las discusiones técnicas, aunque
RPC no es un ejemplo de REST.
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 35
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Los sistemas que siguen los principios REST se llaman con frecuencia
RESTful. REST afirma que la web ha disfrutado de escalabilidad como resultado
de una serie de diseños fundamentales clave:
Cada mensaje HTTP contiene toda la información necesaria para
comprender la petición. Como resultado, ni el cliente ni el servidor necesitan
recordar ningún estado de las comunicaciones entre mensajes. Sin embargo, en
la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros
mecanismos para mantener el estado de la sesión (algunas de estas prácticas,
como la rescritura de URLs, no son permitidas por REST)
HTTP en sí define un conjunto pequeño de operaciones, las más
importantes son POST, GET, PUT y DELETE. Con frecuencia estas operaciones se
equiparan a las operaciones CRUD que se requieren para la persistencia de
datos, aunque POST no encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos. En un sistema REST,
cada recurso es direccionable únicamente a través de su URI.
El uso de hipermedios, tanto para la información de la aplicación como
para las transiciones de estado de la aplicación: la representación de este
estado en un sistema REST son típicamente HTML o XML. Como resultado de
esto, es posible navegar de un recurso REST a muchos otros, simplemente
siguiendo enlaces sin requerir el uso de registros u otra infraestructura
adicional.
3.3.2. SOAP
SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar
que define cómo dos objetos en diferentes procesos pueden comunicarse por
medio de intercambio de datos XML. Este protocolo deriva de un protocolo
creado por David Winer en 1998, llamado XML-RPC. SOAP fue creado por
Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C. Es uno de
los protocolos utilizados en los servicios Web.
SOAP puede formar la capa base de una "pila de protocolo de un servicio
web", ofreciendo un framework de mensajería básica en la cual los servicios
web se puedan construir. Este protocolo basado en XML consiste de tres partes:
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 36
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
un sobre (envelope), el cual define qué hay en el mensaje y cómo procesarlo; un
conjunto de reglas de codificación para expresar instancias de tipos de datos; y
una conversión para representar llamadas a procedimientos y respuestas. El
protocolo SOAP tiene tres características principales:
Extensibilidad (seguridad y WS-routing son extensiones aplicadas en el
desarrollo).
Neutralidad (SOAP puede ser utilizado sobre cualquier protocolo de
transporte como HTTP, SMTP, TCP o JMS).
Independencia (SOAP permite cualquier modelo de programación).
Como ejemplo de cómo los procedimientos SOAP pueden ser utilizados, un
mensaje SOAP podría ser enviado a un sitio Web que tiene habilitado un
servicio web, para realizar la búsqueda de algún precio en una base de datos,
indicando los parámetros necesitados en la consulta. El sitio podría retornar un
documento formateado en XML con el resultado, ejemplo, precios, localización,
características. Teniendo los datos de respuesta en un formato estandarizado
"parseable", este puede ser integrado directamente en un sitio Web o
aplicación externa.
La arquitectura SOAP consiste de muchas capas de especificación: para el
formato del mensaje, MEP (Message Exchange Patterns), subyacentes enlaces
de protocolo de transporte, modelo de procesamiento de mensajes, y
extensibilidad del protocolo. SOAP es el sucesor de XML-RPC, a pesar de que
toma el transporte y la neutralidad de la interacción y el envelope / header /
body de otra parte (probablemente de WDDX).
3.3.3. Comparativa REST y SOAP
A modo de resumen, se exponen dos tablas, una con las características de
ambas API y otra con diferencias:
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 37
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
REST SOAP
Características
Las operaciones se definen en los mensajes. Una dirección única para cada instancia del proceso. Cada objeto soporta las operaciones estándares definidas. Componentes débilmente acoplados.
Las operaciones son definidas como puertos WSDL. Dirección única para todas las operaciones. Múltiple instancias del proceso comparten la misma operación. Componentes débilmente acoplados.
Ventajas declaradas
Bajo consumo de recursos. Las instancias del proceso son creadas explícitamente. El cliente no necesita información de enrutamiento a partir de la URI inicial. Los clientes pueden tener una interfaz “listener” genérica para las notificaciones. Generalmente fácil de construir y adoptar.
Fácil (generalmente) de utilizar. La depuración es posible. Las operaciones complejas pueden ser escondidas detrás de una fachada. Envolver APIs existentes es sencillo Incrementa la privacidad. Herramientas de desarrollo
Posibles desventajas
Gran número de objetos. Manejar el espacio de nombres (URIs) puede ser engorroso. La descripción sintáctica/semántica muy informal (orientada al usuario). Pocas herramientas de desarrollo.
Los clientes necesitan saber las operaciones y su semántica antes del uso. Los clientes necesitan puertos dedicados para diferentes tipos de notificaciones. Las instancias del proceso son creadas implícitamente.
Figura 9: Tabla comparativa REST y SOAP
Punto de vista
REST SOAP
Tecnología
Interacción dirigida por el usuario por medio de formularios.
Flujo de eventos orquestados.
Pocas operaciones con muchos recursos
Muchas operaciones con pocos recursos.
Mecanismo consistente de nombrado de recursos (URI).
Falta de un mecanismo de nombrado.
Se centra en la escalabilidad y rendimiento a gran escala para sistemas distribuidos hipermedia.
Se centra en el diseño de aplicaciones distribuidas.
XML autodescriptivo Tipado fuerte, XML Schema
HTTP Independiente del transporte
HTTP es un protocolo de aplicación HTTP es un protocolo de transporte
Síncrono Síncrono y Asíncrono
Figura 10: Diferencias entre REST y SOAP I
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 38
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Descripción del Servicio
Confía en documentos orientados al usuario que define las direcciones de petición y las respuestas.
WDSL
Interactuar con el servicio supone horas de testeado y depuración de URIs.
Se pueden construir automáticamente stubs (clientes) por medio del WSDL
No es necesario el tipado fuerte, si ambos lados están de acuerdo con el contenido.
Tipado fuerte
WADL propuesto en noviembre de 2006.
WDSL 2.0
Gestión del estado
El servidor no tiene estado (stateless).
El servidor puede mantener el estado de la conversación.
Los recursos contienen datos y enlaces representando transiciones a estados válidos.
Los mensajes solo contienen datos.
Los clientes mantienen el estado siguiendo los enlaces.
Los clientes mantienen el estado suponiendo el estado del servicio
Técnicas para añadir sesiones: Cookies
Técnicas para añadir sesiones: Cabecera de sesión (no estándar)
Seguridad
HTTPS WS-Security
Implementado desde hace muchos años.
Las implementaciones están comenzando a aparecer ahora.
Comunicación punto a punto segura.
Comunicación origen a destino segura.
Metodología de diseño
Identificar recursos a ser expuestos como servicios.
Listar las operaciones del servicio en el documento WSDL.
Definir URLs para direccionarlos Definir un modelo de datos para el contenido de los mensajes.
Distinguir los recursos de solo lectura (GET) de los modificables (POST, PUT, DELETE).
Elegir un protocolo de transporte apropiado y definir las correspondientes políticas QoS, de seguridad y transaccional
Implementar e implantar el servidor Web.
Implementar e implantar el contenedor del servicio Web.
Figura 11: Diferencias entre REST y SOAP II
Figura 12: Pila de protocolos REST y SOAP
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 39
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.3.4. Elección API
A partir de las ventajas y desventajas de ambas API, teniendo en cuenta
que el sistema en el cual se va a desarrollar es un dispositivo móvil con conexión
a internet:
Es necesario limitar el uso de ancho de banda ya que
generalmente la conexión a internet está tarificada por unidad de datos REST
Los recursos del dispositivo pueden ser muy limitados ya que la
plataforma Android es abierta y existen multitud de modelos que lo incorporan
REST
Por otra parte, según Amazon, actualmente el protocolo REST es el más
utilizado en su propio sitio de computación en la nube: Amazon web services.
Figura 13: Protocolos en Amazon web Services
Por estos motivos, se elige para implementar en la aplicación el protocolo
REST.
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 40
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.4. Plataforma Android
En este punto se va a extender de forma global qué conforma la
plataforma Android. Existen actualmente 5 plataformas móviles que copan la
amplia mayoría del mercado de las tecnologías móviles: iOS de Apple, Symbian
de Nokia, Windows Mobile de Microsoft, BlackBerry de RIM y por último
Android de Google.
Android es una pila de software pensada para smartphones o móviles
inteligentes, incluyendo un sistema operativo, middleware y una capa de
aplicaciones. La capa middleware ofrece algunos servicios extra a la capa de
aplicaciones que no ofrece el sistema operativo, hace mas fácil a los
desarrolladores la comunicación entrada/salida con las diversas partes del
equipo. También incluye la máquina virtual Dalvik, de la cual hablaremos en
otro punto.
Android convierte un Smartphone en algo más que un teléfono para
llamar o recibir llamadas, escribir mensajes de texto cortos (SMS) o recibir
correos electrónicos. Un dispositivo Android tiene acceso a multitud de
aplicaciones para realizar casi cualquier operación que realiza un ordenador
personal, cosa impensable hace años. Este gran avance ha sido propiciado
principalmente por el avance de la tecnología en múltiples campos como la
miniaturización, que ha permitido unir en un mismo dispositivo procesadores
Quad-core (4 núcleos), sensores CMOS o radio FM.
Se decide como plataforma final el sistema Android ya que es de libre
distribución, el acceso al SDK de desarrollo es totalmente gratuito y por otra
parte, al estar basado en Linux, tiene un fuerte soporte por parte de la
comunidad libre. Además, la plataforma se encuentra en pleno auge con más de
1.3 millones de activaciones diarias, sumando un total de 500 millones de
activaciones globales (Septiembre 2012).
3.4.1. Inicios de Android. Creación de la OHA.
El principal benefactor de Android es la multinacional Google, quien en
julio de 2005, adquirió la compañía startup Android Inc. principalmente para
comprar dicho sistema operativo que estaban desarrollando. Por aquel
entonces, Apple estaba empezando el desarrollo del Iphone, Microsoft tenia
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 41
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
una cuota de mercado pequeña con su Windows Mobile y principalmente Nokia
y BlackBerry se repartían la totalidad del mercado móvil.
Google, basándose en su filosofía de apoyar el software libre, creó la
Open Handset Alliance (OHA), consorcio formado por fabricantes, proveedores
y operadores, para fomentar el desarrollo de estándares para telefonía móvil.
Coincidiendo con la creación de este consorcio, se presentó Android en
noviembre de 2007, plataforma de código libre con licencia Apache 2.0 y GNU
GPL para teléfonos móviles basado en Linux. El primer SDK fue lanzando una
semana después siendo el primer móvil comercializado en la historia el T-
Mobile G1 (también conocido como HTC Dream) en octubre de 2008.
Actualmente, Android ya no sólo es usado en terminales móviles, desde
la versión 3.0 se añadió soporte para tablets y dispositivos con pantallas
superiores a la de los móviles. Reproductores de música y video, ebooks, Smart
TVs, entre otros, pueden encontrarse con este sistema operativo.
Android ha tenido muchas revisiones desde su primera versión. Cada una
de ellas, además de un número de versión, toma el nombre de un postre en
inglés. La particularidad es que cada una, empieza con una letra del abecedario
comenzando desde la A hasta la J actual. Por supuesto, existen versiones no
oficiales que no serán discutidas en el presente proyecto. A continuación se
detallan todas y cada una de ellas:
Figura 14: Abanico de dispositivos Android
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 42
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Nombre: Versión API
Apple Pie 1.0 1
Banana Bread 1.1 2
Cupcake 1.5 3
Donut 1.6 4
Eclair 2.0/2.1 7
Froyo 2.2 8
Gingerbread 2.3 9-10
Honeycomb 3.x 11-13
Ice Cream Sandwich 4.0 14-15
Jelly Bean 4.1 16
Todos los dispositivos Android incluyen una versión específica del S.O., la
cual a su vez, tiene una versión de la API de desarrollo. En general, una versión
de Android no podrá ejecutar aplicaciones que hayan sido desarrolladas para
una API superior, aunque esto puede ser modificado con la sentencia
MinSdkVersion y TargetSdkVersion en el manifiesto de la aplicación.
Cabe destacar, que Google desarrolla Android para un determinado
hardware con características conocidas. Por ejemplo, las primeras versiones de
Android fueron diseñadas para funcionar en los dispositivos HTC Dream y HTC
Magic. Posteriormente, Google sacó al mercado la serie Nexus (One, S, Galaxy
Nexus y la última incorporación, la Nexus 7 Tablet), también conocidos como
google phones, sobre el cual se desarrollaron las siguientes versiones.
La principal repercusión, es que cada compañía debe portar a su
hardware específico una versión de Android. Esto ha creado mucha diversidad y
segmentación en el mercado, puesto que las compañías no actualizan un
hardware antiguo con la última versión disponible bien por falta de potencia o
memoria o bien para poder vender uno nuevo.
Figura 15:Versiones de Android
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 43
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Figura 16: Distribución de versiones Android Octubre 2012
3.4.2. Arquitectura Android
La pila de la plataforma Android se divide en 4 capas, de arriba a abajo:
Aplicaciones:
Marco de Aplicaciones (Framework)
Librerías y entorno de ejecución
Kernel de Linux
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 44
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.4.2.1. Capa Aplicaciones
En la capa de más alto nivel, se incluyen todas las aplicaciones del
dispositivo, tanto las que tienen interfaz de usuario como las que no, las nativas
(programadas en C o C++) y las administradas (programadas en Java), las que
vienen preinstaladas en el dispositivo y aquellas que el usuario ha instalado.
En esta capa está también la aplicación principal del sistema: Inicio
(Home) o lanzador (launcher), porque es la que permite ejecutar otras
aplicaciones mediante una lista y mostrando diferentes escritorios donde se
pueden colocar accesos directos a aplicaciones o incluso widgets, que son
también aplicaciones de esta capa.
Figura 17: Arquitectura Android
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 45
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.4.2.2. Capa Marco de Aplicaciones
La siguiente capa está formada por todas las clases y servicios que
utilizan directamente las aplicaciones para realizar sus funciones. La mayoría de
los componentes de esta capa son librerías Java que acceden a los recursos de
las capas anteriores a través de la máquina virtual Dalvik. Siguiendo el diagrama
encontramos:
Activity Manager. Se encarga de administrar la pila de actividades de
nuestra aplicación así como su ciclo de vida.
Windows Manager. Se encarga de organizar lo que se mostrará en
pantalla. Básicamente crea las superficies en la pantalla que posteriormente
pasarán a ser ocupadas por las actividades.
Content Provider. Esta librería es muy interesante porque crea una
capa que encapsula los datos que se compartirán entre aplicaciones para tener
control sobre cómo se accede a la información.
Views. En Android, las vistas los elementos que nos ayudarán a
construir las interfaces de usuario: botones, cuadros de texto, listas y hasta
elementos más avanzados como un navegador web o un visor de Google Maps.
Notification Manager. Engloba los servicios para notificar al usuario
cuando algo requiera su atención mostrando alertas en la barra de estado. Un
dato importante es que esta biblioteca también permite jugar con sonidos,
activar el vibrador o utilizar los LEDs del teléfono en caso de tenerlos.
Package Manager. Esta biblioteca permite obtener información sobre
los paquetes instalados en el dispositivo Android, además de gestionar la
instalación de nuevos paquetes. Con paquete nos referimos a la forma en que
se distribuyen las aplicaciones Android, estos contienen el archivo .apk, que a su
vez incluyen los archivos .dex con todos los recursos y archivos adicionales que
necesite la aplicación, para facilitar su descarga e instalación.
Telephony Manager. Con esta librería podremos realizar llamadas o
enviar y recibir SMS/MMS, aunque no permite remplazar o eliminar la actividad
que se muestra cuando una llamada está en curso.
Resource Manager. Con esta librería podremos gestionar todos los
elementos que forman parte de la aplicación y que están fuera del código, es
decir, cadenas de texto traducidas a diferentes idiomas, imágenes, sonidos o
layouts. En un post relacionado a la estructura de un proyecto Android veremos
esto más a fondo.
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 46
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Location Manager. Permite determinar la posición geográfica del
dispositivo Android mediante GPS o redes disponibles y trabajar con mapas.
Sensor Manager. Nos permite manipular los elementos de hardware
del teléfono como el acelerómetro, giroscopio, sensor de luminosidad, sensor
de campo magnético, brújula, sensor de presión, sensor de proximidad, sensor
de temperatura, etc.
Cámara. Con esta librería podemos hacer uso de la(s) cámara(s) del
dispositivo para tomar fotografías o para grabar vídeo.
Multimedia. Permiten reproducir y visualizar audio, vídeo e imágenes
en el dispositivo.
3.4.2.3. Capa Librerías
La siguiente capa, que se sitúa justo sobre el kernel la componen las
bibliotecas nativas de Android, también llamadas librerías. Están escritas en C o
C++ y compiladas para la arquitectura hardware específica del teléfono. Estas
normalmente están hechas por el fabricante, quien también se encarga de
instalarlas en el dispositivo antes de ponerlo a la venta. El objetivo de las
librerías es proporcionar funcionalidad a las aplicaciones para tareas que se
repiten con frecuencia, evitando tener que codificarlas cada vez y garantizando
que se llevan a cabo de la forma “más eficiente”.
Entre las librerías incluidas habitualmente están OpenGL (motor gráfico),
Bibliotecas multimedia (formatos de audio, imagen y video), Webkit
(navegador), SSL (cifrado de comunicaciones), FreeType (fuentes de texto),
SQLite (base de datos), entre otras.
3.4.2.4. Entorno de Ejecución
Como se puede apreciar en el diagrama, el entorno de ejecución de
Android no se considera una capa en sí mismo, dado que también está formado
por librerías. Aquí están las librerías con las funcionalidades habituales de Java
así como otras específicas de Android.
El componente principal del entorno de ejecución de Android es la
máquina virtual Dalvik, creada por el ingeniero islandés Dan Bornstein. Las
aplicaciones se programan en Java y son compiladas en un formato específico
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 47
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
(.dex o Dalvik Executable) muy optimizado. El uso de esta máquina virtual viene
de la necesidad de utilizar un hardware no muy potente con escasos recursos,
cosa que la máquina virtual de Java no contempla. Otra característica
importante, es la capacidad de ejecutar múltiples instancias con un mínimo
impacto sobre el rendimiento de la memoria del dispositivo. Por ende, Android
está optimizado para mantener siempre libre la máxima memoria posible.
La ventaja principal es que las aplicaciones se compilan una única vez y
de esta forma estarán listas para distribuirse con la total garantía de que podrán
ejecutarse en cualquier dispositivo Android que disponga de la versión mínima
del sistema operativo que requiera la aplicación.
Figura 18: Máquina virtual Dalvik
La máquina virtual Dalvik fue diseñada para correr en una CPU lenta con
relativamente poca memoria RAM y un SO con poco espacio swap mientras
todo el conjunto esta siendo alimentado por una batería. Es primordial por
tanto la optimización de la memoria y del uso de la CPU. Es gracias a esto que
muchas de las aplicaciones en Android son tan fluidas.
Cabe aclarar que Dalvik es una variación de la máquina virtual de Java,
por lo que no es compatible con el bytecode Java. Java se usa únicamente como
lenguaje de programación, y los ejecutables que se generan con el SDK de
Android tienen la extensión .dex que es específico para Dalvik, y por ello no
podemos correr aplicaciones Java en Android ni viceversa.
3.4.2.5. Kernel de Linux
El núcleo del sistema operativo Android está basado en el kernel de Linux
versión 2.6, similar al que puede incluir cualquier distribución de Linux, como
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 48
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Ubuntu, solo que adaptado a las características del hardware en el que se
ejecutará Android, es decir, para dispositivos móviles.
El núcleo actúa como una capa de abstracción entre el hardware y el
resto de las capas de la arquitectura. El desarrollador no accede directamente a
esta capa, sino que debe utilizar las librerías disponibles en capas superiores. De
esta forma también se evita el hecho de tener que conocer las características
precisas de cada teléfono. Si se necesita hacer uso de la cámara, el sistema
operativo se encarga de utilizar la que incluya el teléfono, sea cual sea. Para
cada elemento de hardware del teléfono existe un controlador (o driver) dentro
del kernel que permite utilizarlo desde el software.
El kernel también se encarga de gestionar los diferentes recursos del
teléfono (energía, memoria, etc.) y del sistema operativo en sí: procesos,
elementos de comunicación (networking), etc.
3.4.3. Aplicaciones Android
3.4.3.1. Elementos de una aplicación
Las aplicaciones Android se construyen mediante bloques esenciales de
componentes, cada uno de los cuales existe como una entidad propia y
desempeña un papel específico; cada elemento es una pieza única que ayuda a
definir el comportamiento general de la aplicación. Es importante mencionar
que algunos de estos elementos son el punto de entrada para que los usuarios
interactúen con la aplicación y en muchos casos dependen unos elementos de
otros.
Se distinguen 5 elementos en una aplicación Android y cada uno de ellos
tiene un ciclo de vida diferente:
1. Activities (Actividades)
Heredan de la clase android.app.Activity, su objetivo es construir la
interfaz de usuario, presentar los elementos visuales y reaccionar a las acciones
del usuario. No toda aplicación tiene porqué contener un activity, es decir, no
toda aplicación tiene porque tener una interfaz de usuario. Estas aplicaciones se
empaquetan en forma de proveedores de contenido o servicios. Todo activity
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 49
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
puede llamar a otro activity a través de la creación de un Intent, de hecho, todo
activity es iniciado como respuesta a la creación de un Intent.
El punto de entrada de toda actividad es el método onCreate(), no existe
ningún método main() como tal. Solo se llama una vez y pretende inicializar la
aplicación, crear vistas, se enlazan datos, etc. Este método también permite
comprobar el estado de una aplicación. Una vez terminado, se llama al método
onStart(). De la clase Activity heredada, se heredan también métodos para el
control de la aplicación como onResume(), onPause(), onStop(), onDestroy(),
etc…, que pueden ser vistos en el ciclo de vida de una actividad en la figura
siguiente.
Figura 19: Ciclo de vida de Activity
Con los métodos descritos antes, la aplicación puede pasar por 4 estados
como se ve en el ciclo de vida:
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 50
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Activo: la actividad ha sido iniciada por el usuario y esta ejecutándose
actualmente.
Pausado: la actividad se esta ejecutando y es visible, pero una
notificación, un mensaje, o algún otro motivo está sobrepuesta en alguna
parte de la pantalla. Durante este estado, la actividad se puede ver pero
no se puede interactuar con ella.
Detenido: en este caso, la aplicación no es visible pero se esta
ejecutando en un segundo plano. La aplicación aún puede mostrar
información al usuario a través del uso de notificaciones pero no
directamente.
Terminada: la actividad es eliminada del sistema una vez cerrada por el
usuario o por el sistema por falta de memoria disponible.
Todo activity se asocia a un archivo .XML que contiene la información
necesaria para construir la interfaz gráfica: botones, textos, imágenes, etc….
Para ello, se utiliza la sentencia setContentView().
2. Intents
Mecanismo para el paso de mensajes, declara la intención de realizar una
acción, sirviendo para iniciar Activities o comunicarlas entre ellas. Se encargan
de notificar a las aplicaciones de varios eventos: cambios de estado en el
hardware (ej. cuando se inserta una tarjeta SD al teléfono), notificaciones de
datos entrantes (ej. cuando llega un SMS) y eventos en las aplicaciones (ej.
cuando una actividad es lanzada desde el menú principal).
Así como se pueden crear activities que respondan a los intents, también
se pueden crear intents que lancen actividades o usarlas para detonar eventos
ante algunas situaciones específicas (ej. el teléfono notifica por medio de un
mensaje cuando la localización actual esté a 10 metros del punto de destino). El
objetivo principal es desacoplar componentes.
La estructura de un intent se compone de dos componentes: la acción a
realizar y los datos que expresan lo que la acción debe operar. Existen acciones
nativas como las que se muestran a continuación o pueden ser creadas por el
usuario (lanzar otro activity o enviar datos de un activity a otro). Para este tipo
de acciones que no son genéricas, Android requiere que estas sean registradas
primero en el archivo AndroidManifest.xml bajo la etiqueta <intent-filter>
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 51
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Es importante mencionar que el sistema es el que elige entre las
actividades disponibles en el teléfono y dará respuesta a la intención con la
actividad más adecuada
3. Content providers (Proveedores de contenido)
Único mecanismo para compartir datos entre aplicaciones, este elemento
ofrece la capacidad de almacenar datos en el dispositivo a los que se puede
acceder y ser compartidos por las aplicaciones. Se pueden guardar datos en
archivos del sistema, en una base de datos en SQLite, en la web o en cualquier
otro lugar de almacenamiento persistente a la que la aplicación pueda tener
acceso. A través del proveedor de contenido, otras aplicaciones pueden
consultar o incluso modificar los datos (solamente si el proveedor de
contenidos de esa aplicación lo permite).
El modelo de desarrollo en Android invita a los desarrolladores a pensar
siempre en hacer los datos de nuestras aplicaciones disponibles para otras
aplicaciones. De manera que cuando se crea un proveedor de contenido, se
pueda tener un control completo de loa datos y definir la forma en que éstos
serán accedidos.
Un ejemplo es el proveedor de contenido para gestionar la información
de contactos (agenda) del teléfono. Cualquier aplicación con los permisos
adecuados puede realizar una consulta a través del proveedor de contenido
ContactsContract.Data para leer y escribir información sobre una persona en
particular.
4. Services (Servicios)
Un servicio no tiene interfaz gráfica y suele ejecutarse en segundo plano,
es decir, funcionan en background por tiempo indefinido. Se ejecutan en el
mismo hilo que un activity pero tienen más prioridad. Un ejemplo de servicio
ACTION_VIEW: content://contacts/people/1
ACTION_DIAL: tel://687123456
ACTION_ANSWER: tell://incoming
Figura 20: Acciones nativas Android
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 52
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
puede ser obtener el estado de un sensor con una frecuencia determinada y
mostrar el resultado. Es similar al concepto de Daemon en Linux o un servicio de
Windows.
Pueden ser lanzados de dos maneras: utilizando startService() el servicio
empieza a correr, hará su función y será terminado automáticamente cuando
termine o cuando el usuario lo indique. La segunda forma, usando bindService(),
el usuario podrá interactuar mediante la interfaz que exporta el servicio (con el
método onBind() ), teniendo que terminarlo el propio usuario.
Figura 21: Ciclo de vida de un servicio
5. BroadcastReceiver
Este componente responde a las notificaciones de difusión de todo el
sistema como por ejemplo que la pantalla se ha apagado, que la batería del
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 53
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
teléfono está por terminarse o que una fotografía ha sido tomada. Las
aplicaciones también pueden lanzar este tipo de notificaciones, un ejemplo de
ello es el aviso de que alguna información ha terminado de descargarse en el
dispositivo y se encuentran disponibles para su utilización.
Aunque los broadcaster receivers no muestran una interfaz de usuario,
pueden crear notificaciones en la barra de estado del teléfono para avisar al
usuario cuando un evento de este tipo se genera. Se puede pensar en estos
elementos como el medio por el cual otros componentes pueden ser iniciados
en respuesta a algún evento. Cabe mencionar que cada una de las emisiones de
los broadcaster receivers se representa como un intent.
3.4.3.2. Estructura de una aplicación
En la siguiente figura se pueden observar las diferentes partes que
compone un proyecto Android.
Figura 22: Estructura aplicación Android
1. Carpeta /src/: Contiene todo el código fuente de la aplicación, código
de la interfaz gráfica, clases auxiliares, etc. Inicialmente, el entorno de trabajo
(Eclipse) creará automáticamente el código básico de la pantalla (Activity)
principal de la aplicación, siempre bajo la estructura del paquete Java definido.
2. Carpeta /res/: Contiene todos los ficheros de recursos necesarios
para el proyecto: imágenes, vídeos, cadenas de texto, etc. Los diferentes tipos
de recursos de deberán distribuir entre las siguientes carpetas:
a. /res/drawable/. Contienen las imágenes de la aplicación.
b. /res/layout/. Contienen los ficheros de definición de las diferentes
pantallas de la interfaz gráfica.
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 54
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
c. /res/anim/. Contiene la definición de las animaciones utilizadas
por la aplicación.
d. /res/menu/. Contiene la definición de los menús de la aplicación.
e. /res/values/. Contiene otros recursos de la aplicación como por
ejemplo cadenas de texto (strings.xml), estilos (styles.xml), colores
(colors.xml), etc.
f. /res/xml/. Contiene los ficheros XML utilizados por la aplicación.
g. /res/raw/. Contiene recursos adicionales, normalmente en
formato distinto a XML, que no se incluyan en el resto de carpetas
de recursos.
3. Carpeta /gen/: Contiene una serie de elementos de código
generados automáticamente al compilar el proyecto. Cada vez que se genera un
proyecto, la maquinaria de compilación de Android genera una serie de ficheros
fuente en Java dirigidos al control de los recursos de la aplicación. El más
importante es el fichero R.java el cual mantiene una serie de constantes con los
id de todos los recursos de la aplicación, así como de todos los elementos que
haya en la interfaz gráfica.
4. Carpeta /assets/: Contiene todos los demás ficheros auxiliares
necesarios para la aplicación (y que se incluirán en su propio paquete), como
por ejemplo ficheros de configuración, de datos, etc. Este contenido no estará
indexado en la clase R.java, por lo que para acceder a ellos será necesario
utilizar un ContentProvider.
5. Fichero AndroidManifest.xml: Es un documento xml en el que se
declaran los elementos de la aplicación, así como sus restricciones, permisos,
procesos, acceso a datos e interacciones con elementos de otras aplicaciones.
Cada elemento se declara con una etiqueta única. No debe confundirse este
documento con el xml asociado a cada actividad. Los elementos gráficos y
distribución de la pantalla serán definidos para cada actividad dentro de su xml,
pero no en el AndroidManifest.
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 55
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
Figura 23: AndroidManifest.xml
3.4.3.3. Interfaz del usuario
La interfaz de usuario es la principal sección de interacción entre persona
y dispositivo. A todas las funcionalidades disponibles se accede a través de la
pantalla, que es por donde se muestra. Es muy importante conseguir que el
manejo sea intuitivo y sencillo, y que el aspecto visual sea atractivo.
Para construirla, se emplean diferentes objetos que veremos a
continuación, todos ellos descendientes de la clase View. Fundamentalmente
hay 2: los propios objetos de tipo View, como por ejemplo botones o etiquetas,
y que son la base de una subclase llamada widgets; y los de tipo ViewGroup,
que es una clase que extiende a View, y que son la base de una subclase
llamada layouts. La estructura de la interfaz puede resumirse en el cuadro que
se muestra a continuación.
Figura 24: Estructura de la interfaz
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 56
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
1. Layouts en xml.
Un layout es un recurso con el que puedes describir lo que se quiere
mostrar por pantalla y cómo se quiere mostrar. La manera más común de
crearlo es a través de un archivo XML (en el directorio res/layout del proyecto).
Para enlazar un layout en formato xml con una actividad se utiliza el
método setContentView(R.layout.id_del_layout), lo cual debe ser lo primero que
realice el método onCreate() de la actividad.
Todos los layouts tienen unos parámetros específicos. Los únicos que son
comunes a todos son layout_height y layout_width, que sirven para especificar
el valor de la altura y anchura del entorno, respectivamente. Aunque se pueden
emplear valores numéricos, con “wrap_content”, el tamaño se ajusta a las
dimensiones del contenido. Con “fill_parent”, será tan grande como lo permita
su padre o contenedor. Estas 2 opciones son más recomendables que el ajuste
manual. También se pueden establecer y consultar los márgenes, bordes y la
posición del layout, entre otras opciones, mediante métodos y funciones a los
que, en esta ocasión, se llaman desde el código de la aplicación.
Cada componente tiene su propia variedad de atributos en XML. El
atributo “id” se encarga de distinguirlos del resto, otorgándole un nombre
único. Una vez establecido (mediante, por ejemplo, android:id=
"@+id/nombre"), para referenciarlo desde el código de la aplicación es preciso
hacerlo de esta manera:
Tipo myTipo = (Tipo) findViewById(R.id.nombre);
Existen otros muchos atributos, que varían dependiendo del componente
con el que estemos tratando, y con los que podemos establecer el color de
fondo, tamaño, gravedad y un sinfín de opciones más.
2. Eventos de usuario
Cuando un usuario interactúa con la pantalla, existen métodos para
capturar la interacción del usuario y realizar una función concreta. Una de las
maneras más comunes es con los EventListener, una interfaz de la clase View a
través de la cual se pueden detectar diferentes tipos de pulsación sobre el
dispositivo. Métodos como onClick() (cuando se hace click sobre un texto,
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 57
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
imagen, texto, botón, etc..), onKey() (si el usuario presiona una tecla del
dispositivo mientras el cursor esta situado sobre el elemento deseado) y
onTouch() (el usuario toca cualquier parte de la pantalla, mueve el dedo, etc…)
sirven para la interacción dispositivo-usuario.
3. Menús
Los menús son la forma más habitual de proporcionar al usuario una
serie de acciones a realizar, ya sea sobre una aplicación o sobre las opciones del
propio dispositivo. Para crearlo, la mejor opción es definirlo en un archivo xml
que irá contenido en el directorio res/menú del proyecto. Los elementos que lo
componen son <menú>, que es el contenedor principal del resto de elementos;
<ítem>, que representa cada una de las opciones que ofrece el menú, y
<group>, que posibilita agrupar los “ítems” del menú a gusto del usuario, y que
puede ser visible o no.
Hay 3 tipos de menús: menú principal, menú contextual y submenús, los
dos primeros pueden ser observados en la figuras mientras que el tercero es
una lista de opciones que surge cuando el usuario acciona un elemento del
menú.
.
Figura 26: Menú principal Figura 25: Menú contextual
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 58
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
4. Diálogos y Notificaciones
Los diálogos son avisos o comprobaciones que surgen de una
determinada aplicación, en forma de ventana. La principal diferencia entre ellos
y las notificaciones es que las segundas son meramente informativas, no se
ejecutan en primer plano, y no requieren interacción directa con el usuario,
mientras que los primeros sí se realizan en primer plano y pueden necesitar esa
interacción para llevar a cabo una tarea, aunque se puede decir que un diálogo
es un tipo de notificación.
Un diálogo se crea con la instrucción “onCreateDialog(numero)” como
parte de una actividad, y se muestra por pantalla utilizando
“showDialog(numero)”, donde “numero” representa un identificador único de
cada dialogo. Para rechazarlos, se puede hacer con dismiss() o
dismissDialog(int). Si se desea modificar el texto a mostrar o cualquier otro
atributo, existe una colección de métodos variable en función del tipo concreto
de diálogo que facilitan la labor. Android también permite crear cuadros de
diálogo personalizados (creando su propio fichero xml).
Hay dos tipos de notificaciones: Toast notification y Status Bar
notification. La primera de ellas, crea un pequeño cuadro de texto sobre la
pantalla que estamos trabajando para mostrar un mensaje. No cierra ni
modifica la actividad que estemos llevando a cabo, ni acepta interacción con el
usuario, se desvanece en un periodo corto (o largo) de tiempo.
El segundo tipo añade un mensaje en la ventana de notificaciones del
sistema, que al seleccionarlo, lanzará la aplicación que lo ha activado. Puede
configurarse de tal manera que el dispositivo suene, vibre o alerte al usuario de
alguna manera.
Figura 28: Toast Notification Figura 27: Status bar notification
PROYECTO FIN DE CARRERA GUILLERMO GUERRERO GONZÁLEZ 59
APLICACIÓN ANDROID PARA ACCESO A SOLUCIÓN CRM
3.4.4. Distribución de aplicaciones
Las aplicaciones desarrolladas para dispositivos Android tienen su propio
formato de distribución, .APK (application package file). Es el formato usado
para la distribución e instalación de aplicaciones y librerías en cualquier
dispositivo Android.
El sistema Android requiere que toda aplicación sea firmada digitalmente
con un certificado cuya clave privada sea del desarrollador de la aplicación. Es la
manera de identificar al autor de dicha aplicación aunque este certificado no
tiene por qué ser firmado por una entidad certificadora. El propio SDK de
Android proporciona las herramientas necesarias para crear un certificado y
firmar las aplicaciones. En caso de no estar firmada, una aplicación no podrá ser
instalada.
Una vez compilado el código, todo el resultado (ficheros .dex) junto con
los recursos (imágenes, sonidos, etc…), el manifiesto de la aplicación
(AndroidManifest.XML) y los certificados correspondientes son almacenados
dentro de un fichero .APK, que no tiene por qué tener el nombre del programa
que contiene. Realmente, los ficheros APK tienen el formato de un fichero
comprimido .JAR (basado en .ZIP).