Desarrollo 6 Introducción a la programación móvil

Tipos de Aplicaciones Móviles (Apps)

1-Aplicaciones Web para Móviles

Son 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 aformato móvil.
Ventajas Desventajas
Código Reutilizable en diferentes Plataformas Requiere conexión internet
Desarrollo sencillo y económico Acceso limitado a hardware
No aprobación externa para publicarse Experiencia de usuario y tiempo Respuesta
Menor q App nativa
Usuario usara ultima versión siempre Mayor Esfuerzo para promoción y
visualización
Reutilización de Sitios Responsive

2-Aplicaciones Nativas
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 almacenamiento 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).

Ventajas
Acceso completo a dispositivo
Mejor experiencia de usuario
Visibilidad en App Store
Envio de notificaciones o avisos a usuario
La actualización del app es constante
Desventajas
Diferentes habilidades/idiomas/herramientas
Para cada destino
Tienden a ser mas caras de desarrollar
El código del cliente tiende a no ser reutilizable
3. Aplicaciones Hibridas

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

Ventajas
Posible distribuir en IOS y ANDROID
Instalacion Nativa, construida con JS,HTML
y CSS
Mismo código base para multiples
plataformas
Acceso a parte del hardware
Desventajas
Experiencia de usuario mas a web que a
aplicación nativa
Diseño visual no siempre relacionado con el
sistema OP en el que se muestre

Los Sistemas Operativos de los dispositivos móviles y sus entornos de Desarrollo para

aplicaciones (IDE)

Tabla comparativa de Sistema Operativos Moviles

Blackberry OS IOS TIZEN OS Window Phone Android

EMPRESA RIM APPLE Samsung Microsoft Google
fundation Linux
Año de 2000 2007 2012 2000 2007
lanzamiento
Costo licencia GRATIS $99.00 al año GRATIS $90.00 al año $25 de por vida
Validaciones de 1 a 3 semanas 1 semana 3 dias 1 a 2 semanas 5 a 30 min
aplicaciones
IDE -Java Plug-in -Xcode + ios + SDK -ADT.
para eclipse. SDK -Tizen SDK. - Windows -Android
+ B.B. Java -Instruments. Visual Studio Microsoft Studio.
Development -Dash code. -App
Environment -Simulador.
(JDE) Interface
Lenguaje de C,C++,C#, Objetive C, HTML5, C++, C# .NET C, C++, Java,
Programación JAVA. Java, C, C++. JS. XML.

Instalación del Android Studio

Visitar la siguiente URL
https://developer.android.com/studio/install.html?hl=es-419
1.3.1 SDK Manager (ver en laboratorio)
1.4 Estructura de un Proyecto Android en Android Studio (Ver en Laboratorio)
Para crear un nuevo proyecto ejecutaremos Android Studio y desde la pantalla de bienvenida pulsaremos la opción
“Start a new Android Studio project” para iniciar el asistente de creación de un nuevo proyecto.
Si ya habíamos abierto anteriormente Android Studio es posible que se abra directamente la aplicación principal en vez
de la pantalla de bienvenida. En ese caso accederemos al menú “File /
New project...” para crear el nuevo proyecto.
El asistente de creación del proyecto nos guiará por las distintas opciones de creación y configuración de un nuevo
proyecto Android.
En la primera pantalla indicaremos, por este orden, el nombre de la aplicación, el dominio de la compañía, y la ruta
donde crear el projecto. El segundo de los datos indicados tan sólo se utilizará como paquete de nuestras clases java.
Así, si por ejemplo indicamos como en mi caso android.sgoliver.net, el paquete java principal utilizado para mis clases
será net.sgoliver.android.holausuario. En tu caso puedes utilizar cualquier otro dominio.

En la siguiente pantalla del asistente configuraremos las plataformas y APIs que va a utilizar nuestra aplicación. Nosotros
nos centraremos en aplicaciones para teléfonos y tablets, en cuyo caso tan sólo tendremos que seleccionar la API
mínima (es decir, la versión mínima de Android) que soportará la aplicación.

