Академический Документы
Профессиональный Документы
Культура Документы
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 Desventajas
Acceso completo a dispositivo Diferentes habilidades/idiomas/herramientas
Para cada destino
Mejor experiencia de usuario Tienden a ser mas caras de desarrollar
Visibilidad en App Store El código del cliente tiende a no ser reutilizable
Envio de notificaciones o avisos a usuario
La actualización del app es constante
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 Desventajas
Posible distribuir en IOS y ANDROID Experiencia de usuario mas a web que a
aplicación nativa
Instalacion Nativa, construida con JS,HTML Diseño visual no siempre relacionado con el
y CSS sistema OP en el que se muestre
Mismo código base para multiples
plataformas
Acceso a parte del hardware
Los Sistemas Operativos de los dispositivos móviles y sus entornos de Desarrollo para
aplicaciones (IDE)
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:
/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:
super.onCreate(savedInstanceState);
...
super.onStart();
...
super.onRestart();
...
super.onResume();
...
...
super.onPause();
...
onStop();
}
super.onDestroy();
<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>
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.