03 Herramientas Programacion Movil

Herramientas de Programación Móvil SEMANA 3 Activities e intents Todos los derechos de autor son de la exclusiva prop

Views 53 Downloads 5 File size 1MB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

Herramientas de Programación Móvil

SEMANA 3

Activities e intents

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni ESTE LAdeSEMANA 3 utilizarDOCUMENTO los contenidos paraCONTIENE fines comerciales ninguna clase.

1

ESTE DOCUMENTO CONTIENE LA SEMANA 3

2

ÍNDICE OBJETIVOS ESPECÍFICOS ........................................................................................................................... 4 INTRODUCCIÓN ...................................................................................................................................... 4 1.

ACTIVIDADES ............................................................................................................................... 5

2.

UN NUEVO PROYECTO ANDROID ................................................................................................ 5

3.

2.1.

BUILD.GRADLE ..................................................................................................................... 7

2.2.

LAYOUT ................................................................................................................................ 8

2.3.

STRINGS.XML ..................................................................................................................... 10

2.4.

EL ARCHIVO R .................................................................................................................... 11

2.5.

CÓDIGO JAVA .................................................................................................................... 11

2.5.1.

EL ENCABEZADO DE LA CLASE ................................................................................... 12

2.5.2.

EL MÉTODO ONCREATE() .......................................................................................... 12

2.5.3.

EL MÉTODO SETCONTENTVIEW() .............................................................................. 12

2.5.4.

EL MÉTODO FINDVIEWBYID() .................................................................................... 12

USO DE LOGCAT ........................................................................................................................ 13

COMENTARIO FINAL.......................................................................................................................... 15 REFERENCIAS........................................................................................................................................ 16

ESTE DOCUMENTO CONTIENE LA SEMANA 3

3

OBJETIVOS ESPECÍFICOS   

Describir los componentes básicos del SDK (widgets, como campos de texto, botones, entre otros). Identificar el uso de activities e intents en Android. Caracterizar el uso de logcat en aplicaciones desarrolladas en Android.

INTRODUCCIÓN Esta semana se comenzará con el trabajo de la primera aplicación de Android para la versión 2.3 (Gingerbread). Esta aplicación, si bien es cierto es muy básica, ayudará a explicar los conceptos necesarios para poder trabajar en cualquier otra aplicación que se necesite realizar. Dentro de las lecciones del presente curso, esta debe ser una de las más importantes, pues todo el desarrollo Android gira en torno a estos conceptos. El kit básico de construcción son los componentes que el desarrollador utiliza para construir aplicaciones Android, los ítems conceptuales que se unen para crear algo más grande. Cuando el desarrollador comienza a pensar en la aplicación, lo mejor es construirla desde la interfaz de usuario hacia las capas más internas: se comienza con las pantallas, características y las interacciones entre ellas. La idea es tener la visión general primero, ver cómo los componentes se unen y darse cuenta de cómo al final todo tiene sentido. Por ejemplo, Twitter: se sabe que el usuario debe ser capaz de escribir un mensaje y publicarlo, además de ver lo que escriben sus contactos. Estas son características básicas. Más allá de eso, el usuario podría ser capaz de escribir su nombre de usuario y password para autentificarse con su cuenta. Hasta acá, la aplicación debiera tener estas tres pantallas por lo menos. En un nivel mayor de abstracción, el usuario quisiera que la aplicación funcionara incluso con conexiones de red inestables o incluso sin conexión. Para lograr eso, la aplicación debe traer los datos de Twitter cuando está online y guardarlos en un caché local. En términos técnicos, se necesita un servicio que se ejecute en segundo plano y una base de datos. Para mejorar la experiencia, se necesita que el servicio en segundo plano se inicie cuando el dispositivo se encienda. De esta forma cuando el usuario inicie la aplicación, la última versión de los datos ya estará disponible. Estos requerimientos son directos. El kit de construcción básico hace que sea simple separar todo el proyecto en unidades conceptuales, de manera tal que sea fácil trabajar en ellas de forma independiente para después integrarlas en un paquete completo.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

