Programación de Dispositivos Móviles

Introducción

Dispositivo móvil (mobile device), también conocido como computadora de

bolsillo o computadora de mano (palmtop o handheld), es un tipo de computadora de

tamaño pequeño, con capacidades de procesamiento, con conexión a Internet ,

con memoria, diseñado específicamente para una función, pero que pueden llevar a

cabo otras funciones más generales.

Un sistema operativo móvil o SO móvil es un sistema operativo que controla

un dispositivo móvil al igual que los PCs utilizan Windows o Linux entre otros. Sin

embargo, los sistemas operativos móviles son mucho más simples y están más

orientados a la conectividad inalámbrica, los formatos multimedia para móviles y las

diferentes maneras de introducir información en ellos.

A medida que los teléfonos móviles crecen en popularidad, los sistemas operativos

con los que funcionan adquieren mayor importancia. La cuota de mercado de

sistemas operativos móviles en el segundo trimestre de 2014 era el siguiente:

1. Android 84,7 % (en países como España las diferencias son más

significativas, donde Android tiene el 90,8 % de la cuota de mercado.2 )

2. iOS 11,7 %

3. Windows Phone 2,5 %

4. BlackBerry OS 0,5 %

5. Otros 0,6 %

6. Firefox OS Disponible

7. Ubuntu Touch Disponible

Ahora que ya tenemos una idea de lo que es Android, es necesario entender cómo

funciona. Algunos de los conceptos te serán familiares, como el kernel de

Linux, SQL, etc. Algunos otros completamente extraños, como la idea de Android

del ciclo de vida de una aplicación. Ahondemos un poco.

[Arquitectura de Android]

El kernel Linux

Android está construido sobre el kernel de Linux. Linux provee la capa de abstracción

de hardware para Android permitiendo que este sea transferido / portado a una gran

variedad de plataformas en el futuro.

Internamente, Android utiliza Linux para su manejo de memoria, control de

procesos, trabajo con redes y otros servicios relativos al sistema operativo.

El usuario de un teléfono Android jamás verá Linux en su dispositivo y los programas

que desarrolles nunca podrán utilizar sus comandos directamente. Como

desarrollador tú debes saber que ahí está.

Las librerías nativas

Las librerías nativas son contenidas en la capa inmediata superior al kernel de Linux.

Estas librerías compartidas están escritas en C o C++, fueron compiladas para la

arquitectura de hardware utilizada por el dispositivo y preinstaladas en él por el

proveedor del mismo.

Algunas de las más importantes son:

Surface Manager: Es el manejador de ventanas compuesto para Android

(similar a Metro, Vista o Compiz).

Gráficos en 2D y 3D: Elementos de dos y tres dimensiones que pueden ser

combinados en una sola interfaz de Android.

Media codecs: Utilizada para grabación y reproducción de diversos formatos

de medios (como AAC, AVC, H.564, MP3, MP4, etc)

Base de datos SQL: Android incluye el motor de base de datos SQLite que

puede ser utilizado para almacenar datos en el dispositivo.

Motor de navegación: Para mostrar el contenido HTML, Android utiliza la

librería WebKit.

La máquina virtual

Al mismo nivel que las librerías nativas encontramos la máquina virtual Dalvik que

es la implementación Java de Google optimizada para los dispositivos móviles. Todo

el código que escribas en Android será escrito en Java que a su vez se ejecutará en

Dalvik.

Application Framework

Por encima de las librerías nativas y de la máquina virtual se encuentra el Application

Framework. Esta capa provee los bloques de construcción que se utilizan para crear

las aplicaciones. Este framework viene preinstalado con Android pero puede ser

expandido agregando componentes personalizados.

Las partes más importantes de este framework son:

Activity Manager: Controla el ciclo de vida de la aplicación.

Content providers: Encapsulan datos que se comparten entre aplicaciones.

Resource manager: Todo lo que viene con una aplicación que no sea código

(imágenes, videos, etc).

Location manager: Para saber en qué ubicación geográfica se encuentra el

dispositivo (GPS, servicios de ubicación).

Notification manager: Eventos tales como la llegada de un mensaje de

texto, citas, alertas, etc.

Aplicaciones y Widgets

La capa más alta en la arquitectura de Android es la que contiene las aplicaciones y

widgets. Los usuarios finales verán únicamente estos programas, sin darse

cuenta de todo lo que pasa tras bambalinas.

Las aplicaciones son programas que pueden abarcar toda la pantalla e interactuar

con el usuario. Por otra parte, los widgets son programas que operan únicamente

en una pequeña parte de la pantalla principal.

Cuando una persona adquiere un teléfono con Android, este viene con una serie de

aplicaciones por defecto tales como las siguientes:

Marcador de teléfonos

Mensajes de texto

Correo electrónico

Contactos

Agenda

Google Play

etc

El entorno

Antes de poner las manos sobre el código es necesario preparar el entorno completo

que consta de las siguientes partes:

1. Java Development Kit (JDK)

2. Eclipse IDE

3. Android SDK Tools

4. Plugin ADT para Eclipse

5. Configuración de un dispositivo virtual (AVD)

Diccionario Android

ADB y ADB shell, Android Depuration Bridge o Puente de Depuración de Android.

Es la herramienta utilizada para enviar comandos desde un ordenador a un

dispositivo con este sistema. El shell es un programa Terminal que hace de traductor

de nuestras órdenes, actúa sobre una línea de comandos.

AOSP, Android Open Source Project o Proyecto de Código Abierto

Android, Android es un sistema de código abierto, eso quiere decir que cualquier

desarrollador puede descargar su código fuente y modificarlo a su

gusto. Precisamente eso es lo que hace que Android sea un grande entre los

grandes, consiguiendo diferenciarse así de su competidor más directo, iOS de Apple,

que se trata de un sistema cerrado.

APK, Android Package Archive, es la extensión que los paquetes de los programas

que operan en este sistema reciben. Los cuales pueden ser abiertos y modificados

de una manera facil.

APN, Access Point Name o Nombre del Punto de Acceso, son los datos que nos

dan nuestras operadoreas para poder operar en 2G, 3G y LTE, para el uso de datos

e inte. En la mayoría de los casos estos datos vienen ya configurados.

APP, abreviatura de la palabra inglesa application, que quiere decir aplicación.

OTA, Over The Air o Sobre El Aire, es la acción de descargar datos a través del aire.

Las actualizaciones oficiales de Android normalmente se realizan mediante OTA, al

igual que la instalación de aplicaciones y sus actualizaciones.

SDK, Software Development Kit o Kit de Desarrollo de Software,Conjunto de

herramientas de desarrollo que permite al programador crear aplicaciones para un

sistema, en este caso Android.

BOOT, es el proceso que se realiza en el inicio de un ordenador o dispositivo

computarizado como puede ser un móvil Android. Su función es la de cargar el

programa de arranque que carga toda la configuración del hardware para un correcto

funcionamiento.

Bootloader, es el boot encargado del arranque en los dispositivos móviles.

Brick o semibrick, también conocida como pantalla de la muerte, es la

consecuencia de cargar una ROM de forma errónea. En casi la totalidad de los casos

es recuperable. (si haras cambio de alguna Rom es importane que realices un

Backup del CID)

CID, (Carrier ID) o Numero Unico identifica al proveedor del telefono, este número

lo contienen la mayoria de Smartphones tales como los Motorola, Sony Ericsson,

HTC, entre otros.

Dalvik, Máquina virtual encargada de la ejecución de las aplicaciones en la versión

2.1 y anteriores deAndroid.

Wipe Dalvik Cache, Limpia la caché de la máquina virtual Dalvik de Android, la

cual sirve para lanzar nuestras aplicaciones.

Wipe Cache Partition, En Esta opción se borra la memoria caché. En el caché

encontramos los archivos que son de uso más frecuente para tener un acceso rápido.

No se borrarán los datos personales.

Wipe Data/Factory Reset, Se borrarán todos sus datos personales y tal cual el

sistema volverá al estado original.