La versión mínima que seleccionemos en esta pantalla implicará que nuestra aplicación se pueda ejecutar en más o
menos dispositivos. De esta forma, cuanto menor sea ésta, a más dispositivos podrá llegar nuestra aplicación, pero más
complicado será conseguir que se ejecute correctamente en todas las versiones de Android. Para hacernos una idea del
número de dispositivos que cubrimos con cada versión podemos pulsar sobre el enlace “Help me choose”, que mostrará
el porcentaje de dispositivos que ejecutan actualmente cada versión de Android. Por ejemplo, en el momento de escribir
este artículo, si seleccionamos como API mínima la 15 conseguiríamos cubrir un 94,0% de los dispositivos actuales.
Como información adicional, si pulsamos sobre cada versión de Android en esta pantalla podremos ver una lista de las
novedades introducidas por dicha versión.
En la siguiente pantalla del asistente elegiremos el tipo de actividad principal de la aplicación. Entenderemos por ahora
que una actividad es una “ventana” o “pantalla” de la aplicación. Para empezar seleccionaremos Empty Activity, que es
el tipo más sencillo.
Por último, en el siguiente paso del asistente indicaremos los datos asociados a esta actividad principal que acabamos de
elegir, indicando el nombre de su clase java asociada (Activity Name) y el nombre de su layout xml (algo así como la
interfaz gráfica de la actividad, lo veremos más adelante). No nos preocuparemos mucho por ahora de todos estos datos
por lo que podemos dejar todos los valores por defecto. Más adelante en el curso explicaremos cómo y para qué
utilizar estos elementos.

Una vez configurado todo pulsamos el botón Finish y Android Studio creará por nosotros toda la estructura del proyecto
y los elementos indispensables que debe contener. Si todo va bien aparecerá la pantalla principal de Android Studio con
el nuevo proyecto creado. En ocasiones Android Studio no realiza correctamente esta primera carga del proyecto y es
posible que os encontréis con un error del tipo “Rendering Problems...“. Para solucionarlo no tienes más que cerrar la
ventana del editor gráfico y volverla a abrir pulsando sobre el fichero “activity_main.xml” que puedes ver en el
explorador de la parte izquierda.
En la parte izquierda, podemos observar todos los elementos creados inicialmente para el nuevo proyecto Android, sin
embargo por defecto los vemos de una forma un tanto peculiar que podría llevarnos a confusión. Para entender mejor la
estructura del proyecto vamos a cambiar momentáneamente la forma en la que Android Studio nos la muestra. Para
ello, pulsaremos sobre la lista desplegable situada en la parte superior izquierda, y cambiaremos la vista de proyecto al
modo “Project”.

Lo primero que debemos distinguir son los conceptos de proyecto y módulo. La entidad proyecto es única, y engloba a
todos los demás elementos. Dentro de un proyecto podemos incluir varios módulos, que pueden representar
aplicaciones distintas, versiones diferentes de una misma aplicación, o distintos componentes de un sistema (aplicación
móvil, aplicación servidor, librerías, ...). En la mayoría de los casos, trabajaremos con un proyecto que contendrá un sólo
módulo correspondiente a nuestra aplicación principal. Por ejemplo en este caso que estamos creando tenemos el
proyecto “android-hola-usuario” que contiene al módulo “app” que contendrá todo el software de la aplicación de
ejemplo.
A continuación describiremos los contenidos principales de nuestro módulo principal.
Carpeta /app/src/main/java
Esta carpeta contendrá todo el código fuente de la aplicación, clases auxiliares, etc. Inicialmente, Android Studio creará
por nosotros el código básico de la pantalla (actividad o activity) principal de la aplicación, que recordemos que en
nuestro caso era MainActivity, y siempre bajo la estructura del paquete java definido durante la creación del proyecto.

Carpeta /app/src/main/res/
Contiene todos los ficheros de recursos necesarios para el proyecto: imágenes, layouts, cadenas de texto, etc. Los
diferentes tipos de recursos se pueden distribuir entre las siguientes subcarpetas:
Carpeta Descripción
/res/drawable/ Contiene las imágenes y otros elementos gráficos usados por la aplicación. Para poder
definir diferentes recursos dependiendo de la resolución y densidad de la pantalla del
dispositivo se suele dividir en varias subcarpetas:

/drawable (recursos independientes de la densidad)