4

1. ACTIVIDADES Una actividad es una pantalla que un usuario ve en un momento determinado. Una aplicación típicamente tiene muchas actividades y el usuario las cambia a través del tiempo. De esta manera, las actividades son la parte más visible de la aplicación. Comparando con un sitio web: un sitio web puede estar constituido de muchas páginas. De la misma manera una aplicación Android puede tener muchas actividades. Un sitio web tiene una página de inicio, y asimismo una aplicación Android tiene una actividad principal (main), que es la primera actividad que se ve al momento de iniciar la aplicación. Esta actividad, dentro del archivo manifest es la única que tiene los siguientes elementos:

Siguiendo con la analogía de la web, un usuario puede cambiar de un sitio a otro. Similarmente en Android un usuario puede usar la aplicación de Contactos, cambiar a la aplicación de Calculadora y finalmente cambiar a la aplicación de Mensajería. A este flujo se le conoce como el “ciclo de vida de la aplicación”.

2. UN NUEVO PROYECTO ANDROID Al momento de crear un nuevo proyecto Android, se genera una cierta cantidad de carpetas y archivos estándar. En el contenido de la semana anterior se abordó el archivo AndroidManifest.xml. Esta semana se centra en la carpeta “java”, que contiene el código fuente de la aplicación, la carpeta “res/layout”, que contiene la interfaz de usuario ligada al código java, y un archivo oculto llamado “R.class”, que ayuda a unir el código fuente con la interfaz de usuario. También se verá el contenido del archivo “build.grade” (el que está marcado como Module:app), que tiene la configuración de cómo debe ser compilado un proyecto, para qué versiones de Android y con qué bibliotecas.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

5

Estructura de archivos de un proyecto Android

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

ESTE DOCUMENTO CONTIENE LA SEMANA 3

6

2.1.BUILD.GRADLE Este archivo contiene toda la configuración que utilizará el compilador para generar la aplicación.

Estructura de un archivo de compilación gradle

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

En la captura de pantalla hay opciones como:     

compileSdkVersion: le dice al entorno de desarrollo qué versión de Android debe utilizar para compilar. Como este curso está centrado en Gingerbread, el SDK Versión es 10. minSdkVersion: especifica cuál es la versión más baja de Android que puede ejecutar la aplicación. 9 corresponde a Froyo (Android 2.2). targetSdkVersion: corresponde a la versión para la cual está diseñada la aplicación. applicationId: es el nombre único con el que se define la aplicación y el nombre de paquete que el sistema operativo utilizará para reconocerla. versionCode y versionName: corresponden a los números de versión de la aplicación. Estos números son definidos por el programador.

La opción “dependencias” corresponde a otras bibliotecas necesarias para el funcionamiento de la aplicación. Este tema se verá en semanas posteriores.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

7

2.2.LAYOUT Los archivos existentes en la carpeta Layout corresponden a la interfaz de usuario de las actividades. El código XML puede ser mostrado de forma gráfica para simplificar la forma de trabajarla. Las siguientes imágenes muestran la interfaz de usuario de una aplicación de ejemplo y cómo luce en formato XML:

Editor de interfaz de usuario

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

En la parte superior derecha de la pantalla se puede observar un árbol que contiene los elementos de la interfaz de usuario que están siendo utilizados (EditText, button y TextView). En la parte inferior derecha están las propiedades del elemento seleccionado en el sector superior y en la parte izquierda está la paleta completa de elementos que se pueden utilizar. Los elementos de la paleta pueden ser arrastrados tanto a la interfaz de usuario (al centro de la pantalla) como al árbol de controles de la derecha.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

8

Código fuente de la interfaz de usuario

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