Fastboot, es un bootloader con el que podemos hacer flasheos de bajo nivel.

Hard Reset o Factory Reset, es el proceso de dejar el teléfono tal y como estaba

justo al momento de comprarlo como de fábrica, o bien para recuperarlo a como

esta ajusto después de haber instalado una rom.

Kernel, es el núcleo de los sistemas que se encarga de realizar las operaciones

relativas a la gestión del sistema operativo (gestión de memoria, planificador, etc.)

Launcher, es la parte encargada de la interfaz gráfica de usuario de Android, es

totalmente personalizable como ya hemos visto.

Wipe, es lo que comúnmente llamamos a “Formatear o Limpiar” en el ámbito de los

ordenadores, hacer wipe implica la pérdida de los datos almacenados.

Es importante mencionar que todo móvil con un sistema operativo cuenta con

particiones las cuales a veces modificamos sin saber que significa cada una de ellas

Api, es la abreviatura de Aplication Programming Interface. Un API no es más que

una serie de servicios o funciones que el Sistema Operativo ofrece al programador,

como por ejemplo, imprimir un caracter en pantalla, leer el teclado, escribir en un

fichero de disco, etc. Visto desde la perspectiva del código máquina, el API aparece

como una serie de llamadas (en otros sistemas operativos se hace mediante saltos

a supervisor; en OS/2 se implementan como Far Calls), mientras que si lo vemos

desde la de un lenguaje de alto nivel, el API aparece como un conjunto de

procedimientos y funciones.

Los 3 tipos de aplicaciones móviles: ventajas e inconvenientes

El mercado de las aplicaciones móviles no para de crecer. Son muchas las empresas

que no quieren dejar pasar la oportunidad de unirse a este negocio y crear una

aplicación que dé respuesta a sus necesidades. Sin embargo, la mayoría

desconocen qué tipos de aplicaciones móviles existen y cuál es la mejor para ellos.

En anteriores posts hemos hablado sobre las ventajas de tener una

aplicación para tu empresa, y hemos dado información sobre cuánto cuesta crear

una app. Para completar esta guía, definimos en profundidad qué tipos de

aplicaciones móviles hay y te damos algunos consejos para que selecciones la

que mejor le vaya a tu empresa o startup.

1. App nativas

Una aplicación nativa es la que se desarrolla de forma específica para un

determinado sistema operativo, llamado Software Development Kit o SDK. Cada

una de las plataformas, Adroid, iOS o Windows Phone, tienen un sistema diferente,

por lo que si quieres que tu app esté disponible en todas las plataformas se deberán

de crear varias apps con el lenguaje del sistema operativo seleccionado.

Por ejemplo:

Las apps para iOS se desarrollan con lenguaje Objective-C

Las apps para Android se desarrollan con lenguaje Java

Las apps en Windows Phone se desarrollan en .Net

Cuando hablamos de desarrollo móvil casi siempre nos estamos refiriendo a

aplicaciones nativas. La principal ventaja con respecto a los otros dos tipos, es la

posibilidad de acceder a todas las características del hardware del móvil: cámara,

GPS, agenda, dispositivos de almacenimiento y otras muchas. Esto hace que la

experiencia del usuario sea mucho más positiva que con otro tipo de apps.

Además las aplicaciones nativas no necesitan conexión a internet para que

funcionen.

La descarga e instalación de estas apps se realiza siempre a través de las tiendas

de aplicaciones (app store de los fabricantes). Esto facilita el proceso de

marketing y promoción.

Está claro que si el coste no es un obstáculo en tu empresa, o tienes la certeza de

que tu app será rentable, la mejor opción será siempre el desarrollo de una

aplicación nativa para cada plataforma (iOS, Android y Windows Phone). Si tu

presupuesto es limitado, las aplicaciones web tienen también grandes ventajas para

tu negocio.

2. Web App

Una aplicación web o webapp es la desarrollada con lenguajes muy conocidos por

los programadores, como es el HTML, Javascript y CSS. La principal ventaja con

respecto a la nativa es la posibilidad de programar independiente del sistema

operativo en el que se usará la aplicación. De esta forma se pueden ejecutar en

diferentes dispositivos sin tener que crear varias aplicaciones.

Las aplicaciones web se ejecutan dentro del propio navegador web del

dispositivo a través de una URL. Por ejemplo en Safari, si se trata de la plataforma

iOS. El contenido se adapta a la pantalla adquiriendo un aspecto de navegación APP.

¿Puede considerarse esto una APP? En realidad la gran diferencia con una aplicación

nativa (además de los inconvenientes que se muestran en la tabla) es que no

necesita instalación por lo que no pueden estar visibles en app store y la

promoción y comercialización debe realizarse de forma independiente. De todas

formas se puede crear un acceso directo que sería como “instalar” la aplicación en

el dispositivo.

Las apps web móviles son siempre una buena opción si nuestro objetivo es adaptar

la web a formato móvil.

3. Web App nativa

Una aplicación híbrida es una combinación de las dos anteriores, se podría decir

que recoge lo mejor de cada una de ellas. Las apps híbridas se desarrollan con

lenguajes propios de las webabpp, es decir, HTML, Javascript y CSS por lo que

permite su uso en diferentes plataformas, pero también dan la posibilidad de acceder

a gran parte de las características del hardware del dispositivo. La principal ventaja

es que a pesar de estar desarrollada con HTML, Java o CSS, es posible agrupar

los códigos y distribuirla en app store.

PhoneGap es uno de los frameworks más utilizados por los programadores para el

desarrollo multiplataforma de applicaciones híbridas. Otro ejemplo de herramienta

para desarrollar apps híbridas es Cordova.

¿Cuál es la mejor elección?

Para seleccionar el tipo de app más adecuada en tu situación, deberás analizar las

ventajas e inconvenientes de cada una y responder a varias preguntas:

¿Cuánto coste estás dispuesto a asumir?

¿Quieres aprovechar las funcionalidades del dispositivo (GPS, cámara…) o no lo

necesitas?

¿Cuál es el público al que se dirigirá tu app?

¿Necesitas un diseño complejo y muy personalizado?

¿Quieres incluir notificaciones en tu app?

¿Tienes previsto modificar las acciones de la aplicación móvil o incorporar más

funciones en el futuro?

Los componentes principales que tenemos que conocer son los que

siguen:

1. Activity: Los Activities (actividades) son los componentes principales de las

aplicaciones nativas para Android, gracias a ellos podemos crear interfaces

gráficas. Para la mayoría de los programadores de lenguajes visuales

(especialmente de escritorio) lo pueden comparar con las ventanas o

formularios.

2. View: Éstos componen la interfaz gráfica, y existen varios tipos como las

cajas de texto, botones, listview, etc. La mayoría de los que ofrece el SDK

por defecto son bastantes básicos, pero también nos permite crear controles

o views personalizados para obtener mayores funcionalidades.

3. Service: Éste concepto probablemente no se diferencia del concepto que ya

conocemos en sistemas operativos existentes hoy día, que son aplicaciones

sin interfaz gráfica que se ejecutan en segundo plano. El mismo puede hacer

lo mismo que cualquier otra aplicación gráfica.

4. Content Provider: Mediante éste podemos compartir datos entre

aplicaciones de manera encapsulada, así no se enteran como están

almacenadas o como trabajan internamente. Son accesibles por otras

aplicaciones como la misma que la crea.

5. Intent: El componente clave para la comunicación entre Activities de la

misma aplicación o con otras, la misma puede enviar mensajes, invocar

aplicaciones, servicios, etc.

6. Broadcast Receiver: Éste componente es muy útil, y tiene un alcance global

ya que es capaz de reaccionar a ciertos eventos (como los triggers de las

bases de datos) y hacer algo al respecto, por ejemplo puede detectarse la

batería baja, mensajes de textos recibidos, generar intents para que otras

aplicaciones los reciban, etc.

7. Widget: Son componentes visuales que se pueden mostrar en el escritorio

(Home Screen) para interactuar con el usuario o mostrar información.