/drawable-ldpi (densidad baja)
/drawable-mdpi (densidad media)
/drawable-hdpi (densidad alta)

/drawable-xhdpi (densidad muy alta)

/drawable-xxhdpi (densidad muy muy alta :)
/res/mipmap/ Contiene los iconos de lanzamiento de la aplicación (el icono que aparecerá en el menú
de aplicaciones del dispositivo) para las distintas densidades de pantalla existentes. Al
igual que en el caso de las carpetas /drawable, se dividirá en varias subcarpetas
dependiendo de la densidad de pantalla:

/mipmap-mdpi
/mipmap-hdpi
/mipmap-xhdpi
/res/layout/ Contiene los ficheros de definición XML de las diferentes pantallas de la interfaz
gráfica. Para definir distintos layouts dependiendo de la orientación del dispositivo se
puede dividir también en subcarpetas:

/layout (vertical)
/layout-land (horizontal)
/res/anim/ Contienen la definición de las animaciones utilizadas por la aplicación.
/res/animator/
/res/color/ Contiene ficheros XML de definición de listas de colores según estado.
/res/menu/ Contiene la definición XML de los menús de la aplicación.
/res/xml/ Contiene otros ficheros XML de datos utilizados por la aplicación.
/res/raw/ Contiene recursos adicionales, normalmente en formato distinto a XML, que no se incluyan en el
resto de carpetas de recursos.
/res/values/ Contiene otros ficheros XML de recursos de la aplicación, como por ejemplo cadenas
de texto (strings.xml), estilos (styles.xml), colores (colors.xml), arrays de valores
(arrays.xml), tamaños (dimens.xml), etc.
1.5 Componentes de una Aplicación Android
En Java o .NET estamos acostumbrados a manejar conceptos como ventana, control, eventos o servicios como los
elementos básicos en la construcción de una aplicación. Pues bien, en Android vamos a disponer de esos mismos
elementos básicos, aunque con un pequeño cambio en la terminología y el enfoque.
1.5.1 Activity
Las actividades (activities) representan el componente principal de la interfaz gráfica de una aplicación Android. Se
puede pensar en una actividad como el elemento análogo a una ventana o pantalla en cualquier otro lenguaje visual.
1.5.1.1 Fragments
Los fragmentos no son obligatorios en las aplicaciones, pero podemos utilizarlos para aumentar la interacción en una
misma pantalla. Un Activity o actividad, puede estar formado de muchos fragmentos, por lo que podríamos definirlos
como componentes de una Activity.
De los fragmentos, destaco lo siguiente:
Puedes declarar varios fragmentos en una misma Activity.
Si destruyes/pausas/ una actividad, destruyes/pausas sus fragmentos.
Existen desde la API 11.
Ventajas de los Fragmentos
Son reutilizables.
Facilita el desarrollo de apps para todo tipo de pantallas.

Sin duda una de las grandes ventajas es la reutilización, ya que los fragmentos se ubican en las Activity. Entonces, son
independientes unos de los otros, y podemos reutilizarlos en las diferentes Activity o hacer pequeños cambios en ellos si
lo consideramos oportuno.
1.5.2 Content Providers
Un proveedor de contenidos (content provider) es el mecanismo que se ha definido en Android para compartir datos
entre aplicaciones. Mediante estos componentes es posible compartir determinados datos de nuestra aplicación sin
mostrar detalles sobre su almacenamiento interno, su estructura, o su implementación. De la misma forma, nuestra
aplicación podrá acceder a los datos de otra a través de los content provider que se hayan definido.
1.5.3 Broadcast Receiver
Un broadcast receiver es un componente destinado a detectar y reaccionar ante determinados mensajes o eventos
globales generados por el sistema (por ejemplo: “Batería baja”, “SMS recibido”, “Tarjeta SD insertada”, ...) o por otras
aplicaciones (cualquier aplicación puede generar mensajes (intents, en terminología Android) broadcast, es decir, no
dirigidos a una aplicación concreta sino a cualquiera que quiera escucharlo).
1.5.4 Services
Los servicios son componentes sin interfaz gráfica que se ejecutan en segundo plano. En concepto, son similares a los
servicios presentes en cualquier otro sistema operativo. Los servicios pueden realizar cualquier tipo de acciones, por
ejemplo actualizar datos, lanzar notificaciones, o incluso mostrar elementos visuales (p.ej. actividades) si se necesita en
algún momento la interacción con del usuario.
1.5.5 Intent
Un intent es el elemento básico de comunicación entre los distintos componentes Android que hemos descrito
anteriormente. Se pueden entender como los mensajes o peticiones que son enviados entre los distintos componentes
de una aplicación o entre distintas aplicaciones. Mediante un intent se puede mostrar una actividad desde cualquier
otra, iniciar un servicio, enviar un mensaje broadcast, iniciar otra aplicación, etc.
1.6 Ciclo de Vida de una Aplicación Android

