capitulo3/capitulo3.tex

   1 \chapter{Herramientas y tecnologías utilizadas}
   2
   3 \section{Full-stack frameworks}
   4
   5
   6 Un \emph{full-stack framework\footnote{Framework en Castellano es traducido como marco de trabajo}}, es una solución que incluye seguridad, enrutamiento de URIs, caché, hooks y muchas otras características. Cuando se usa un framework de estas características el desarrollador se adhiere a los estándares y guías que el framework marca para escribir e implementar el código. Además este tipo de frameworks ofrecen todas las librerías y herramientas que el programador necesita para (en este caso que nos ocupa) desarrollar páginas y servicios Web. Ejemplos de estos frameworks en PHP son:
   7
   8 \begin{itemize}
   9     \item CakePHP.
  10     \item Symfony.
  11 \end{itemize}
  12
  13
  14
  15 \section{Glue frameworks}
  16
  17 Como contra parte a \emph{full-stack frameworks} encontramos los \emph{glue frameworks} donde se da más libertad al programador para implementar su propio código, clases, helpers, o librerías. Un \emph{glue framework} no te ata ni hace que el código siga unos estándares determinados. Usualmente estos tipos de frameworks requieren de más código y más diseño y desarrollo en el lado de los desarrolladores; sin embargo, el desarrollador no está limitado a ningún tipo de funcionalidad o estándares. Unos pocos ejemplos de \emph{glue frameworks} son:
  18
  19 \begin{itemize}
  20     \item Zend.
  21     \item Codeigniter.
  22 \end{itemize}
  23
  24
  25 \section{Symfony}
  26
  27 Symfony es un marco de trabajo para el desarrollo de aplicaciones Web escrito en PHP que sigue el paradigma del modelo vista controlador (MVC) Su objetivo es incrementar la velocidad y la eficiencia del desarrollo web. Symfony trae muchas características muy útiles que ayudan a que el desarrollador se concentre en la lógica del negocio de la aplicación en lugar de en la implementación o en los objetos paginadores Web o en las abstracciones con la capada de base de datos. Sin embargo, todo tiene un coste, y es el aprendizaje de cómo usar todas las características que hacen de Symfony un marco de trabajo muy útil~\cite{C3:SymfonyBook14}.
  28
  29 El objetivo de Symfony es acelerar la creación y mantenimiento de aplicaciones web y remplazar tareas de codificación repetitivas. Está diseñado para optimizar el desarrollo de aplicaciones web a través de varias características clave. Así, Symfony separa las reglas de negocio de la aplicación web, de la lógica del servidor y de las vistas o presentación al usuario. Contiene numerosas herramientas y clases que permiten acortar el tiempo de desarrollo y aplicaciones web compleja. También automatiza tareas comunes así que el desarrollador puede enfocar su actividad enteramente en las tareas relacionadas con casos específicos de la aplicación. Como resultado final de estas características, con Symfony no hay necesidad de reinventar la rueda cada vez que una nueva aplicación web es construida.
  30
  31 Está escrito completamente en PHP y actualmente se usa en sitios web con alta demanda de páginas. Es compatible con la mayoría de servidores de bases de datos disponibles a la fecha como MySQL, PostgreSQL, Oracle y Microsoft SQL Server. Se ejecuta en entornos *NIX y Windows.
  32
  33 \subsection{Características de Symfony}
  34
  35 Symfony ha sido diseñado para alcanzar los siguiente requisitos:
  36
  37 \begin{itemize}
  38     \item Fácil instalación y configuración en la mayoría de plataformas.
  39     \item Independiente del tipo de servidor de base de datos.
  40     \item Simple de usar en la mayoría de casos, pero flexible para adaptarse a casos complejos.
  41     \item Cumple con la mayoría de prácticas recomendadas para el desarrollo Web así como con muchos patrones de diseño también recomendado para este tipo de desarrollos.
  42     \item Código leíble, con phpDocumentor para fácil mantenimiento.
  43     \item Fácil de extender y permite la integración con librerías de otros vendedores.
  44 \end{itemize}
  45
  46 \subsection{Características de proyectos Web automatizados}
  47
  48 A continuación se enumeran la mayoría de las características comunes que existen entre proyectos web y que pueden ser automatizadas:
  49
  50 \begin{itemize}
  51     \item Capa de internacionalización ya construida dentro de Symfony para datos, traducción de interfaces y localización del contenido.
  52     \item La capa presentación usa plantillas y layouts que pueden ser construidos por diseñadores HTML sin necesidad de ningún conocimiento del framework. Los helpers recuden la cantidad de código de presentación que hay que escribir.
  53     \item Los formularios soportan validación automatizada, asegurando una buena calidad de los datos almacenados en la base de datos y un experiencia de usuario más agradable.
  54     \item Existe una cache de gestión que reduce el uso de ancho de bando y la carga del servidor.
  55     \item Las listas son más fáciles de usar gracias a la paginación, clasificación y filtrado automatizados.
  56 \end{itemize}
  57
  58 \subsection{Object-Relational Mapping, ORM}
  59
  60 Las bases de datos son relacionales. PHP y Symfony por otro lado están orientados a objetos. Para acceder a una base de datos en la forma en la que se haría si estuvieran orientadas a objetos se necesita un interfaz de traducción de la lógica de objetos a la relacional. Este interfaz es el ORM.
  61
  62 Un ORM está constituido de objetos que dan acceso a datos y de reglas de negocio. Un beneficio de una capa de abstracción objeto-relacional es que previene de usar una sintaxis que es específica a una base de datos determinada. Esto significa que migrando de un sistema de base de datos en el medio de un proyecto debería ser fácil.
  63
  64 En el ORM, la capa de abstracción, encapsula la lógica de los datos. El resto de la aplicación no necesita saber las queries SQL y usando los objetos en lugar de las records de la base de datos y clases en lugar de tablas tiene otro beneficio: se pueden añadir nuevos métodos de acceso a las tablas. Por ejemplo si se tiene una tabla llamada Cliente con dos campos, Nombre y Apellido, se puede añadir un nuevo campo NombreCompleto que se componga de los dos sin necesidad de hacer ninguna modificación en la tabla o en la base de datos, simplemente añadiendo un nuevo método al objeto que representa la tabla de la base de datos que devuelva el Nombre y el Apellido concatenados como NombreCompleto.
  65
  66 Symfony soporta dos ORMs escritos en PHP que son open source: Propel y Doctrine. Integra ambos y cuando se crea un nuevo proyecto se elige qué ORM usar.
  67
  68 \subsection{El patrón MVC}
  69
  70 Symfony se basa en el patrón de diseño web clásico conocido como arquitectura MVC, la cual consiste de tres niveles:
  71
  72 \begin{itemize}
  73 \renewcommand{\labelitemi}{$-$}
  74     \item El \textbf{Modelo} representa la información con la cual la lógica de negocio de la aplicación opera.
  75     \item La \textbf{Vista} renderiza el modelo en una página web adecuada para interactuar con el usuario.
  76     \item El \textbf{Controlador} responde a acciones del usuario e invoca cambios en el modelo o en la vista según corresponda.
  77 \end{itemize}
  78
  79 Además de dividir la aplicación en esos tres niveles arriba citados, el diseño MVC define las interacciones entre cada uno de ellos. En la Figura~\ref{fig:MVC}) se representa el patrón MVC.
  80 \begin{figure}[H]
  81     \centering
  82         \includegraphics[width=0.8\textwidth]{fig/MVC}
  83     \caption{\emph{El patrón MVC}}
  84     \label{fig:MVC}
  85 \end{figure}
  86
  87 \subsubsection{El Modelo}
  88
  89 Representa la estructura subyacente de una aplicación Web. Los modelos a menudo son compartidos entre diferentes subaplicaciones de una aplicación Web. Por ejemplo, un modelo LoginForm puede ser usado tanto en el front end como en el back end de una aplicación, también pueden hacer uso del model APIs Web, etc. El modelo debería contener propiedades para representar datos específicos, lógica de negocio como reglas de validación para asegurar que los datos representado se adecuan a los requerimientos de diseño y puede contener código para la manipulación de los datos. En ocasiones, el modelo puede alcanzar proporciones demasiado grandes conteniendo mucho código en una única clase. También puede ser duro de mantener si el código que contiene sirve a diferentes propósitos~\cite{C3:YiiFramework}. De este modo para grandes aplicaciones es conveniente generar una clase base que represente parte del modelo que sea compartido por todas las diferentes subaplicaciones y en cada subapliación se extiende dicha clase base con el código específico para esa subaplicación.
  90
  91 \subsubsection{La Vista}
  92
  93 Representa el modelo en el formato que el usuario final desea. Las vistas, en general deberían cumplir estos puntos:
  94
  95 \begin{itemize}
  96     \item Principalmente deben contener código de la capa de presentación, como HTML y código PHP simple para formatear y renderizar daros.
  97     \item Debería evitar contener código que realiza queries explícitas a la base de datos. Este código debe estar situado en el modelo.
  98     \item La vista puede acceder a propiedades y métodos de controladores y modelos directamente. Sin embargo, esto debería ser realizado solo para presentación.
  99 \end{itemize}
 100
 101 \subsubsection{El Controlador}
 102
 103 Los controladores enlazan el modelo, la vista y otros componentes de la aplicación. Tratan directamente con peticiones del usuario.
 104
 105 \begin{itemize}
 106     \item Se debe evitar el uso de sentencias SQL directamente en esta capa. Éstas deben ser mantenidas preferiblemente en el modelo.
 107     \item No debería contener código HTML o cualquier otro código relacionado con la capa de presentación. Este código es mejor mantenerlo siempre en las vistas.
 108 \end{itemize}
 109
 110 En una aplicación MVC diseñada correctamente los controladores no contienen mucho código mientras que los modelos sí lo hacen y contienen la mayor parte del código responsable para la representación y manipulación de los datos. Esto se debe a que la estructura de datos y la lógica de negocio representada por los modelos suele ser muy específica para una determinada aplicación, y necesita grandes cambios para lograr los requerimientos de dicho programa; mientras que la lógica del controlador a menudo sigue un modo de funcionamiento similar a través de diferentes aplicaciones y por tanto puede ser simplificado por el framework subyacente o por las clases base~\cite{C3:YiiFramework}.
 111
 112
 113 \section{Bases de datos relacionales}
 114 Una base de datos relacional es una colección de datos organizados en forma de tablas desde las cuales los datos pueden ser accedidos fácilmente. Las bases de datos relacionales son creadas usando el modelo relacional\footnote{Para más información acerca del modelo relacional ver: \url{http://en.wikipedia.org/wiki/Relational_model}} y el software usado para la utilización de estas bases de datos se conoce como Sistema de Gestión de Bases de Datos Relacionales (RDBMS por sus siglas en Inglés) Por ejemplo en el mundo open source,  MySQL y PostgreSQL son unos de los más extendidos RDBMS pero no los únicos. De hecho PostgreSQL es algo más que un RDBMS puro como el lector podrá comprobar a través de las siguientes secciones.
 115
 116 Una base de datos contiene una o más tablas de información. Las filas en una tabla son llamadas \emph{records} y las columnas en la tabla campos o atributos. En la Figura~\ref{fig:tableDescription}) se representa una tabla típica de una base de datos relacional. Una base de datos que contiene únicamente una tabla es llamada una base de datos plana. Una que contiene dos o más se conoce como Base de Datos Relacional. Para el acceso a sus datos se hace uso del \emph{Standard Query Language} o SQL\footnote{Más acerca del lenguaje SQL en: \url{http://en.wikipedia.org/wiki/SQL}} por sus siglas en Inglés, con dicho lenguaje se pueden manipular los datos de una base datos con operaciones básicas como pueden ser: SELECT, INSERT, UPDATE y DELETE.
 117
 118 \begin{figure}[H]
 119     \centering
 120         \includegraphics[width=0.8\textwidth]{fig/table_description}
 121     \caption{\emph{Una tabla típica de una base de datos relacional}}
 122     \label{fig:tableDescription}
 123 \end{figure}
 124
 125
 126 \subsection{Terminología básica de las bases de datos relacionales}
 127
 128 \begin{itemize}
 129     \item \textbf{Filas:} también conocidas como tuplas o \emph{records} Cada fila en una tabla es distinta a otra en la misma tabla pero tienen el mismo tipo de datos.
 130     \item \textbf{Columnas:} son conocidas como atributos. Cada columna en una tabla tiene un nombre único (representa un único atributo de esa tabla)y éste debería ser descriptivo. El ordenamiento de las filas y las columnas es irrelevante a la funcionalidad de la base de datos.
 131     \item \textbf{Clave primaria:} más comúnmente conocida por su nombre en Inglés \emph{primary key}, es una clave usada para identificar una fila de forma única en una tabla.
 132     \item \textbf{Clave extranjera:} o \emph{foreign key}. Así se conoce a la clave primaria cuando ésta es usada en otra tabla para establecer una \textbf{relación} entre dos \emph{records} o filas de diferentes tablas. En la Figura~\ref{fig:relationAmongTable}) se puede observar las relaciones entre diferentes tablas así como sus correspondientes \emph{keys} y \emph{foreing keys}.
 133 \end{itemize}
 134
 135 \begin{figure}[H]
 136     \centering
 137         \includegraphics[width=0.7\textwidth]{fig/relation_among_table}
 138     \caption{\emph{Relaciones entre tablas}}
 139     \label{fig:relationAmongTable}
 140 \end{figure}
 141
 142
 143 \section{PostgreSQL}
 144
 145 PostgreSQL (o de forma abreviada Postgres) es un Sistema de Gestión de Bases de Datos Relacionales y de Objetos (ORDBMS por sus siglas en Inglés) Un ORDBMS es un sistema similar a una base de datos relacional pero con un modelo orientado a objetos. Clases y herencia son soportados directamente en los esquemas de la base de datos y en el lenguaje para realizar queries. Los ORDBMS se encuentran a medio camino entre los Sistemas de Bases de Datos Orientados a Objetos (OODBMS) y los Relacionales (RDBMS)
 146
 147 PostgreSQL evolucionó desde un proyecto de la Universidad de California en el Departamento de Ciencias Computacionales de Berkeley. El primer sistema operacional basado en Postgres fue liberado en 1987 y no disponía de motor SQL si no de uno propio conocido como PostQUEL. En 1994 se añadió el interpretador SQL a Postgres y desde entonces y hasta ahora el proyecto ha crecido enormemente. Además, se libera con una licencia similar a las licencias MIT o BSD\footnote{\url{http://www.postgresql.org/about/licence/}}
 148
 149 PostgreSQL es considerado el más avanzado sistema de base de datos open source en el mundo. Proporciona muchas características que tradicionalmente solo pueden ser encontradas en productos comerciales para grandes empresas.
 150
 151 PostgreSQL es un proyecto open source. Open source por definición significa que se puede obtener el código fuente, usar el programa, y modificarlo libremente sin ningún límite por parte del propietario del software. Ahora bien, NO confundir software open source con software libre de coste. Es cierto que se puede descargar sin ningún coste, pero siempre habrá costes asociados con el tiempo y energía que una compañía pone en el soporte y mantenimiento de la aplicación. Si una empresa no tiene esos recursos para gastar siempre existen vendedores y consultores especializados en productos relacionados con PostgreSQL.
 152
 153 \subsection{Características de PostgreSQL}
 154
 155 El siguiente es un breve listado de algunas de las características que PostgreSQL implementa~\cite{C3:PPostgreSQL}:
 156
 157 \begin{itemize}
 158     \item \textbf{ORDBMS}: un ORDBMS es una Base de Datos Relacional y de Objetos; esto significa que PostgreSQL permite acceso a datos mediante un modelo relacional y de objetos, y es capaz de manejar rutinas y reglas complejas. Ejemplos de su avanzada funcionalidad son las consultas SQL declarativas, el soporte multi usuario, la optimiazación de consultas, herencia y arrays.
 159     \item \textbf{Altamente extensible}: PostgreSQL permite que el usuario pueda definir sus propios operadores, funciones, métodos de acceso y tipos de datos.
 160     \item \textbf{Integridad referencial}: soporte de integridad referencial, el cual es usado para asegurar la validez de los datos el base de datos.
 161     \item \textbf{API flexible}: la flexibilidad de la API de PostgreSQL ha permitido a múltiples vendedores proporcionar fácilmente soporte de desarrollo. Estos interfaces incluyen Python, Perl, PHP, ODBC, Java/JDBC, Ruby, C/C++, Object Pascal, etc.
 162     \item \textbf{Cliente/Servidor}: PostgreSQL usa una arquitectura cliente/servidor de un proceso por usuario. Existe un proceso master que realiza \emph{forks} para proporcionar conexiones adicionales en cada intento de conexión por parte del cliente al servidor PostgreSQL.
 163     \item \textbf{MVCC}: Control de Concurrencia de Versión Múltiple, es la tecnología que PostgeSQL usa para evitar innecesario \emph{locking}. En servidores tales como MySQL o Access, existen momentos en los que el lector tiene que esperar para acceder a la información en la base de datos. La espera es causada por otros usuarios que están escribiendo a la base de datos. Dicho a groso modo, el lector es bloqueado por escritores que están actualizando \emph{records} en tablas de la base de datos.
 164     \item \textbf{WAL}: \emph{Write Ahead Logging} consiste en escribir el histórico de las acciones realizadas por una base de datos antes de que incluso estas acciones se hayan producido. Llevando el diario (la historia) de los cambios antes de que estos sean escritos a la base de datos incrementa la fiabilidad de PostgreSQL respecto a otros competidores. Incluso en caso de un \emph{crash} de la base datos existirá un histórico de las transacciones desde el cual podremos recuperar seguramente los datos.
 165 \end{itemize}
 166
 167 \section{PostGIS}
 168
 169 PostGIS es un software open source que añade soporte de objetos geográficos a la base de datos PostgreSQL. Se libera bajo la licencia \emph{GNU General Public License} (GPL-2.0) Se trata de una base de datos espacial, es decir, una base de datos que define tipos de datos especiales para objetos geométricos y permite almacenar datos geométricos (usualmente de naturaleza geográfica) en tablas de bases de datos convencionales. Proporciona funciones e índices especiales para realizar consultas y manipular los datos geométricos usando SQL (\emph{Structured Query Language}) Una base de datos espacial es a menudo usada solo como un contenedor para almacenar datos espaciales, pero puede hacer mucho más que eso. Aunque una base de datos espacial no necesita ser relacional, la mayoría de las bases de datos espaciales lo son~\cite{C3:PostGIS}.
 170
 171 Una base de datos espacial proporciona herramientas de almacenaje y de análisis. La presentación de datos visualmente no es una meta de las bases de datos espaciales. Permite hacer consultas del tipo: ``Dame una lista de localizaciones donde la distancia media a una pizzería es menor a 16 kilómetros''.
 172
 173 \subsection{Consultas, análisis y procesado espacial}
 174
 175 Una \emph{query} espacial es una consulta a la base de datos que usa funciones geométricas para responder cuestiones acerca del espacio y de objetos en el espacio. Bases de datos espaciales como PostGIS añaden un conjunto de funciones al lenguaje estándar SQL que trabajan con objetos geométricos en una base de datos de forma similar a funciones que trabajan con datos. Por ejemplo, con una fecha, hay funciones que cuentan cuantas horas/días/minutos/años/semanas hay entre dos fechas o si esta fecha se encuentra en el futuro o en el pasado. PostGIS añade a PostgreSQL funciones de este tipo pero relacionadas con datos geográficos.
 176
 177 Además de ser capaz de responder cuestiones acerca del uso del espacio, las funciones espaciales permiten crear y modificar objetos en el espacio. Esta porción del análisis espacial es a menudo referida como procesado geométrico o espacial~\cite{C3:PostGIS}.
 178
 179
 180 \subsection{Fortalezas de PostgreSQL para su uso como base de datos espacial}
 181
 182 La principal razón por la cual PostgreSQL fue elegido como punto de partida para la creación de una base de datos espacial fue la facilidad para crear extensiones a su funcionalidad base. PostgreSQL permite, por ejemplo, crear nuevos tipos y operadores. Otras características de PostgreSQL de las cuales PostGIS hace uso son enumeradas a continuación:
 183
 184 \begin{itemize}
 185     \item \textbf{Soporte de arrays}. Únicamente Oracle, IBM DB2 y PostgreSQL permiten el tratamiento complejo de arrays. Por ejemplo, en PostgreSQL se pueden definir arrays de strings, números, fechas, datos geométricos o incluso datos propios creados por el desarrollador. Además permite la conversión de cualquier lista de filas pertenecientes a una tabla en un array, lo cual es particularmente práctico cuando se manipulan datos geométricos.
 186     \item \textbf{Herencia de tablas}. PostgreSQL tiene una funcionalidad conocida como herencia de tablas, la cual es equivalente a una multi herencia de objetos. La herencia de tablas permite tratar un conjunto de tablas como una única así como definir jerarquías de herencia anidadas.
 187     \item \textbf{Capacidad para definir funciones agregadas que toman más de una columna}.
 188     \item \textbf{Habilidad para la definición de nuevos tipos de datos}.
 189     \item \textbf{Capacidad para escribir funciones con argumentos por defecto}. Esta característica fue introducida en PostgreSQL 8.4 y mejorada en PostgreSQL 9.0.
 190     \item \textbf{Miles de funciones que pueden encontrarse por defecto en PostgreSQL}. Existen funciones para la manipulación de strings, expresiones regulares y para el análisis de datos astronómicos.
 191 \end{itemize}
 192
 193 \section{Android}
 194
 195 Android es una plataforma de código abierto diseñada para dispositivos móviles. Nació de la alianza de 30 organizaciones del sector de los dispositivos móviles bajo la \emph{Open Handset Alliance}. La meta de esta alianza es ``acelerar la innovación en dispositivos móviles y ofrecer a los consumidores una experiencia más rica, menos cara y mejor''. Android es el vehículo para lograrlo.
 196
 197 Android esta revolucionando el espacio ocupado por los dispositivos móviles. Por primera vez hay una verdadera plataforma abierta que separa el software del hardware sobre el que se ejecuta. Esto permite que un número más grande de dispositivos puedan ejecutar las mismas aplicaciones y crea un ecosistema mucho más rico para los desarrolladores y los consumidores.
 198
 199 Android es una plataforma \textbf{integral}, lo que significa que es un software que contiene todo lo necesario para funcionar en un dispositivo móvil.
 200
 201 \begin{itemize}
 202     \item Para los desarrolladores, Android proporciona todas las herramientas y \emph{frameworks} para el desarrollo rápido y sencillo de aplicaciones móviles. El \emph{SDK} de Android es todo lo que se necesita para empezar a desarrollar aplicaciones para Android; no se necesita si quiera un teléfono físico.
 203     \item Para los usuarios, Android funciona sin necesidad de ninguna configuración adicional, pero los usuarios si lo desean también pueden modificar las configuraciones de sus teléfonos.
 204     \item Para los fabricantes, Android es una solución integral para hacer funcionar sus dispositivos. A parte de ciertos elementos hardware que requieren drivers específicos, Android proporciona todo lo necesario para poder ejecutarse en los dispositivos que los fabricantes desarrollan.
 205 \end{itemize}
 206
 207 \subsection{Plataforma de código abierto}
 208
 209 El conjunto del software del cual está compuesto Android, desde los módulos Linux de bajo nivel y las librerías nativas, hasta los programas que sirven para escribir aplicaciones Android, son totalmente abiertos.
 210
 211 Además Android se distribuye bajo la licencia Apache/MIT, así que otros pueden libremente extenderlo y usarlo para una gran variedad de propósitos. Incluso algunos librerías open source que fueron portadas al \emph{stack} de Android fueron reescritas bajo los términos de esta licencia.
 212
 213 Así, como desarrollador, cualquiera puede acceder al código fuente de la plataforma. Esto permite a los programadores ver cómo funciona internamente el sistema operativo Android. Por otro lado a los fabricantes les facilita el esfuerzo y tiempo requeridos para portar el sistema operativo Android a sus respectivos hardwares~\cite{C3:LearningAndroid}.
 214
 215 \subsection{Diseñado para dispositivos móviles}
 216
 217 Durante las fases de desarrollo de Android, lo primero que se hizo fue tener en cuenta las limitaciones de los dispositivos móviles que probablemente no iban a cambiar en el futuro a corto y medio plazo. Por un lado, los dispositivos móviles funcionan con baterías, y la capacidad de éstas no mejorará demasiado en el futuro cercano. Por otro, el tamaño pequeño de los dispositivos móviles significa que siempre estarán limitados en términos de memoria y velocidad. Estas dos principales limitaciones estuvieron siempre bajo consideración durante todo el desarrollo de la plataforma.
 218
 219 Android fue diseñado para ejecutarse en toda clase de dispositivos físicos. No hace suposiciones acerca del tamaño de la pantalla del dispositivo, resolución, chipset, etc. Su núcleo está diseñado para ser portable.
 220
 221 \subsection{Historia de Android y evolución}
 222
 223 En 2005, Google compra una pequeña compañía que desarrollaba aplicaciones para dispositivos móviles. El mundo comienza a especular acerca de la pronta liberación de un ``gPhone'' y de la entrada de Google en el mercado de los \emph{smartphones} o teléfonos inteligentes. Eric Schmidt, el CEO de Google, desde el primer momento dejó claro que las ambiciones de Android eran mucho mayores que el desarrollo de un único teléfono. En su lugar, ellos planificaban el desarrollo de una plataforma que permitiría su uso en mucho teléfonos y en muchos otros dispositivos.
 224
 225 Hasta el 2007 no surgen nuevas noticias. Pero es en este año cuando la \emph{Open Handset Alliance} es anunciada en todos los medios de comunicación y el código fuente de Android es oficialmente liberado.
 226
 227 En el 2008, la versión 1.0 del SDK de Android es liberada. Poco después, el teléfono G1 fabricado por HTC es vendido en todo el mundo.
 228
 229 A partir del 2009 comienzan a proliferar dispositivos basados en Android. Nuevas versiones del sistema operativo son liberadas: Cupcake (1.5), Donut (1.6) y Eclair (2.0 y 2.1). Durante este año más de 20 dispositivos a nivel mundial ya están haciendo uso del nuevo sistema operativo.
 230
 231 En 2010, Android es la segunda plataforma detrás de Blackberry en número de teléfonos móviles inteligentes vendidos. Froyo (Android 2.2) es liberado y más de 60 dispositivos durante este año hacen uso de esta versión de Android.
 232
 233 \subsection{La motivación de Google}
 234
 235 La principal motivación de Google para la creación y soporte del proyecto Android se basa en conseguir que Android llegue a todas partes y para ello necesita crear un software que pueda ejecutarse en tantos dispositivos móviles como sea posible. Google es una compañía de publicidad y su negocio consiste en vender anuncios. Si todo el mundo usa Android, Google puede proporcionar servicios adicionales en la cima de este software y de este modo a diferencia de otros vendedores de software que dependen del cobro de licencias, Google puede ofrecer su Android de forma gratuita~\cite{C3:LearningAndroid}.
 236
 237 Aunque Google licencia alguna aplicaciones propietarias como Gmail y Google Maps, y también consigue ganancias desde el Android Markey (ahora conocido como Google Play), su motivación principal sigue siendo el retorno por la publicidad que estas aplicaciones y otras muchas generan.
 238
 239 \subsection{Open Handset Alliance}
 240
 241 Para conseguir que Android sea algo más que una simple compañía propiedad de Google, Android es propiedad de la Open Handset Alliance, un grupo formado por operadores, fabricantes y otras compañías clave del sector de la telefonía y los dispositivos móviles. Los objetivos de la alianza son la constante mejora e innovación en la experiencia del usuario con los dispositivos móviles.
 242
 243 \subsection{Versiones de Android}
 244
 245 En la Tabla~\ref{tab:versionesAndroid} se muestra el número de versión y API de las diferentes \emph{releases} del sistema operativo Android. Así como el tanto por ciento de dispositivos que hace uso de esa versión del total de dispositivos móviles que funcionan con Android.
 246
 247 \begin{table}[h]
 248 \centering
 249 \scriptsize
 250     \begin{tabularx}{\textwidth}{|X|X|X|X|}
 251         \hline
 252         {\cellcolor[gray]{0.8}}\textbf{Versión de Android} & {\cellcolor[gray]{0.8}}\textbf{API} & {\cellcolor[gray]{0.8}}\textbf{Nombre} & {\cellcolor[gray]{0.8}}\textbf{Distribución}\\
 253         \hline
 254         Android 1.0 & 1 & & 0.1\% \\
 255         Android 1.1 & 2 & & 0.1\% \\
 256         Android 1.5 & 3 & Cupcake & 0.1\% \\
 257         Android 1.6 & 4 & Donut & 0.4\% \\
 258         Android 2.0 & 5 & Eclair & 3.4\% \\
 259         Android 2.0.1 & 6 & Eclair & 3.4\% \\
 260         Android 2.1 & 7 & Eclair & 3.4\% \\
 261         Android 2.2 & 8 & Froyo (frozen yogurt) & 12.9\% \\
 262         Android 2.3 & 9 & Gingerbread & 0.3\% \\
 263         Android 2.3.3 & 10 & Gingerbread & 55.5\% \\
 264         Android 3.0 & 11 & Honeycomb & 0.4\% \\
 265         Android 3.1 & 12 & Honeycomb & 0.4\% \\
 266         Android 3.2 & 13 & Honeycomb & 1.5\% \\
 267         Android 4.0.0 & 14 & Ice Cream Sandwich & 23.7\% \\
 268         Android 4.0.4 & 15 & Ice Cream Sandwich & 23.7\% \\
 269         Android 4.1 & 16 & Jelly Bean & 1.8\% \\
 270         \hline
 271     \end{tabularx}
 272     \caption{\emph{Versiones de Android.}}
 273     \label{tab:versionesAndroid}
 274 \end{table}
 275
 276 Lo más importante es el número o nivel de la API Android. Los números de versión cambian todo el tiempo, en ocasiones porque la API ha cambiado y otras veces porque se solucionan errores o se mejora la eficiencia del sistema operativo.
 277
 278 Un desarrollador de aplicaciones Android debe asegurarse de a cual nivel de API se dirige su aplicación. Ese nivel de API determinará sobre qué dispositivos puede o no ejecutarse la aplicación.
 279
 280 Normalmente, el objetivo es conseguir que la aplicación se ejecute en tantos dispositivos como sea posible. Así hay que tener en mente cual es la distribución de versiones Android en el mercado en cada momento, es decir, su fragmentación. En la Figura~\ref{fig:fragmentacionAndroid}) se muestran las diferentes versiones de Android y su uso en dispositivos móviles.
 281
 282 \begin{figure}[H]
 283     \centering
 284         \includegraphics[width=1\textwidth]{fig/fragmentacionAndroid}
 285     \caption{\emph{Distribución de versiones Android. Octubre 2012.}}
 286     \label{fig:fragmentacionAndroid}
 287 \end{figure}
 288
 289 Desde estos datos, un desarrollador Android probablemente elegirá como objetivo mínimo para su aplicación las versión de Android 1.6 y 2.0 a menos que realmente se necesiten características de las últimas versiones.
 290
 291 \subsection{Arquitectura}
 292
 293 En la Figura~\ref{fig:AndroidSystemArchitecture}) se muestran los principales componentes de la arquitectura Android. El color verde muestra la capa escrita en C o C++, el azul indica código Java que se ejecuta sobre la Máquina Virtual Dalvik.
 294
 295 \begin{figure}[H]
 296     \centering
 297         \includegraphics[width=1\textwidth]{fig/AndroidSystemArchitecture}
 298     \caption{\emph{Arquitectura del sistema Android.}}
 299     \label{fig:AndroidSystemArchitecture}
 300 \end{figure}
 301
 302 Android hace uso de la versión 2.6 del kernel de Linux, modificado debido a requisitos especiales en la gestión de la energía, la memoria y el entorno de ejecución. Justo por encima del kernel se ejecutan algunos demonios como \emph{bluez} para dar soporte a dispositivos Bluetooth y \emph{wpa\_supplicant} para la encriptación WiFi.
 303 Como Android debe ejecutarse en dispositivos con poca memoria y CPUs con bajo poder de ejecución, las librerías como la libc fueron modificadas para reducir el consumo de memoria. También el código relacionado con la reproducción de audio y vídeo (los \emph{codecs} y \emph{decodecs}) se ejecuta con código nativo y ha sido fuertemente optimizado.
 304 Android hace uso de la máquina virtual Dalvik, la cual es un interpretador de un byte code que ha sido transformado desde el byte code de Java al byte code especial de Dalvik. Dalvik en sí mismo es compilado como código C/C++ nativo mientras que las librerías son escritas en Java e interpretadas por Dalvik.
 305
 306 En la capa \emph{Framework} o marco de trabajo se encuentra código y aplicaciones escritas en Java. Esta capa proporciona la abstracción necesaria para hacer uso de las librerías nativas y de las capacidades de Dalvik para desarrollar y ejecutar aplicaciones. Todos los programas para Android se ejecutan en su propia \emph{sandbox}, es decir, se ejecutan a parte del resto de aplicaciones; de tal modo que si una aplicación Android es comprometida digamos por un cracker el resto de aplicaciones permanecen inafectadas. Las aplicaciones Android se componen de actividades, servicios, receptores de broadcast y proveedores de contenido. Estos componentes pueden interactuar con otros de la misma o de diferentes aplicaciones vía intents.
 307
 308 \subsection{Android y Java}
 309
 310 En Java, se escribe un programa en Java, se compila a byte code usando el compilador Java y luego este byte code se ejecuta sobre la Maquina Virtual Java (Java VM en Inglés). En Android, es algo distinto. En Android hay que escribir código en Java, y hay que compilarlo a byte code de Java usando el mismo compilador Java. Pero después el byte code de Java debe ser recompilado de nuevo usando el compilador Dalvik para generar byte code Dalvik. Este byte code de Dalvik es posteriormente ejecutado en la Máquina Virtual Dalvik (Dalvik VM en Inglés). En la Figura~\ref{fig:DalvikJava}) se muestra una comparación entre el estandar Java (a la izquierda) y en Android usando Dalvik (a la derecha)~\cite{C3:LearningAndroid}.
 311
 312 \begin{figure}[H]
 313     \centering
 314         \includegraphics[width=0.5\textwidth]{fig/DalvikJava}
 315     \caption{\emph{Java versus Dalvik}}
 316     \label{fig:DalvikJava}
 317 \end{figure}
 318
 319 La buena noticia para el programador es que para él no hay diferencia entre programar en Java o en Android, pues los pasos adicionales de compilación se encuentran totalmente automatizados si se hace uso de Eclipse o Ant.
 320
 321 ¿Por qué no compilar directamente desde código Java a byte code de Dalvik? En el 2005, cuando se comenzó a trabajar en la máquina virtual Dalvik, el lenguaje Java estaba sufriendo constantes modificaciones, pero el byte code de Java era más o menos estable. Por tanto, los desarrolladores de Android eligieron basar Dalvik en byte code de Java en lugar de en código fuente de Java.
 322
 323 Un efecto positivo de esta elección, es que en teoría se podrían escribir aplicaciones Android en cualquier otro lenguaje que pudiera generar byte code de Java. Por ejemplo, se podría usar Python o Ruby. En realidad, en la práctica sería necesario disponer de las librerías apropiadas en el SDK de Android pero probablemente en el futuro acaben apareciendo.
 324
 325 También, hay que tener en cuenta que el código Java de Android hace uso de clases Java que no son estándar. Java normalmente contiene:
 326
 327 \begin{itemize}
 328     \item \emph{Java Standard Edition}: usado para el desarrollo de aplicaciones de usuario.
 329     \item \emph{Java Enteriprise Edition o J2EE/JavaEE}: usado para el desarrollo de aplicaciones para empresas.
 330     \item \emph{Java Micro Edition J2ME/JavaME}: para dispositivos móviles
 331 \end{itemize}
 332
 333 El conjunto de librerías de Android está más cercano la \emph{Java Standard Editio}. La principal diferencia es que las librerías de interfaz de usuario de Java (AWT y Swing) han sido extraídas y reemplazadas con librerías de interfaz de usuario específicas de Android. Además Android añade algunas nuevas características al estándar de Java. De este modo, el desarrollador tiene a su disposición la mayoría de las librerías estándar de Java y algunas otras nuevas.
 334
 335 \subsection{El marco de trabajo de las aplicaciones (\emph{application framework})}
 336
 337 El \emph{application framework} es un entorno que proporciona numerosos servicios que ayudan al programador a realizar correctamente su trabajo. Es la capa que permite a los desarrolladores crear aplicaciones que atraigan a los usuarios.
 338
 339 En la capa \emph{application framework} se encuentran numerosas librerías Java especialmente construidas para Android. También hay muchos servicios que proporcionan acceso a muchas de las capacidades del sistema sobre el que se está ejecutando Android: localización, sensores, WiFi, telefonía, etc. Esta es la capa que fundamentalmente usarán todos los desarrolladores de Android.
 340
 341 \subsection{Aplicaciones}
 342
 343 Finalmente, según lo mostrado en la Figura~\ref{fig:AndroidSystemArchitecture}), nos encontramos con la capa de aplicaciones creadas por los desarrolladores. Estas aplicaciones son las que finalmente interactúan con el usuario. Pueden venir preinstaladas en el dispositivo o pueden ser descargadas desde uno de los muchos \emph{Android markets}.