Pero, ¿cómo sabe nuestra aplicación qué componentes tiene

disponibles? Para ello, existe el fichero AndroidManifest.xml. Este fichero será

el encargado de comunicarle al sistema operativo:

1. las componentes de las que dispone la aplicación

2. los permisos necesarios para la aplicación (cámara, GPS…)

3. la versión de Android mínima necesaria

4. el hardware y software requerido y/o usado

5. las librerías externas que utiliza (como Google Maps…)

Para ello, utilizaremos etiquetas, que en el caso de los componentes serán:

<activity> <service> <receiver> <provider>

Cada una de estas etiquetas tendrá una serie de atributos disponibles, donde

indicaremos qué componente en cuestión será de todos los disponibles, icono o un

sinfín de opciones disponibles. Además, si queremos indicar las capacidades de uno

de nuestros componentes, podemos hacer uso de la etiqueta <intent-filter>.

Recursos de una app

A la hora de hacer un buen programa, siempre hay que externalizar los recursos

del código, entendiendo por recursos imágenes, textos, estilos… De esta forma,

también podremos especificar diferentes recursos dependiendo del tipo de

dispositivo en el que estemos, sin necesidad de modificar el código. Para esto, el

ejemplo perfecto es la versión móvil y tablet de una misma pantalla (o Activity,

para ir entrando en la jerga): creamos una única Activity la cual utilizará una

distribución de su contenido diferente según el tipo de dispositivo que usemos.

Siempre podemos especificar un recurso genérico o por defecto. En contraposición

a éste, tendremos la opción de especificar que una versión concreta de un recurso

es para una configuración específica.

Para detallar la configuración específica podemos basarnos en idiomas, resolución,

orientación del dispositivo… Para ello, basta ver las posibilidades en esta página.

Básicamente radica en añadir unas terminaciones a las carpetas donde

almacenaremos los recursos, acordes a la configuración específica.

Todos los recursos irán bajo la carpeta /res. Pero, ¿qué recursos son los que

podemos incluir? :

Animaciones

Colores

Imágenes (Drawable)

Layouts (Disposición de elementos gráficos)

Menús

Cadenas de texto (String)

Estilos

Otros (booleanos, dimensiones…)

Para ello, deben ir en una estructura de carpetas específica, de forma que por

ejemplo para añadir cadenas de texto en español utilizaríamos la carpeta

/res/values-es o /res/drawable-xxhdpi para Drawables para pantallas de alta

resolución.

Estructura de un proyecto Android

Cuando creamos un nuevo proyecto para Android, ya sea desde eclipse o desde el

nuevo Android Studio, se nos crearán una serie de directorios necesarios para

posteriormente generar/compilar la aplicación. Vamos a repasar brevemente esa

estructura de directorios y nos centraremos en uno de los directorios más

importantes a la hora de crear una aplicación: el directorio de recursos.

1. El directorio /src/

Será el encargado de contener todo el código fuente de la aplicación que estamos

desarrollando. No solo insertaremos en él controlador de las pantallas

(actividades), sino que también colocaremos todas nuestras librerías auxiliares. O

demás código Java.

2. El directorio /gen/

Nota: si estamos utilizando Android Studio, el contenido de este directorio esta en /build/source/

Es un directorio que no debemos modificar. Ni su contenido. Ya que en él, el

compilador de Android creará automáticamente una serie de ficheros dirigidos al

control de recursos de la aplicación. Debemos destacar el fichero R.java (y su clase

R) ya que será donde se almacenarán cada uno de los identificadores de cada

recurso de la aplicación. Esto incluye contenedores, vistas, cadenas de texto,

estilos, imágenes... Cada vez que creemos un recurso, el sdk generará una entrada

en este fichero. Donde almacenará el identificador que hayamos dado al recurso y

un entero auto-asignado. Gracias a esta clase podremos acceder a los recursos

desde el código fuente de la aplicación.

public final class R {

public static final class attr {

}

public static final class dimen {

/** Default screen margins, per the Android Design guidelines.

Customize dimensions originally defined in res/values/dimens.xml

(such as

screen margins) for sw720dp devices (e.g. 10" tablets) in landscape

here.

*/

public static final int activity_horizontal_margin=0x7f040000;

public static final int activity_vertical_margin=0x7f040001;

}

public static final class drawable {

public static final int ic_launcher=0x7f020000;

}

public static final class id {

public static final int AbsoluteLayout1=0x7f080003;

public static final int action_settings=0x7f080005;

public static final int button1=0x7f080002;

public static final int button2=0x7f080004;

…

3. El directorio /assets/

Este es el directorio destinado a los ficheros de configuración o datos a cargar.

Aunque se pueden insertar cualquier tipo de elemento auxiliar necesario para la

aplicación. Estos ficheros serán accedidos mediante la ruta al directorio. Como

veremos posteriormente, habrá otros ficheros (ciertos tipos) que crearán

identificadores para su acceso ya que son pre-compilados. Dependiendo de la

aplicación nos puede resultar más apropiado tener recursos que se accedan

mediante un identificador o mediante su ruta en el sistema de ficheros y tener más

libertad de lectura (al no estar pre-compilados).

4. El directorio /bin/

Los elementos de este directorio, al igual que los elementos de /gen/, son

generados automáticamente por el IDE. Por lo que no debemos modificarlos. El

compilador utiliza este directorio para preparar los ficheros del proyecto que serán

empaquetados para crear la aplicación (.apk). Esto incluye compilar tu código Java

en ficheros .class y disponer los recursos (incluyendo imágenes) en una cierta

estructura para crear dicho fichero compilado .apk (que es la aplicación).

5. Directorio /res/

Android separa los recursos del código fuente, y para ello los organizaremos en

este directorio. Esto facilita el mantenimiento y además permite dar soporte a

diferentes configuraciones de idiomas o tamaños de pantalla.

Como se ha comentado en el apartado anterior, cada uno de los recursos que

añadamos el sistema crea, de forma automática, un id de recurso dentro de la clase

R. Dependiendo del tipo de recurso que estemos añadiendo a la aplicación, se

tendrán que distribuir en los siguientes subdirectorios básicos:

A) /res/drawable: Directorio destinado a almacenar los recursos de tipo imagen.

Podremos insertar 3 tipos de ficheros: - Ficheros en bitmap (.png, .jpg o .gif ). - Ficheros PNG en f ormato Nine-patch (.9.png).

- Ficheros XML con descriptores gráficos (Drawable) B) /res/layout/: Insertaremos los ficheros XML que especifican las pantallas (lo

veremos en posteriores tutoriales) de la interfaz gráfica. C) /res/anim/: Insertaremos cada uno de los ficheros XML que definen las

animaciones tween para las vistas. D) /res/menu/: Insertaremos los ficheros XML que definen los diferentes menús

(de opciones, sub-menus o de contexto) de la aplicación.

E) /res/xml/: Insertaremos los XML que no corresponden a ninguna otra de las demás categorías.

F) /res/raw/: Insertaremos los recursos adicionales, normalmente en formato distinto a XML, que no se incluyan en el resto de directorios de recursos.

G) /res/values/: Cada elemento de cada fichero insertado en este directorio será considerado como un único recurso. Por lo que creará una entrada en la clase R. Estos serán los ficheros que podrán estar presentes en este directorio y cada uno

de ellos contendrán las etiqueta XML de apertura y la etiqueta de cierre : - arrays.xml donde crearemos arrays de recursos. Por ejemplo podría ser utilizado

para una lista de cadenas fijas que aparece en una lista. Como los días de la semana.

<resources>

<array name="textArray">

<item>First</item>

<item>Second</item>

<item>Third</item>

<item>Fourth</item>

<item>Fifth</item>

</array>

<array name="daysArray">

<item>Monday</item>

<item>Tuesday</item>

<item>Wednesday</item>

<item>Thursday</item>

<item>Friday</item>

<item>Saturaday</item>

<item>Sunday</item>

</array>

</resources>

- colors.xml donde definiremos valores de colores.

<resources>