Este es el código XML de la interfaz vista anteriormente, aquí se puede editar las propiedades de cada uno de los controles de forma manual. Se aprecia además que la interfaz de usuario está hecha sobre un “RelativeLayout” (otras alternativas son LinearLayout [horizontal] y LinearLayout [vertical]). RelativeLayout es la forma más versátil de disponer los elementos, pero a su vez la más compleja. Cada elemento se sitúa dentro del Layout como si fuera una calcomanía, de tal forma que al agregar un nuevo elemento este queda sobre el anterior. Es por esto que es obligatorio darle un identificador a cada elemento de la interfaz (utilizando el elemento XML “android:id”), de esta forma a cada nuevo elemento se le puede asignar un elemento android:layout_ que definirá quiénes son sus vecinos. En la captura de pantalla superior, el elemento “Button” tiene nombre “button” (android:id=”@+id/button”) y está debajo del elemento llamado “@id/editText” (android:layout_below=”@id/editText”). Notar que al momento de nombrar un elemento, el nombre es “@+id/nombre” y al momento de referenciarlo en un elemento distinto, no se incluye el signo “+” (@id/nombre).

ESTE DOCUMENTO CONTIENE LA SEMANA 3

9

2.3.STRINGS.XML El archivo de Strings contiene todas las palabras que se pueden utilizar a través de la interfaz (aquellos valores que pueden asignarse en los atributos “android:text”). La idea es no repetir palabras que puedan ser necesarias en otras partes de la aplicación, por ejemplo los textos “Aceptar”, “Cancelar”, “Sí” o “No” de los botones. Ejemplo de archivo strings.xml

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

En la imagen anterior hay cinco strings definidos. El string “app_name” es el nombre de la aplicación. Aparece en la parte superior de la aplicación y bajo el ícono del escritorio de Android (llamado Launcher). Para usar estos strings, al atributo android:text de algún elemento de la interfaz debe asignársele el valor “@string/nombre_del_string”. Por ejemplo, para que un botón diga “Saludar”, debe escribirse de esta forma: Ejemplo de uso de string

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

El atributo android:text debe verse de la siguiente forma: android:text=”@string/btn_saludar”

ESTE DOCUMENTO CONTIENE LA SEMANA 3

10

Cabe señalar que Android Studio reemplaza automáticamente los textos del tipo @string por su valor del archivo strings.xml, pero solo por legibilidad. Se puede deducir entonces que para los valores de los atributos de los elementos visuales se pueden utilizar recursos tanto definidos por el desarrollador como existentes en el sistema operativo utilizando “@” (@string, @color, @drawable, etc.).

2.4.EL ARCHIVO R Este archivo es el encargado de integrar la interfaz del usuario y el código Java. Es generado automáticamente y no debe ser modificado por el desarrollador. Se genera cada vez que hay algún cambio dentro de la carpeta “res”, esto es, cada vez que se agrega un ícono, un string o una interfaz de usuario completa. Lo importante de este archivo es que genera un mapa de todos los elementos existentes en la carpeta “res”. Este mapa está compuesto de números enteros y son estos números los que se utilizan en el código Java para hacer referencia a algún control, palabra, ícono o color existente dentro de la carpeta “res”.

2.5.CÓDIGO JAVA El código Java es donde converge todo. Es donde el desarrollador le otorga el comportamiento a la aplicación y orquesta todo lo que hizo en el XML. Código Java de una aplicación

Fuente: material elaborado para esta asignatura (Héctor Horta, 2015).

ESTE DOCUMENTO CONTIENE LA SEMANA 3

11

Partes importantes de este código son:

2.5.1. EL ENCABEZADO DE LA CLASE Todas las actividades heredan de una única clase: Activity. Entonces es obligatorio crear una clase que extienda a Activity. En el ejemplo: Public class HelloActivity extends Activity

2.5.2. EL MÉTODO ONCREATE() Este método es el primero que se ejecuta luego de tocar el ícono de una aplicación. Todo lo que sucede dentro de él se ejecuta mientras la aplicación está en primer plano: comportamiento cuando se toca un botón, comportamiento cuando se toca un campo de texto (EditText), cálculos que el desarrollador desee hacer, etc.

2.5.3. EL MÉTODO SETCONTENTVIEW() La llamada a este método es importantísima. Es la que une el archivo R (que contiene los índices de la interfaz de usuario, de ahora en adelante layout) con el código Java. En el ejemplo la línea dice: setContentView(R.layout.activity_hello);

