3. Estado del Arte -...

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



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



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



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,…).

http://www.sugarcrm.com/crm/products/editions

http://civicrm.org/features



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

http://hipergate.morfeo-project.org/

http://www.sap.com/solutions/bp/customer-relationship-management/index.epx

http://www.sap.com/solutions/bp/customer-relationship-management/index.epx

http://www.salesforce.com/es/crm/sales-force-automation/



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

http://crm.dynamics.com/es-es/home

http://www.oracle.com/us/products/applications/crmondemand/index.html



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).



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.



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.



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:



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:



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



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



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.



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



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



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



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



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



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.



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



(.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



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



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:



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>



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

tel://687123456/



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



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.



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.



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



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,



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



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



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).

3. Estado del Arte -...

Documents

Transcript of 3. Estado del Arte -...