<color name="wh_red">#FF990000</color>

<color name="wh_blue_lighter">#FF6E9DC6</color>

<color name="wh_blue_light">#FF305581</color>

<color name="wh_blue">#FF204571</color>

<color name="pressed_whitehouse">#CC204471</color>

</resources>

- dimens.xml donde definiremos medidas.

<resources>

<dimen name="cuadro_texto">160sp</dimen>

</resources>

- strings.xml donde definiremos cadenas de texto que aparecen en la app.

<resources>

<string name="app_name">NotePad</string>

<string name="live_folder_name">Notes</string>

<string name="title_edit_title">Note title:</string>

<string name="title_create">Create note</string>

<string name="title_edit">Edit: \"%1$s\"</string>

<string name="title_notes_list">Notes</string>

</resources>

- styles.xml donde definiremos estilos para las vistas de la interfaz.

<resources>

<style name="CustomText">

<item name="android:textSize">20sp</item>

<item name="android:textColor">#008</item>

</style>

</resources>

A continuación un diagrama de flujo de cómo Android elige el recurso adecuado:

Teniendo claro cómo se gestionan los recursos, ¿cómo creamos algunos

recursos específicos? Veamos a continuación algunos de ellos: layouts, menus y

estilos.

Un layout define la estructura visual de una interfaz de usuario. A pesar de que

podríamos crearla dinámicamente por código, lo ideal es declarar los elementos

de la interfaz en un XML.

Para crear un layout, disponemos de muchos componentes gráficos ya en la API,

aunque podemos crear los nuestros propios. Tenemos layouts donde insertar

múltiples componentes, vistas de texto, botones… A continuación, podéis ver un

ejemplo de un layout que nos pondrá un texto y justo debajo un botón:

En este caso, un LinearLayout nos pondrá elementos uno detrás de otro (en este

caso al ser su orientación vertical, uno debajo de otro). A continuación un TextView

que de ancho y alto ocupa lo que necesite (wrap_content), con el texto Hello, I am

a TextView. Y similar para el botón. Cada uno con su identificador único.

Si queremos hacernos buenos a la hora de hacer layouts, lo ideal es

que empecemos trabajando con el editor gráfico de eclipse o Android Studio, pero

vayamos comprobando cómo queda el XML. Conforme pase el tiempo, os daréis

cuenta que a veces será más rápido escribir directamente en el XML.

Cuando vamos a definir un menú en una de nuestras Actividades, éste también se

define a través de un XML. Ejemplo:

Por último, cuando hablamos de estilos, nos estamos refiriendo al concepto más

parecido a lo que es CSS para una web: externalizar estilos para poder ser

reutilizados. Podremos definir estilos para asignarlos a entidades gráficas, así como

crear un tema para asignarlo a toda la aplicación.

A continuación podéis ver como mostrar un texto con un formato específico:

Y como queda tras utilizarlo con estilos, donde el estilo CodeFont podríamos

reutilizarlo en otras Views, o si decidiéramos cambiarlo, podríamos cambiarlo a

todos a la vez:

El archivo AndroidManifest.xml

Este archivo es generado automáticamente y modificable gráficamente

o programando. Y por lo tanto es importante conocerlo. Ya que el archivo presenta

información esencial sobre la aplicación al sistema operativo Android. Información

necesaria para que pueda ejecutar la aplicación.

Principales tareas que realiza AndroidManifest.xml:

- Utiliza el nombre de paquete Java como identificador único de la aplicación.

- Describe los componentes de la aplicación: Actividades, servicios, proveedores de

contenido... Para ello utiliza el nombre de las clases que implementan cada uno de

estos componentes y publica sus capacidades. Esto permite al sistema operativo

conocer que componentes tiene y bajo qué condiciones pueden ser lanzados.

- Especifica que permisos tiene la aplicación para acceder a partes protegidas del

API que proporciona el sistema Android.

- Declara la mínima versión del sistema operativo en el que funcionará la aplicación.

- Indica las librerías que utiliza el proyecto y por lo tanto tienen que ser

empaquetadas al crear la aplicación.

- Permite declarar una clase 'Instrumentation' que sirve para monitorizar la

interacción de la aplicación con el sistema. Esta declaración solo estará presente

mientras se desarrolla y prueba la aplicación. Ya que será borrada antes de que la

aplicación se vaya a publicar.

Partes de AndroidManifest.xml

Vamos a mostrar un ejemplo básico de 'manifiesto' y vamos a explicar cada una de sus partes:

<?xml version="1.0" encoding="utf-8"?>

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.loginandregisterapi"

android:versionCode="1"

android:versionName="1.0" >

<uses-sdk

android:minSdkVersion="10"

android:targetSdkVersion="17" />

<uses-permission android:name="android.permission.INTERNET"/>

<application

android:allowBackup="true"

android:icon="@drawable/ic_launcher"

android:label="@string/app_name"

android:theme="@style/AppTheme" >

<activity

android:name="com.example.loginandregisterapi.LoginActivity"

android:label="@string/app_name" >

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

</activity>

</application>

</manifest>

Cosas a tener en cuenta:

- El elemento padre (manifest) del archivo debe de contener una declaración del

espacio de nombres y del nombre que asigna al paquete que forma la aplicación.

- Cada manifiesto incluye un único elemento que contendrá información básica para

la aplicación como el icono, nombre o tema que utiliza.

- Cada una de las actividades (controladores de cada pantalla de la interfaz) que

aparecerán en la aplicación deberán de aparecer en el manifiesto.

Descripción de los elementos básicos:

1. Etiqueta manifest

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.loginandregisterapi"

android:versionCode="1"

android:versionName="1.0" >

Este el elemento raíz del manifiesto y sus dos atributos principales y obligatorios

son:

- xmlns:android: Define el espacio de nombres de Android y siempre debe ser el

mismo

- package: El nombre del paquete define la aplicación y actúa como identificador

único de la misma. Por lo que si haz publicado una aplicación con un nombre y

luego se cambia, los usuarios de la primera versión no podrán actualizar a la

siguiente.

2. Etiqueta uses-sdk

<uses-sdk

android:minSdkVersion="10"

android:targetSdkVersion="17" />

Elemento (etiqueta) de segundo nivel obligatorio que determina la compatibilidad

de la aplicación con una o más versiones del sistema operativo. Esta compatibilidad

viene expresada en base al nivel de API del sistema Android que soporta. Sus dos

atributos principales son:

- android:minSdkVersion (obligatorio): Determina el mínimo nivel de API que

debe de tener el sistema operativo Android que pretenda ejecutar la aplicación. El

sistema evitará que la aplicación se instale en un sistema que tenga un nivel de

API inferior del especificado.

- android:targetSdkVersion (opcional): Si no se especifica se toma el valor de

minSdkVersion. Determina el nivel del API con el que fue construida la aplicación.

Por lo que se espera que tome ventajas del nivel de API especificado pero es

totalmente retro-compatible con versiones antiguas hasta la indicada mediante

minSdkVersion.

3. Etiqueta uses-permission

<uses-permission android:name="android.permission.INTERNET"/>

Etiqueta opcional de segundo nivel que sirve para indicar un permiso necesario que

requiere la aplicación para acceder a alguna parte protegida del API que

proporciona el sistema Android. Esta declaración alertará a los usuarios que la

aplicación utilizará ciertos permisos. Evidentemente crearemos tantas etiquetas

como permisos necesitemos. El único atributo disponible y obligatorio es

android:name. El cual indica un permiso que necesita la aplicación.

4. Etiqueta application

<application

android:allowBackup="true"

android:icon="@drawable/ic_launcher"

android:label="@string/app_name"

android:theme="@style/AppTheme" >

Etiqueta de segundo nivel que contendrá otras etiquetas que declararán cada uno

de los componentes de la aplicación. Además permite atributos que pueden afectar

a todos los citados componentes de la aplicación. Solo se puede declarar una vez

este elemento en el manifiesto. Y admite multitud de atributos aunque los más

importantes y utilizados son los siguientes:

- android:allowBackup(opcional). Valor por defecto a true. Indica que si se hace

un backup del sistema Android, las aplicaciones que tengan este valor a true se

guarden junto con el backup del sistema.

- android:description: Descripción larga de la aplicación y sus funcionalidades.

- android:icon: identificador del recurso que será el icono de la aplicación.

Recordar que los recursos crearán un identificador en la clase R para facilitar su

acceso en el código fuente de la aplicación.

- android:label. Identificador de la cadena de texto que dará nombre a la

aplicación y que será el que verá el usuario en el sistema operativo.

- android:permission. Especificamos el nombre de un permiso que será necesario

si otras aplicaciones hacen uso de partes de tu aplicación. También podemos definir

el permiso necesario para cada una de las actividades (siguiente etiqueta)

utilizando este atributo en cada una de ella.

- android:theme. Identificador al recurso que especifica el tema por defecto de

todas las actividades de la aplicación. Las actividades pueden sobreescribir

individualmente el tema general con sus respectivos atributos android:theme.

5. Etiqueta activity

<activity

android:name="com.example.loginandregisterapi.LoginActivity"

android:label="@string/app_name" >

</activity>

Etiqueta de tercer nivel y que es uno de los sub-elementos de la etiqueta

application. Una actividad es el controlador que va a interactuar con una pantalla

de la interfaz gráfica. Y por lo tanto debemos de especificar cada actividad del

proyecto con su etiqueta activity correspondiente. Si una actividad no está

especificada en el manifiesto, esta no podrá lanzarse. Con el consiguiente error en

la aplicación.

Principales atributos:

- android:ExcludeForRecents(opcional). Si su valor es 'true' significa que la

aplicación asociada con esta actividad no aparecerá en la lista de aplicaciones

recientes del sistema Android,

- android:exported (opcional). Con este atributo podemos restringir a que esta

actividad pueda ser lanzada por componentes de otra aplicación.Con lo que

limitamos la exposición a otras aplicaciones. Por lo tanto si el valor es 'true'

aceptamos dicho uso.

- android:icon (opcional). Si se desea que el icono que aparece junto a la

etiqueta superior de la pantalla de la interfaz gráfica sea distinto al icono general

de la aplicación, se puede especificar con el identificar del recurso de tipo imagen

que se desea.

- android:label (obligatiorio). Etiqueta que verá el usuario en la parte superior

(junto al icono) cuando la actividad muestre la pantalla gráfica correspondiente. El

valor será una referencia a un identificar de recurso de tipo cadena.

- android:name (obligatorio). Este atributo indica el nombre de la clase (ruta

completa) que implementa la actividad.

- android:screenOrientation (opcional). Con este atributo indicamos que

orientación tendrá la pantalla de la interfaz gráfica que controla nuestra actividad.

Sus valores más usados son 'portrait' (vertical), 'landscape' (horizontal) o el valor

por defecto 'unspecified' con el que el dispositivo elige la orientación.

6. Etiqueta intent-filter

<activity

android:name="com.example.loginandregisterapi.LoginActivity"

android:label="@string/app_name" >

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

</activity>

Etiqueta que se sitúa como sub-elemento de la anterior etiqueta (activity). Esta

etiqueta sirve para agrupar el número de acciones que concretarán el ámbito en el

que se va a ejecutar la actividad. Las actividades pueden declarar el tipo de

acciones que pueden llevar a cabo y los tipos de datos que pueden gestionar.

Si una actividad no tiene declarado ningún 'intent filter', se considera una opción

para cualquier 'intent' con una acción. Por lo tanto es importante definir que

acciones puede manejar la actividad.

Hay que tener en cuenta que solo es necesario declarar filtros cuanto los 'intents'

son lanzados de forma implícita. Ya que es el sistema Android el encargado de

buscar la actividad adecuada. En los 'intents' lanzados de forma explicita ya se

especifica la actividad que se quiere ejecutar.

7. Etiqueta action

<activity

android:name="com.example.loginandregisterapi.LoginActivity"

android:label="@string/app_name" >

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />

</intent-filter>

</activity>

Una acción que el 'intent-filter' soporta. Las acciones son cadenas de texto estándar

que describen lo que la actividad puede hacer. El único y obligatorio atributo es

android:name. En el cual indicaremos el nombre de la acción. En el anterior

ejemplo, indicamos que esta es la actividad principal de la aplicación y por lo tanto

la que controlará el inicio de la aplicación.

Pero imaginemos que nuestra actividad específica las siguientes acciones:

<intent-filter>

<action android:name="android.intent.action.VIEW" />

<action android:name="android.intent.action.EDIT" />

<category android:name="android.intent.category.DEFAULT" />

<data android:mimeType="vnd.android.cursor.dir/vnd.google.note" />

</intent-filter>

Esto nos indica que la actividad está disponible para ver y editar elementos del tipo

vnd.android.cursor.dir/vnd.google.note

8. Etiqueta category

Básicamente indica si la actividad va a ser lanzada desde el lanzador de

aplicaciones, desde el menú de otra aplicación, directamente desde otra actividad.

9. Etiqueta data

Mediante esta etiqueta añadiremos una especificación de datos para las acciones

especificadas. Puede ser un tipo de datos o una URI.

Entendiendo el ciclo de vida de una actividad

Las actividades tienen un ciclo de vida frenético. Continuamente se crean y

destruyen nuevas actividades, por lo que es fundamental conocer el ciclo de vida

de estas para poder salvar información importante antes de que se destruyan y

para inicializarlas antes de que se le muestren al usuario. Todo este baile comienza

cuando se hace un broadcast al sistema de un intent, que está registrado en

nuestra actividad para que esta lo reciba.

En ese momento el sistema llama al constructor de la actividad mientras que

también inicia la aplicacion si es necesario y llama a los siguientes métodos por

orden:

onCreate

onStart

onResume

Se supone que al implementar una actividad debemos extender estos métodos que

conforman el ciclo de vida. Cuando un usuario pulsa el boton de retorno desde la

actividad, estos métodos son llamados por este orden:

onPause

onStop

onDestroy

Ejemplos de acciones que destruirán una actividad:

Cambio del móvil a apaisado o viceversa

La actividad ya no se ve en la pantalla, o el sistema esta bajo de recursos

Es martes

El usuario presiona el botón de retroceso o de Home y sale de la aplicación

Después de estas acciones la actividad es cerrada y debería estar lista para el

garbage collector.

Vamos a ver los métodos del ciclo de vida en detalle. Recuerda que se debería

invocar al método de la super clase (a menudo antes de hacer nada ) o Android nos

tirará excepciones.

4.1.1 onCreate

Como hemos dicho antes, es el primer método que se llama cuando se crea una

actividad, y es el lugar donde llamar a setContentView. Como ya te habrás podido

imaginar, no es un buen sitio para poner cosas que vayan a cambiar cuando la

aplicación esté dormida.

4.1.2 onStart

Se llama inmediatamente después del onCreate. Si nuestra aplicación estaba en

segundo plano, onStart será llamado cuando la aplicación vuelva a estar en primer

plano.

4.1.3 onResume

Es el último método que se llama antes de que la actividad tenga acceso a la

pantalla. Si algún elemento del interfaz gráfico ha cambiado mientras la actividad

estaba en segundo plano este método es el sitio para asegurar que el estado está

sincronizado. No importa de qué estado venga, cuando la actividad vuelva a estar

en primer plano este método será llamado.

4.1.4 onPause

Es el primer método que se llama cuando la aplicación se está yendo de la pantalla.

Si tenemos bucles, procesos, animaciones que deberían estar corriendo cuando la

actividad está en pantalla este método es el idóneo para pararlos. Este método

también se llama cuando lanzamos otra actividad desde la que se está ejecutando

actualmente. Este método es importante porque puede ser el único en avisarnos de

que la actividad o incluso toda la aplicación se está cerrando. En este

método deberíamos guardar cualquier información importante a disco, base de datos

o preferencias.

4.1.5 onStop

