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.
-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.
+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. En este proyecto en concreto, se usará el ORM Doctrine.
+
+\cleardoublepage
\subsection{El patrón MVC}
\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.
\end{itemize}
+\cleardoublepage
+
\subsubsection{El Controlador}
Los controladores enlazan el modelo, la vista y otros componentes de la aplicación. Tratan directamente con peticiones del usuario.
\section{Bases de datos relacionales}
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.
-Una base de datos contiene una o más tablas de información. Las filas en una tabla son llamadas \emph{records} o filas y las columnas en la tabla \emph{campos} o \emph{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.
+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.
\begin{figure}[H]
\centering
\label{fig:relationAmongTable}
\end{figure}
+\cleardoublepage
\section{PostgreSQL}
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.
-Además de ser capaz de responder cuestiones acerca del uso del espacio, las funciones espaciales permite 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}.
+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}.
\subsection{Fortalezas de PostgreSQL para su uso como base de datos espacial}
\section{Android}
+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.
+
+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.
+
+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.
+
+\begin{itemize}
+ \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.
+ \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.
+ \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.
+\end{itemize}
+
+\subsection{Plataforma de código abierto}
+
+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.
+
+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.
+
+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}.
+
+\subsection{Diseñado para dispositivos móviles}
+
+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.
+
+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.
+
+\subsection{Historia de Android y evolución}
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+\subsection{La motivación de Google}
+
+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}.
+
+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.
+
+\subsection{Open Handset Alliance}
+
+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.
+
+\subsection{Versiones de Android}
+
+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.
+
+\begin{table}[H]
+\centering
+\scriptsize
+ \begin{tabularx}{\textwidth}{|X|X|X|X|}
+ \hline
+ {\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}\\
+ \hline
+ Android 1.0 & 1 & & 0.1\% \\
+ Android 1.1 & 2 & & 0.1\% \\
+ Android 1.5 & 3 & Cupcake & 0.1\% \\
+ Android 1.6 & 4 & Donut & 0.4\% \\
+ Android 2.0 & 5 & Eclair & 3.4\% \\
+ Android 2.0.1 & 6 & Eclair & 3.4\% \\
+ Android 2.1 & 7 & Eclair & 3.4\% \\
+ Android 2.2 & 8 & Froyo (frozen yogurt) & 12.9\% \\
+ Android 2.3 & 9 & Gingerbread & 0.3\% \\
+ Android 2.3.3 & 10 & Gingerbread & 55.5\% \\
+ Android 3.0 & 11 & Honeycomb & 0.4\% \\
+ Android 3.1 & 12 & Honeycomb & 0.4\% \\
+ Android 3.2 & 13 & Honeycomb & 1.5\% \\
+ Android 4.0.0 & 14 & Ice Cream Sandwich & 23.7\% \\
+ Android 4.0.4 & 15 & Ice Cream Sandwich & 23.7\% \\
+ Android 4.1 & 16 & Jelly Bean & 1.8\% \\
+ \hline
+ \end{tabularx}
+ \caption{\emph{Versiones de Android.}}
+ \label{tab:versionesAndroid}
+\end{table}
+
+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.
+
+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.
+
+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.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1\textwidth]{fig/fragmentacionAndroid}
+ \caption{\emph{Distribución de versiones Android. Octubre 2012.}}
+ \label{fig:fragmentacionAndroid}
+\end{figure}
+
+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.
+
+\subsection{Arquitectura}
+
+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.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1\textwidth]{fig/AndroidSystemArchitecture}
+ \caption{\emph{Arquitectura del sistema Android.}}
+ \label{fig:AndroidSystemArchitecture}
+\end{figure}
+
+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.
+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.
+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.
+
+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.
+
+\subsection{Android y Java}
+
+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}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\textwidth]{fig/DalvikJava}
+ \caption{\emph{Java versus Dalvik}}
+ \label{fig:DalvikJava}
+\end{figure}
+
+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.
+
+¿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.
+
+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.
+
+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:
+
+\begin{itemize}
+ \item \emph{Java Standard Edition}: usado para el desarrollo de aplicaciones de usuario.
+ \item \emph{Java Enteriprise Edition o J2EE/JavaEE}: usado para el desarrollo de aplicaciones para empresas.
+ \item \emph{Java Micro Edition J2ME/JavaME}: para dispositivos móviles
+\end{itemize}
+
+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.
+
+\subsection{El marco de trabajo de las aplicaciones (\emph{application framework})}
+
+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.
+
+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.
+
+\cleardoublepage
+
+\subsection{Aplicaciones}
+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}.
projects / PFCLatex / .git / blobdiff