No es casualidad que el entero pasado como parámetro al método se llame R.layout.activity_hello. El único layout existente para la aplicación de ejemplo se llama activity_hello.xml, entonces se puede deducir que R.layout.activity_hello guarda el índice de todos los elementos de la interfaz que se pueden utilizar.

2.5.4. EL MÉTODO FINDVIEWBYID() Este método retorna un objeto del tipo “View” desde el archivo R.class el control de la interfaz definido por su R.id (el id que se le otorgó dentro del xml del layout al que pertenece).

ESTE DOCUMENTO CONTIENE LA SEMANA 3

12

En el ejemplo, el id del botón es “button”, entonces para poder trabajar con el botón dentro de Java, se debe invocar: findViewById(R.id.button);

Como findViewById() retorna una vista y todos los elementos visuales de Android son vistas, basta con hacer un cast hacia el elemento que se necesita. Entonces el código queda: ButtonsaludarButton = (Button) findViewById(R.id.button);

Los botones no tienen un comportamiento por defecto y siempre se les debe asignar el método setOnClickListener(). En el ejemplo esto se ve de la siguiente manera:

saludarButton.setOnClickListener(new View.OnClickListener() { publicvoidonClick(View v) { } }); Dentro del método onClick(View v) se debe programar el comportamiento que se desea al momento de hacer tap en el botón.

3. USO DE LOGCAT Logcat es una herramienta del entorno de desarrollo a través de la cual se visualizan los mensajes de Log que emite el sistema operativo, además de los mensajes que el desarrollador quiera mostrar en él. En el código de ejemplo, el comportamiento de onClick() es el siguiente: Log.d(TAG, "Se hizo tap en el botón Saludar"); StringnombreDeUsuario = nombreUsuario.getText().toString(); Log.d(TAG, "Se obtuvo el nombre del campo EditText"); respuestaTextView.setText("Hola!, " + nombreDeUsuario); Log.d(TAG, "Se imprimió en pantalla el nombre");

ESTE DOCUMENTO CONTIENE LA SEMANA 3

13

El objeto Log muestra en la consola del desarrollador (no en la aplicación) procesos o mensajes respecto de lo que se está ejecutando. Existen tres tipos de Log:   

Log.d: mensajes de debug o control de errores. Sirven para entregar mensajes al desarrollador respecto a lo que está haciendo la aplicación. Log.e: mensajes de error. Las excepciones pueden ser escritas aquí. Log.w: mensajes de advertencia. Cuando el comportamiento programado no es el esperado, pero la aplicación puede seguir su flujo normal.

El resto de las líneas tienen que ver con el manejo de texto. Algunos elementos de la interfaz de usuario, como por ejemplo EditText, tienen métodos para obtener lo que se escribió dentro de ellos (getText()), pero no aseguran que lo retornado sea un string. Por eso es necesario realizar la conversión. Así como existe getText() para obtener el string de algún elemento, también existe el método setText() que permite escribir un string en ellos.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

14

COMENTARIO FINAL Esta semana se comenzó a trabajar dentro del entorno de desarrollo que se configuró en la semana 1 y dentro del archivo manifest visto en la semana 2. Se incluyó la primera actividad de la aplicación de ejemplo. También se profundizó en la programación haciendo la primera interfaz de usuario y el primer programa funcional Android. La comprensión de estos primeros pasos en el desarrollo de aplicaciones móviles es vital, ya que son estos los que se repiten una y otra vez en el desarrollo de la aplicación. En la próxima sesión se verá cómo incluir un menú en ella. En los recursos adicionales de la semana está el código completo de la aplicación de ejemplo presentada en este documento.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

15

REFERENCIAS Gargenta, M. (2011). Learning Android. California: O’Reilly.

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE: IACC (2015). Activities e intents. Herramientas de Programación Móvil. Semana 3.

ESTE DOCUMENTO CONTIENE LA SEMANA 3

16

ESTE DOCUMENTO CONTIENE LA SEMANA 3

17