Cuando se llama a onStop lo que sabemos es que la actividad está oficialmente fuera

de pantalla. No siginifica que la actividad se esté apagando, aunque podría ser. Solo

se puede asumir que el usuario ha dejado tu actividad por otra. Si estás haciendo

algún proceso que solo debería estar corriendo cuando la actividad está en ejecución

este es un buen momento para pararla.

4.1.6 onDestroy

Es el último método que se llama antes del final. Es la última oportunidad para

limpiar lo necesario antes de que el garbage collector la elimine por completo.

Cualquier proceso de background que la actividad puede taner corriendo debe

pararse. Sin embargo porque este método se haya llamado no significa que la

actividad sea borrada. Si tienes algún hilo corriendo, este puede seguir corriendo y

consumiendo recursos incluso aunque este método se llame

Podemos decir que todas las pantallas de una aplicación son una “activity”. Más

adelante vamos a ver que existen algunas variaciones, pero por ahora digamos que

todas lo son. Es decir, que si una aplicación tiene cinco pantallas, tiene 5

“Actividades” o activities.

Las activities están conformadas por dos partes: la parte lógica y la parte gráfica.

La parte lógica es una archivo .java que es la clase que se crea para poder

manipular, interactuar y colocar el código de esa actividad.

La parte gráfica es un XML que tiene todos los elementos que estamos viendo de

una pantalla declarados con etiquetas parecidas a las del HTML, es decir, que el

diseño de una aplicación en Android se hace similar a una página web; XML es un

primo de HTML.

Resumiendo, una actividad está conformada por la parte lógica (un archivo Java) y

la parte gráfica (un archivo XML).

Adentrando más en el tema, ya sabemos que tenemos un archivo .java, esto

quiere decir que tenemos una clase principal, al ser una actividad extiende de la

clase Activity (por eso el nombre) que nos proporciona Android para crear

actividades con sus métodos asignados.

Veamos una actividad básica:

Este sería nuestro archivo "ManActivity" como el del ejercicio del "HolaMundo".

package com.example.holamundodesarrollowebcom;

import android.os.Bundle;

import android.app.Activity;

public class MainActivity extends Activity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

}

}

Expliquemos por líneas:

package com.example.holamundodesarrollowebcom;

Esta línea únicamente indica el nombre del paquete en donde se

encuentra nuestra clase.

import android.os.Bundle;

import android.app.Activity;

Los dos imports, son la forma de decir que necesitamos esos archivos para

trabajar dentro de la clase, los que ya nos da Android para no tener que escribir

las cosas desde cero.

public class MainActivity extends Activity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

}

}

En esta última sección de código lo que estamos haciendo es crear una clase que

se llama "MainActivity" y la estamos extendiendo de acvitity, en español esto es el

concepto de herencia de la famosa programación orientada a objetos, estamos

diciendo que "mainactivity" es una clase que hereda las cosas de la clase Activity

que ya tiene Android definida.

Todas las activities deben llevar por lo menos un método, el método "oncreate",

que es en donde se crea la actividad o podemos decir que es donde se le da vida.

Del método "onCreate" lo más importante es la línea de código:

SetContentView(R.Layout.acivity_main).

Es la que hace el trabajo de enlazar la parte lógica con la parte gráfica. El archivo

XML que va a mostrarse cuando se mande a llamar la clase "MainActivity" es el

archivo XML llamado "activity_main".

Para cerrar la explicación: si se crea una actividad nueva y se llama

"VentanaPrinicipal", debo hacer que herede de activity si quiero que funcione como

actividad y para decirle que el archivo XML que va a mostrar sea el

"ventanaprincipal.xml" o "pepito.xml". La línea que dice "SetContentView" debe

llevar dentro algo parecido a esto: "setContentView"(R.layout.ventanaprincipal).

Los proyectos de Android siguen una estructura fija de carpetas que debemos

respetar.

Carpeta Res

Esta es una de las carpetas que más se va a usar junto con src. Se compila y se

generan referencias en la clase R, para acceder a ellos desde código. Están escritos

en XML. El propósito de esta carpeta es separar la lógica de la aplicación de la

interfaz.

anim: Definición de Animaciones.

color: Definición de colores

drawable: Ficheros bitmap(.png, .9.png, .jpg, .gif) o XML con contenidos

que se dibujarán (fondos, botones etc). layout: Definen la capa de interfaz de usuario

menu: Definición de los menús de la aplicación

raw: Binarios que no se pueden colocar en las otras carpetas.

values: Definición de estilos, cadenas de texto para Localización etc.

xml: Ficheros XML que pueden ser accedidos en tiempo de ejecución

Pasemos ahora a describir los distintos componentes de la aplicación.

La aplicación creada por defecto tendrá un Activity muy simple, uno de los métodos

más importantes de esta clase es onCreate, en él se crean y se instancias los

componentes necesarios para dicha Activity, se instancias componentes gráficos, se

establecen loscallbacks necesarios, eventos etc. El código más simple que se puede

obtener en este método es el siguiente:

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

/**

* Método encargado de “inflar” la actividad.

* Inicializar cada componente de la actividad

* con su correspondiente View.

*/

setContentView(R.layout.activity_main);

}

Es importante añadir la línea setContentView(R.layout.activity_main) ya que aquí se

define qué layout (Interfaz gráfica) va a usar esta Activity. De no añadirla, cualquier

referencia que intentemos hacer de un componente gráfico fallará.

La siguiente imagen muestra el ciclo de vida de una Activity, esto es qué flujo de

llamadas siguen las aplicaciones. Como vemos, onCreate es el primero método en

llamarse al lanzar una Activity, es por ello que en él debemos hacer todas las

inicializaciones necesarias. Si lo necesitamos, podemos implementar todos y cada

uno de estos métodos. Por ejemplo, en una aplicación de vídeo, interesará detener

la reproducción cuando se recibe una llamada, o cuando la pantalla se apaga, toda

esa lógica deberá ir en el métodoonPause o onStop, y debería reanudarse

implementando la lógica en onRestart oonResume.

./res/layout/activity_main.xml

Este es el fichero que especifica qué interfaz gráfica queremos en

nuestra Activity(Recordemos la llamada setContentView(R.layout.activity_main);).

En este caso, la interfaz es un simple TextView que mostrará el mensaje Hola Mundo.

(El texto se ha especificado haciendo referencia al fichero de cadenas (strings.xml)

definido más abajo, en concreto se hace referencia a la cadena de texto de

valor hello_world).

<RelativeLayout

android:layout_width="match_parent"

android:layout_height="match_parent"

tools:context=".MainActivity" >

<TextView

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="@string/hello_world" />

</RelativeLayout>

./res/values/strings.xml

Aquí se definen las cadenas de texto a usar en la aplicación. Siempre deben

escribirse en un fichero XML dentro de la carpeta values, ya que de este modo

podremos traducir la aplicación a otro idioma fácilmente con tan solo crear otra

carpeta llamada values-de, por ejemplo, que contenga las cadenas de texto en

alemán. En este caso, se crea una única cadena de texto de nombre hello_world y

de valor Hello World!.

<resources>

<string name="hello_world">Hello world!</string>

</resources>

Empezaremos creando la primera pantalla que verá el usuario al acceder a la

aplicación. En este caso consiste en una caja de texto (EditText) y un botón:

<!-- ./layout/activity_hello_world_main -->

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

android:paddingBottom="@dimen/activity_vertical_margin"

android:paddingLeft="@dimen/activity_horizontal_margin"

android:paddingRight="@dimen/activity_horizontal_margin"

android:paddingTop="@dimen/activity_vertical_margin"

tools:context=".MainActivity">

<EditText

android:id="@+id/edit_message"

android:layout_width="0dip"

android:layout_height="wrap_content"

android:layout_weight="1"

android:hint="@string/edit_message"/>

<Button

android:id="@+id/send_button"

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="@string/button_send"/>

</LinearLayout>

Un LinearLayout especifica cómo se ordenarán las vistas que hay dentro de él. Hay