Cuando se empieza a programar en un lenguaje como C++ o Java, lo primero que se enseña es el método main, el punto
al que llamará el sistema operativo cuando vayamos a arrancar nuestra aplicación.
En Android no existe un método main como tal, pero sí existen varios métodos de nuestra actividad que serán llamados
por el SSOO cuando ocurran eventos importantes. Estudiaremos a fondo cuáles son esos eventos, y como funciona el
ciclo completo de una activid
1.onCreate(Bundle) Representa el momento en el que la actividad se crea. Este método normalmente lo generará el
asistente al crear una nueva actividad en Android, y es donde crearemos todo lo que vaya a necesitar la actividad. Si
antes hemos salvado los datos de la actividad en un objeto Bundle, podremos utilizarlo para regenerarla. Normalmente
no lo usaremos.
2. onStart() La actividad va a pasar a estar en pantalla, aunque no necesariamente visible. Sivenimos de una parada,
pasaremos antes por onRestart().
3. onRestart() Anterior a onStart() cuando procedemos de una llamada a onStop().
4. onResume() La actividad va a empezar a responder a la interacción del usuario.
5. onPause() La actividad va a dejar de responder a la interacción del usuario.
6. onStop() La actividad ha pasado completamente a segundo plano.
7. onDestroy() La actividad va a ser destruida y sus recursos liberados.
Cuando necesitemos implementar uno de estos métodos, lo haremos añadiendo a nuestra actividad con estos perfiles:

public class MiActividad extends Activity {

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

...

protected void onStart() {

super.onStart();

...

protected void onRestart() {

super.onRestart();

...

protected void onResume() {

super.onResume();

...

protected void onPause() {

...

super.onPause();

protected void onStop() {

...

onStop();
}

protected void onDestroy() {

super.onDestroy();

1.7 Archivo Android Manifest XML

Todas las aplicaciones deben tener un archivo AndroidManifest.xml (con ese nombre exacto) en el directorio raíz. El
archivo de manifiesto proporciona información esencial sobre tu aplicación al sistema Android, información que el
sistema debe tener para poder ejecutar el código de la app.
1.7.1 Función del Android Manifest
Entre otras cosas, el archivo de manifiesto hace lo siguiente:
- Nombra el paquete de Java para la aplicación. El nombre del paquete sirve como un identificador único para la
aplicación.
- Describe los componentes de la aplicación, como las actividades, los servicios, los receptores de mensajes y los
proveedores de contenido que la integran. También nombra las clases que implementa cada uno de los
componentes y publica sus capacidades, como los mensajes Intent con los que pueden funcionar. Estas
declaraciones notifican al sistema Android los componentes y las condiciones para el lanzamiento.
- Determina los procesos que alojan a los componentes de la aplicación.
- Declara los permisos debe tener la aplicación para acceder a las partes protegidas de una API e interactuar con
otras aplicaciones. También declara los permisos que otros deben tener para interactuar con los componentes
de la aplicación.
- Enumera las clases Instrumentation que proporcionan un perfil y otra información mientras la aplicación se
ejecuta. Estas declaraciones están en el manifiesto solo mientras la aplicación se desarrolla y se quitan antes de
la publicación de esta.
- Declara el nivel mínimo de Android API que requiere la aplicación.
- Enumera las bibliotecas con las que debe estar vinculada la aplicación.
1.7.2 Elementos del Android Manifest

A continuación, se ofrece un ejemplo de archivo de manifiesto:

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

<manifest>

<uses-permission />
<permission />
<permission-tree />
<permission-group />
<instrumentation />
<uses-sdk />
<uses-configuration />
<uses-feature />
<supports-screens />
<compatible-screens />
<supports-gl-texture />
<application>
<activity>
<intent-filter>
<action />
<category />
<data />
</intent-filter>
<meta-data />
</activity>
<activity-alias>
<intent-filter> . . . </intent-filter>
<meta-data />
</activity-alias>
<service>
<intent-filter> . . . </intent-filter>
<meta-data/>
</service>
<receiver>
<intent-filter> . . . </intent-filter>
<meta-data />
</receiver>
<provider>
<grant-uri-permission />
<meta-data />
<path-permission />
</provider>
<uses-library />

</application>
</manifest>

1.8 Ejecución de una Aplicación Móvil (ver en lab)

1.8.1 En el Emulador (ver en lab)
1.8.2 En el Dispositivo (ver en lab)

1.9 Publicación y Distribución Aplicaciones Móviles en Google Play

Para empezar, el desarrollador deberá convertir su cuenta de Google en una cuenta de desarrollador a través de Google
Play Developer Console, a la cual se puede acceder desde https://play.google.com/apps/publish/signup/ una vez que se
haya identificado previamente en la cuenta de Google.
Una vez se haya accedido a la consola de desarrollador de Google Play, se deberá proceder al pago de la tasa que Google
pone a todos los desarrolladores para que puedan incluir sus apps en la tienda. Para ello, hay que aceptar las
condiciones de Google y pulsar sobre el botón que se muestra en la parte inferior de “Continuar para completar el
pago”. A continuación se abrirá una pantalla de Google Wallet para proceder con el pago de 25
dólares que es la tasa que cobra Google para darse de alta como desarrollador de aplicaciones y poderlas publicar en la
tienda.

Una vez que se ha pasado por caja, ya se pueden gestionar las aplicaciones desde el centro de gestión e información
como desarrolladores, que permitirá añadir una nueva aplicación, ver el listado de aplicaciones añadidas, acceder a los
servicios para Google Play Games, ver los informes de los beneficios, menú de configuración, anuncios o alertas.
Store Listing es donde se deberá indicar la descripción completa, texto de promoción, icono de la app, pantallazos,
categoría de la tienda donde se incluirá, datos de contacto, política de privacidad, etc. Pricing & Distribution permitirá
elegir los países donde se quiere poner disponible la aplicación para su descarga e indicar si la aplicación se va a
distribuir de forma gratuita o de pago.
Una vez que se haya completado toda esta información se puede publicar la aplicación cambiando el estado actual de
Borrador. También se recomienda leer los consejos para optimizar la información de la app en Google Play dentro de la
pestaña que Google ofrece para ello. Si se ha elegido que la aplicación sea de pago hay que tener en cuenta que para
cobrar por los productos publicados en Google Play, el desarrollador debe disponer de una Cuenta de Pago válida
proporcionada a través de un acuerdo independiente con un Procesador de Pagos. Si el desarrollador ya dispone de una
antes de registrarse en Google Play Store, se aplicarán las condiciones de ese acuerdo salvo que exista algún conflicto
con el acuerdo de distribución para desarrolladores que Google Play ha definido, en cuyo caso se aplicarán las
condiciones de ese acuerdo.

El desarrollador es el comerciante oficial de los productos, el cual vende a través de Google Play y el que establecerá el
precio en las distintas monedas que crea oportuno. Según el precio que establezca para sus productos, se determinará la
cantidad que recibirá en el pago, ya que Google añadirá una Comisión de Transacción al precio de venta de cada
producto. Esta Comisión de Transacción, Google la fija en un 30% del precio de la aplicación, recibiendo de esta manera
un 70% el desarrollador y el 30% restante se destina al partner de distribución. Por lo tanto, el precio total para publicar
nuestra app en la tienda Google Play Store será los 25 dólares (poco más de 20 euros) por darse de alta como
desarrollador, que sólo se deberá abonar la primera vez y después el 30% de la facturación total de la venta de las
aplicaciones que se tengan disponibles en la tienda también será para Google.