dos tipos, vertical u horizontal. Si no se especifica nada por defecto es horizontal, lo

cual significa que se irán colocando las vistas una debajo de otra. En nuestro caso,

el EditTex testará colocado encima del botón.

android:layout_weight="1" especifica el peso que tiene esta vista (La cantidad de

espacio que debería ocupar).

El valor es relativo al espacio ocupado por las vistas hermanas. Por ejemplo, una

vista con un peso de 2 y otra de 1. La suma es 3, la primera vista ocupará 2/3 del

espacio libre y la segunda el resto. Si añadimos otra vista con peso 1, ahora la suma

es 4 y la primera estará ocupando 1/2 (2/4) del espacio restante, y las otras dos

1/4.

Si dejamos todos los valores por defecto y especificamos un valor!= 0 en una vista,

dicha vista ocupará todo el espacio restante.

Si usamos weight, hay que poner un width de 0dip para mejorar el rendimiento, ya

que no es necesario calcular éste valor.

El resultado de este layout es:

A esta pantalla se enviará el mensaje escrito en la anterior. Se define con el siguiente

código:

<RelativeLayout

xmlns:android="http://schemas.android.com/apk/res/android"

xmlns:tools="http://schemas.android.com/tools"

android:layout_width="match_parent"

android:layout_height="match_parent"

android:paddingBottom="@dimen/activity_vertical_margin"

android:paddingLeft="@dimen/activity_horizontal_margin"

android:paddingRight="@dimen/activity_horizontal_margin"

android:paddingTop="@dimen/activity_vertical_margin"

tools:context=".DisplayMessageActivity">

<TextView

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="@string/hello_world"/>

</RelativeLayout>

Es más simple que la anterior, simplemente tiene un TextView que será usado para

mostrar el texto recibido. Para saber más sobre cómo trabajar con layouts puedes

visitar el artículo interfaz gráfica - layouts.

Veamos ahora cómo implementar el funcionamiento de la pantalla principal. Al crear

el proyecto también se crea un fichero .java de nombre MainActivity en la mayoría

de los casos. Aquí se ha cambiado el nombre por HelloWorldMain, con el siguiente

código:

public class HelloWorldMain extends Fragment {

public final static String EXTRA_MESSAGE =

"com.tutorial.holamundo.MESSAGE";

private Button mButton;

private OnClickListener mOnClickListener;

public static HelloWorldMain newInstance() {

HelloWorldMain fragment = new HelloWorldMain();

return fragment;

}

public HelloWorldMain() {}

@Override

public View onCreateView(LayoutInflater inflater, ViewGroup

container,

Bundle savedInstanceState) {

// Especificamos qué interfaz vamos a usar, el xml corresponde al

visto más arriba

final View root =

inflater.inflate(R.layout.activity_hello_world_main, container, false);

// Obtenemos una referencia al botón para poder usarlo

mButton = (Button) root.findViewById(R.id.send_button);

// Implementamos el OnClickListener para definir qué se

// hará al pulsar la vista asociada a este listener

mOnClickListener = new OnClickListener() {

@Override

public void onClick(View view) {

/**

* Un intent proporciona una forma de enlazar componentes

separados. Representa

* la intención de una aplicación de hacer algo. Pueden

usarse

* para muchas cosas, entre ellas para lanzar otra

activity.

*/

// Los parámetros son el contexto y la activity a lanzar.

Intent intent = new Intent(view.getContext(),

DisplayMessageActivity.class);

/**

* Obtenemos una referencia del EditText declarado en

XML.

* findViewById devuelve un objeto View, por tanto es

necesario

* realizar un casting al tipo de vista que nos interesa.

*/

EditText editText = (EditText)

root.findViewById(R.id.edit_message);

// Obtener el valor introducido por el usuario

String message = editText.getText().toString();

/**

* Los intent pueden llevar información consigo, para que

el

* componente que los reciba pueda usala. En este caso al

intent

* le adjuntaremos el mensaje escrito en el edittext. El

primer

* argurmento es el nombre que identificará al mensaje

adjunto,

* así el otro componente podrá obtenerlo y usarlo.

*/

intent.putExtra(EXTRA_MESSAGE, message);

// lanzamos la actividad

startActivity(intent);

}

};

// Establecer el evento onClickListener al botón.

mButton.setOnClickListener(mOnClickListener);

return root;

}

}

Lo que vemos en la declaración de una clase, que hereda de Fragment.

Los Fragments son un concepto introducido en Android 3 que pretendía modularizar

aún más una pantalla (Activity). El obetivo es poder reutilzar más código. Si en una

pantalla, supongamos, disponemos de dos botones abajo (Aceptar, Cancelar) y

dichos botones queremos reutilzarlos a lo largo de muchas pantallas, bastaría con

crearlos en un Fragment. De usar una Activity sería necesario copiar y pegar el

código de ambos botones en todas y cada una de las pantallas en las que

quisieremos los botones.

Se definen unos cuantos atributos de la clase, (Un botón, un onClickListener y un

identificador para el mensaje a enviar). El único método obligatorio de implementar

en un Fragment es onCreateView, en él se define la interfaz gráfica del Fragment y

se inicializan los componenetes. El funcionamiento está explicado en los comentarios

del código.

Una vez se pulse el botón, se lanzará la segunda pantalla, veamos qué hace.

/**

* Clase que hereda de la clase Activity, por lo cual dispondrá de

* interfaz de usuario. Al crear una Activity, Android invoca a una serie

de

* métodos, entre ellos <i>oncreate()</i>. El ciclo de vida de una

activity se

* puede ver en <a

href="http://developer.android.com/reference/android/app/Activity.html#Ac

tivityLifecycle">Activity

* Lifecycle</a>

*

* @author Alejandro Alcalde

* @see

http://developer.android.com/reference/android/app/Activity.html#Activity

Lifecycle

*/

public class DisplayMessageActivity extends Activity {

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

/**

* Toda Activity se invoca mediante un intent, independientemente

de

* cómo el usuario haya llegado hasta ella. Se puede obtener el

intent

* con el método getIntent() y obtener la información adjunta.

*/

Intent intent = getIntent();

String message =

intent.getStringExtra(HelloWorldMain.EXTRA_MESSAGE);

/**

* En esta ocasión, vamos a ver cómo crear la interfaz desde

código en

* lugar de XML. Para ello declaramos un TextView que mostrará el

* mensaje y lo añadiremos a la raiz de la activity con

* setContentView().

*/

TextView textView = new TextView(this);

textView.setTextSize(40);

textView.setText(message);

// Establecer el TextView como interfaz de la actividad

setContentView(textView);

}

}

En este caso, en lugar de un Fragment tenemos una Activity. Como vemos, se

recupera la información enviada desde la primera pantalla usando el identificador

que le asociamos (EXTRA_MESSAGE. Luego, en vez de establecer la interfaz gráfica

mediante un fichero XML, se realiza mediante programación, por lo tanto, el XML de

la segunda pantalla que vimos arriba no se usa. Aunque es posible implementar la

interfaz desde código se recomienda hacerlo desde XML siempre que sea posible.

Esto es todo, solo resta ver el AndroidManifest, el fichero que recoge todas las

propiedades de una apliación en android:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="es.tformacion.helloworld">

<application android:allowBackup="true"

android:label="@string/app_name">

<activity

android:theme="@android:style/Theme.Holo.Light"

android:name="es.tformacion.helloworld.HelloWorldMain"

android:label="@string/app_name">

<intent-filter>

<action

android:name="es.tformacion.helloworld.HelloWorldMain"/>

<category

android:name="android.intent.category.DEFAULT"/>

</intent-filter>

</activity>

<activity

android:theme="@android:style/Theme.Holo.Light"

android:name="es.tformacion.helloworld.DisplayMessageActivity"

android:label="@string/app_name">

</activity>

</application>

</manifest>

En este fichero se definen las pantallas que la aplicación va a usar, así como los

permisos que necesita (En este caso ninguno).

Introducción a Xamarin en

Visual Studio Xamarin le permite usar C# para compilar aplicaciones nativas que se ejecutan en

iOS, Android y en dispositivos de Windows

Esta guía le ayudará a instalar la extensión Xamarin para Visual Studio y le dará un

paseo guiado por las opciones de uso.

Instalar Xamarin con Visual Studio

Elija la característica de Xamarin al instalar Visual Studio.Puede agregar la

característica más adelante siempre que lo desee.

Elegir la característica de Xamarin al instalar Visual Studio

1. En el instalador de Visual Studio, elija la opción Personalizar y, a

continuación, seleccione la casilla de verificación C# / .NET (Xamarin).

Una vez instalado Visual Studio, Buscar las plantillas de proyecto de Xamarin.

Elija la característica Xamarin después de instalar Visual Studio.

1. En el Panel de Control, abra Programas y características, elija el

elemento Visual Studio 2015 y, a continuación, elija el botón Cambiar.

2. En el Asistente para la instalación de Visual Studio, elija el botón Modificar.

3. En la lista de características opcionales para instalar, seleccione la casilla de

verificación C# / .NET (Xamarin), elija el botón Siguiente y, a

continuación, elija el botón Actualizar.

Buscar las plantillas de proyecto de Xamarin

Bien, ha instalado Visual Studio y Xamarin y está listo para probarlo, así que vamos

a buscar todas las plantillas.

Abra el cuadro de diálogo Nuevo proyecto y, a continuación, expanda el

nodo Visual C#.Encontrará las plantillas de Xamarin en los grupos

Android, iOS y Aplicaciones móviles.

Técnicamente, las plantillas de Windows no forman parte de la extensión de

Xamarin, pero las encontrará en el grupo Windows.Hablaremos acerca de su uso

con otras plantillas de Xamarin más adelante.

Para obtener información acerca de cualquiera de estas plantillas, elija una y lea su

descripción.

Algunas plantillas no son tan obvias, como, por ejemplo, el grupo API clásico, que

contiene sus propias plantillas para iPad, iPhone yUniversal.Dichas plantillas

existen, principalmente, para compatibilidad con versiones anteriores.Puede leer

más información sobre esto aquí: API unificada.

Otro grupo que parece extraño es el grupo Extensiones.Las plantillas de este grupo

permiten crear nuevos tipos de comportamiento para diferentes tareas que el

usuario se encuentra en su sistema.

El grupo de plantillas Aplicaciones móviles le ayudarán a crear compilaciones para

más de una plataforma (por ejemplo: Windows, iOS y Android).Aquí encontrará

plantillas Xamarin.Forms que le ayudarán a crear una interfaz de usuario que se

puede compartir entre las diferentes plataformas.Estas plantillas aparecen

resaltadas en la imagen siguiente.

Si está familiarizado con Xamarin, consulte Xamarin.Forms.

¿Faltan las plantillas de proyecto de Xamarin?Pruebe esto

Esto puede suceder si instala Xamarin directamente desde el sitio web de Xamarin

y tiene Visual Studio 2013 y Visual Studio 2015 instalados al mismo tiempo.Pero no

se preocupe, es bastante fácil de corregir.Habilite la característica Xamarin para

Visual Studio 2015 en el programa de instalación de Xamarin.

Procedimiento para habilitar la característica Xamarin para Visual Studio 2015 en el

programa de instalación de Xamarin

1. En el Panel de Control, abra Programas y características, elija el

elemento Xamarin y, a continuación, elija el botón Cambiar.

2. En el Asistente para la instalación de Xamarin, elija el botón Siguiente y, a

continuación, elija el botón Cambiar.

3. En la lista de características opcionales para instalar, elija el icono junto

a Xamarin para Visual Studio 2015 y, a continuación, elija Se instalará

en la unidad local.

Después de habilitar la característica, abra Visual Studio y Buscar las

plantillas de proyecto de Xamarin.

Ejecutar una aplicación Android lista para usar

En el grupo Android de plantillas de proyecto, elija la plantilla Aplicación vacía

(Android) y, después, presione F5 para iniciar el proyecto.

Su aplicación aparecerá en el emulador de Visual Studio para Android.

Puesto que existen dispositivos Android con tamaños de pantalla, resolución y

configuración del hardware diferentes, elija Herramientas ->Emulador de Visual

Studio para Android para seleccionar los perfiles de su dispositivo.

Ejecutar una aplicación de Windows lista para usar

En el grupo de plantillas de proyecto Windows -> Universal, elija la

plantilla Aplicación vacía (Universal de Windows).

Establezca el proyecto de Windows como su proyecto de inicio.

Abra el cuadro de diálogo Administrador de configuración y seleccione las

casillas de verificación Compilar e Implementar para el proyecto de Windows.

Presione F5 para iniciar el proyecto.

Crear su primera aplicación para Android y Windows

Siga los pasos de Crear aplicaciones multiplataforma con Xamarin en Visual

Studio para crear aplicaciones básicas para Android y Windows que muestren el

tiempo de cualquier ubicación de su región.

Esto es lo que aprenderá:

Usar el diseñador para simular una página para Android y una página para

Windows.

Manipular eventos de los controles y modificar la apariencia de los controles

mediante código.

Compartir código entre aplicaciones de Android, iOS y Windows

Obtener datos de un servicio gratuito y mostrarlo en la página

Cuando haya terminado, las aplicaciones tendrán este aspecto.

Para obtener información general sobre el diseño para Windows 10,

consulte Compilar una aplicación universal para Windows 10.

¿Desea crear una aplicación para iOS?Tendrá que conectarse a un Mac conectado

en red

Para configurarlo, consulte este artículo en el sitio Web de Xamarin: Instalar

Xamarin.iOS en Windows.Por desgracia, no se puede simplemente presionar F5 y

ejecutar una aplicación vacía de iOS sin haber completado primero esas

instrucciones.

Sin embargo, cuando haya finalizado, puede agregar un proyecto de iOS a la

solución como hizo con Windows; establézcalo como proyecto de inicio, seleccione

las casillas Compilar e Implementar y presione F5 para ejecutarlo.

Crear su primera aplicación para iOS

Siga estos pasos en Hola, iOS para crear una aplicación básica de iOS que convierta

los números de teléfono alfanuméricos especificados por el usuario en un número

de teléfono compuesto solo por números y, a continuación, llame a ese número.

Esto es lo que aprenderá:

Utilice el diseñador para crear un modelo visual de una página de iOS.

Manipular eventos de los controles y modificar la apariencia de los controles

mediante código.

Ejecute la aplicación en un simulador de iOS.

Cuando haya terminado, las aplicaciones tendrán este aspecto.

Uso de Xamarin.Forms para diseñar una interfaz de usuario para las tres plataformas

Si está listo para iniciar una versión de prueba de 30 días de Xamarin, puede

experimentar con Xamarin.Forms y compartir no solo código, sino también la

interfaz de usuario.

En el grupo de plantillas de proyecto Móvil, elija la plantilla Aplicación vacía

(Xamarin.Forms Portable).

Lo primero que aparece es el cuadro de diálogo Conectar un Host de compilación

de Xamarin.iOS.Por ahora, solo tiene que elegir Cancelar para crear la solución.

La solución contiene cuatro proyectos porque Xamarin.Forms no genera una sola

aplicación que se ejecute en todas las plataformas.En lugar de eso, genera

aplicaciones nativas para cada una de las tres plataformas.

Podrá crear la interfaz de usuario en la biblioteca de clases portables y colocar todo

el código compartido en esa biblioteca también.

El proyecto de Windows genera una aplicación de Windows Phone Silverlight 8.

Puede ejecutar cada uno de los proyectos de las tres plataformas haciendo lo mismo

que se describe en las secciones anteriores:

Establezca cualquier proyecto como su proyecto de inicio.

Abra el cuadro de diálogo Administrador de configuración y seleccione las

casillas de verificación Compilar e Implementar para dicho proyecto.

Las aplicaciones tienen este aspecto cuando se ejecuten una vez acabadas.