capítulo 3 diseño y gestión de acceso a servicios remotos

Servicios móviles

Dpto. de Ingeniería de TelecomunicaciónÁrea de Ingeniería Telemática

Universidad de JaénEscuela Politécnica Superior de Linares

Versión 1.0

Autor: Juan Carlos Cuevas Martínez

CAPÍTULO 3Diseño y gestión de acceso a servicios remotosNetworking y gestión de tareas en segundo plano para comunicaciones

Tecnologías de comunicación inalámbrica para terminales móvilesServicios Móviles

2



Versión 1.1

1. Conocer los tipos de procesos involucrados en una aplicación Android.

2. Conocer los detalles de las clases de comunicaciones a través de Internet y redes IP con Android.

1. Sockets2. HTTP

3. Conocer la problemática de la comunicaciones con Android.

4. Conocer como afrontar la gestión de tareas de comunicación en segundo plano.

OBJETIVOS


3



Versión 1.1

Android Developer, Processes and Threads, http://developer.android.com/intl/es/guide/components/processes-and-threads.html [Último acceso 11/2015]

Android Developer, Loaders. http://developer.android.com/intl/es/guide/components/loaders.html [Último acceso 11/2015]

ANDROID DESIGN PATTERNS, http://www.androiddesignpatterns.com [Último acceso 11/2015]

Android Developer. Services. developer.android.com/intl/es/guide/components/services.html [Último acceso 11/2015]

REFERENCIAS


4



Versión 1.1

1. Procesos y tareas1. Procesos2. Hebras3. Handlers - Manejadores de mensajes4. Tareas asíncronas5. Loaders

2. Comunicaciones con Android1. Paquetes de comunicaciones de Android2. Permisos de aplicación para acceso a las

comunicaciones3. Gestión del uso de la red4. Clientes HTTP en Android

3. Servicios

ÍNDICE


5



Versión 1.1

Por defecto una aplicación y todos sus componentes son ejecutados en un único proceso. Cuando un componente de una aplicación se inicia, y no había

ningún otro componente de la aplicación ejecutándose, el sistema Android inicia un nuevo proceso Linux para esa aplicación con un solo hilo de ejecución denominado main thread.

Si cuando se inicia un componente de una aplicación, ya existe un proceso para la misma, el componente se inicia en ese mismo proceso usando la misma hebra de ejecución.

Es posible que componentes de una aplicación se ejecuten en procesos separados.

Cualquier tarea lenta, o que pueda bloquear la hebra principal debe ejecutarse en una hebra aparte.

1. Procesos y tareas


6



Versión 1.1

Procesos Normalmente la aplicaciones no deberían necesitar ejecutar nada

fuera de su propio proceso, sin embargo, si lo necesitan, esto se debe hacer a través del fichero de manifiesto.

Cada entrada en el manifiesto para un componente (activity, service, receiver o provider) admite el atributo android:process.

El elemento <application> también soporta el atributo android:process, por lo que se puede cambiar el nombre del proceso por defecto donde se ejecutará la aplicación.



7



Versión 1.1

android:process

Procesos

android:process="string" Permite especificar el nombre del proceso donde se ejecutará ese

componente de la aplicación. Si el nombre comienza con dos puntos, ‘:’, el proceso será

privado a la aplicación. Si el nombre comienza con una letra minúscula creará un proceso

global con ese nombre, suponiendo que tenga permisos para eso. Este proceso podrá ser accedido desde componentes de otras aplicaciones, pudiendo conseguir un ahorro de recursos.


http://developer.android.com/guide/topics/manifest/activity-element.html


8



Versión 1.1

Procesos Android puede decidir eliminar cualquier proceso que se esté

ejecutando si la memoria disponible es escasa, y otros procesos, que están sirviendo al usuario más directamente, demandan más recursos.

Android decidirá, en función de la importancia para el usuario, qué proceso eliminar antes.

Android gestiona qué proceso es más importante a través de una jerarquía de 5 niveles



9



Versión 1.1

Ciclo de vida de un proceso

Procesos

Los cinco niveles de la jerarquía de importancia de Android son los siguientes (en prioridad decreciente):1. Proceso en primer plano.2. Proceso visible3. Proceso de servicio4. Proceso en segundo plano5. Proceso vacío.



10



Versión 1.1


Procesos

1. Proceso en primer plano: se considera un proceso en primer plano si se da alguna de estas condiciones: Si mantiene una Activity con la que el usuario está actualmente

interactuando (el método onResume() de la actividad ha sido llamado). Mantiene a un Service vinculado a una actividad con la que el usuario

está interactuando. Mantiene a un Service que se ejecuta en primer plano al haber sido

creado con startForeground(). Si mantiene a un Service que esté ejecutando una de las llamadas del

ciclo de vida (onCreate(), onStart(), o onDestroy()). Si mantiene a un BroadcastReceiver ejecutando su método onReceive()

.


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



http://developer.android.com/reference/android/app/Service.html











http://developer.android.com/reference/android/content/BroadcastReceiver.html




11



Versión 1.1


Procesos

1. Proceso en primer plano (continua) Normalmente hay muy pocos procesos en primer plano y tan sólo se

eliminan como último recurso. Un proceso en primer plano no se destruye a menos que la memoria

disponible sea tan escasa que no haya ni siquiera para mantenerlo a él mismo.



12



Versión 1.1

2. Proceso visible: Este proceso no tiene componentes en primer plano, pero aun afecta a lo que el usuario puede ver. Esto puede darse por dos razones: Una Activity no tiene elementos en primer plano, se ejecutó

onPause(), pero aun es visible. Esto puede suceder cuando una actividad en primer plano ejecuta un cuadro de diálogo que aún permite que se vea la aplicación previa.

Si mantiene un servicio vinculado a una actividad en primer plano o visible.

Los procesos visibles son muy importantes y no son eliminados a menos que sea necesario para mantener a un proceso en primer plano.

ProcesosCiclo de vida de un proceso



13



Versión 1.1

3. Proceso de servicio: mantiene a un servicio iniciado con startService() y que no corresponde con ninguna de las categorías anteriores. Los servicios, no necesariamente mantienen elementos gráficos que visualizar, sin embargo pueden realizar tareas muy interesantes para un usuario, tales como reproducir música o descargar ficheros de la red. Por lo tanto el sistema los mantiene en ejecución mientras no

sea necesario liberar memoria para un proceso en primer plano o visible.




14



Versión 1.1

4. Proceso en segundo plano: Una Activity que no es visible para el usuario (se ha ejecutado onStop()). Estos procesos no tienen efectos en la experiencia de usuario y pueden ser eliminados en cualquier momento cuando se necesita memoria. Se mantienen en la lista de usados recientemente LRU (least

recently used). Si la aplicación maneja bien su ciclo de vida y guarda su

estado, el usuario no notará ningún efecto cuando pulse el botón “back” y vuelvan a su estado visible.





15



Versión 1.1

5. Procesos vacíos: estos procesos no tienen ningún elemento en ejecución y el sistema los mantiene para tener una caché y acelerar la próxima vez que se arranquen. El sistema elimina estos procesos para mantener un balance

adecuado entre memoria y velocidad de carga.




16



Versión 1.1

Se debe tener en cuenta que Android intentará poner en el nivel tan alto como pueda a un proceso dependiendo de la importancia de los componentes del mismo.

Un proceso nunca puede tener un nivel inferior a otro proceso al que le está dando servicio.

Dado que los servicios tienen un nivel más alto que los procesos realizando tareas en segundo plano, se recomienda que las tareas de larga duración sean implementadas como servicios.




17



Versión 1.1

Cuando una aplicación comienza el sistema crea una hebra de ejecución denominada main.

La hebra main es la encargada de recibir todos los eventos y notificaciones de la interfaz de usuario (UI), de los todos los widgets, vistas y dibujado, por eso también se la suele llamar UI Thread.

Todos los componentes se ejecutan dentro de esta misma hebra de ejecución, así como los eventos (callbacks) o cambios en el ciclo de vida.

La hebra main es la encargada de entregar y gestionar los eventos producidos por los controles, tales como la pulsación en un botón.

Gestión de hebras de trabajo



18



Versión 1.1

Si en una aplicación se realiza un trabajo intensivo (operaciones de red o con bases de datos), debido al modelo de una sola hebra, esto puede derivar en un pobre comportamiento de la UI.

Si una operación se bloquea no se podrán entregar eventos, ni siquiera el redibujado, quedando el UI como colgado.

Aún más, si el UI Thread está bloqueado unos pocos segundos (tan sólo 5 actualmente), aparecerá el cuadro de diálogo ANR (application not responding)

Gestión de hebras de trabajo



19



Versión 1.1

El conjunto de aplicación del UI de Android (Android UI toolkit) no tiene protección entre hebras (thread-safe) por lo que no se debe manipular el UI en una hebra de trabajo.

Así pues se deben observar siempre dos sencillas reglas: No bloquear la hebra del UI. No acceder al Android UI toolkit fuera de la hebra de UI.

Gestión de hebras de trabajoProtección entre hebras de Android



20



Versión 1.1

Dadas las anteriores reglas, toda operación que no sea instantánea debe realizarse en una hebra separada. Puede usarse la clase Thread de Java y clases con la interfaz

Runnable. Para realizar operaciones que puedan afectar al UI en este

tipo de hebras existen varios métodos como: Activity.runOnUiThread(Runnable) View.post(Runnable) View.postDelayed(Runnable, long)

Gestión de hebras de trabajoHebras de trabajo



21



Versión 1.1

Sin embargo cuando la complejidad crece este tipo de soluciones se complican y son difíciles de mantener.

Se recomiendan: Usar un Handler para los eventos entre la hebra de trabajo y

la hebra de UI. Lo más recomendable: usar una tarea asíncrona de la clase

AsyncTask para procesar información en segundo plano. Loaders para la lectura y carga de información en actividades

y fragmentos.




22



Versión 1.1

Ejemplo de mal uso: acceso con problemas al UI


public void onClick(View v) { new Thread(new Runnable() {

public void run(){ Bitmap b = loadImageFromNetwork("http://example.com/image.png"); mImageView.setImageBitmap(b);}

}).start(); }



23



Versión 1.1

Ejemplo de buen uso: acceso sin problemas al UI


public void onClick(View v) { new Thread(new Runnable() {

public void run(){ Bitmap b = loadImageFromNetwork("http://example.com/image.png"); mImageView.post(new Runnable(){

public void run(){ mImageView.setImageBitmap(bitmap); }});

}).start(); }



24



Versión 1.1

Android aporta el paquete java.util.concurrent para controlar la concurrencia.

Sin embargo presenta características especiales que obligan a una sincronización con la hebra del UI para poder modificar el UI.

Además el manejo de hebras en Android tiene las siguientes desventajas: La sincronización con la hebra principal cuando se envían cambios al

UI. No hay una forma por defecto de cancelar una hebra. No hay una forma por defecto de ordenación (pooling) de hebras. No existe una manera por defecto de tratar los cambios de

configuración para una hebra.

Gestión de hebras de trabajoProblemas con las hebras



25



Versión 1.1

Un Handler se usa para enviar y procesar mensajes (clase Message) y objetos ejecutables (Runnable) asociados con la cola de mensajes de una hebra (MessageQueue).

Cada instancia de un Handler se asocia con la cola de mensajes de la hebra que lo está creando. A partir de ahí, puede enviar mensajes y ejecutables a esa cola de mensajes o ejecutarlos en cuanto salgan de dicha cola.

Dos son los usos principales de un Handler:1. Planificar mensajes y ejecutables para ser ejecutados en

algún momento en el futuro.2. Encolar una acción para que sea realizada por una hebra

diferente a la suya propia.

Handlers - Manejadores de mensajes



26



Versión 1.1

Si un Handler se instancia en una Activity, el objeto resultante puede usarse para enviar datos a la hebra principal.

Como ya se ha visto, la clase View permite enviar objetos del tipo Runnable a través del método post().

Handlers - Manejadores de mensajesFuncionamiento de un Handler



27



Versión 1.1

Para usar un Handler se debe crear una subclase y sobrecargar el método handleMessage() para procesar los mensajes.

La hebra puede enviar mensajes con sendMessage(Message) o sendEmptyMessage() a ese objeto.

Se puede reusar el Handler existente en una activity si no se quiere hacer un uso específico de éste:

handler = getWindow().getDecorView().getHandler();

Handlers - Manejadores de mensajesCreación y reusado de instancias de Handlers



28



Versión 1.1

public class Splash extends Activity { private static final int STOPSPLASH =2000; private static final long SPLASHTIME = 2000; //handler for splash screen private Handler splashHandler = new Handler() { @Override public void handleMessage (Message msg) {

switch (msg.what) { case STOPSPLASH: //Generating and Starting new intent on splash time out Intent intent = new Intent(getApplicationContext(),Second.class); startActivity(intent); Splash.this.finish(); break; } super.handleMessage(msg);

} };

@Override public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState); setContentView(R.layout.secondactivity); //Generating message and sending it to splash handle Message msg = new Message(); msg.what = STOPSPLASH; splashHandler.sendMessageDelayed(msg, SPLASHTIME); }

}

Handlers - Manejadores de mensajesEjemplo: splash screen

Ejemplo extraído de: http://examplesofandroid.com/using-handler-in-android



29



Versión 1.1

Usando la clase AsyncTask se puede realizar trabajo asíncrono en el interfaz de usuario.

En este tipo de tareas llevan a cabo las operaciones bloqueantes en una hebra de trabajo y luego publican los resultados en la hebra del UI.

No necesitan que el desarrollador implemente las hebras ni los handlers.

Tareas asíncronas - AsyncTask



30



Versión 1.1

Para usar este tipo de tareas se debe crear una clase derivada de AsyncTask e implementar su método doInBackground(), el cual es ejecutado junto a otros procesos en segundo plano.

Para modificar el UI se debe implementar onPostExecute(), el cual es el encargado de mostrar el resultado de doInBackground() y que es ejecutado en la hebra de UI.

La tareas se arranca ejecutando el método execute() de la nueva clase creada.

Tareas asíncronas - AsyncTask



31



Versión 1.1

…public void onClick(View v){

new DownloadImageTask().execute("http://example.com/image.png");}

private class DownloadImageTask extends AsyncTask<String, Void, Bitmap> {

protected Bitmap doInBackground(String... urls){

return loadImageFromNetwork(urls[0]); }

protected void onPostExecute(Bitmap result) { mImageView.setImageBitmap(result);

} }…

}

Tareas asíncronas - AsyncTaskEjemplo



32



Versión 1.1

AsyncTask puede especificar los tipos esperados para los parámetros de entrada, de progreso y el resultado a través de especificaciones genéricas a la hora de instanciar la clase. Los parámetros se usan de entrada en el método

doInBackground(Params...). El progreso se usa en las llamadas a publishProgress(Progress...) y

onProgressUpdate(Progress...). Y el resultado se usa en onPostExecute(Result) y es lo que devuelve

doInBackground(Params...). Si alguno de los parámetros no se necesita se declara como Void.

private class MyTask extends AsyncTask<Void, Void, Void> { ... }

Tareas asíncronas - AsyncTaskDetalles sobre uso de android.os.AsyncTask<Params, Progress, Result>



33



Versión 1.1

public void onClick(View v) {

new DownloadImageTask().execute("http://example.com/image.png"); }

private class DownloadImageTask extends AsyncTask<String, Integer, Bitmap> {

protected Bitmap doInBackground(String... urls){

return loadImageFromNetwork(urls[0]); }

protected void onPostExecute(Bitmap result) { mImageView.setImageBitmap(result);

} }

…}




34



Versión 1.1

public void onClick(View v) {

new DownloadImageTask().execute("http://example.com/image.png"); }

private class DownloadImageTask extends AsyncTask<String, Integer, Bitmap> {

@Overrideprotected void onProgressUpdate(Integer... values) {

progressBar.setProgress(values[0]);progressBar.postInvalidate();super.onProgressUpdate(values);

}

}…}




35



Versión 1.1

El método doInBackground() se ejecuta en una hebra de trabajo.

onPreExecute(), onPostExecute(), y onProgressUpdate() son todos invocados en la hebra de UI. Por lo tanto permiten hacer cambios en la interfaz de usuario.

El valor retornado por doInBackground() se envía a onPostExecute().

Se puede llamar en cualquier momento a publishProgress() en el método doInBackground() para ejecutar onProgressUpdate() en la hebra de UI.

Tareas asíncronas - AsyncTaskDetalles sobre uso de AsyncTask



36



Versión 1.1

La tarea se puede cancelar en cualquier momento desde cualquier hebra a través del método cancel(boolean) que originará las subsecuente llamadas a isCancelled() devuelvan true.

Además, en vez de onPostExecute(Object) cuando termine doInBackground() se llamará a onCancelled(Object).

Se debe comprobar el valor devuelto por isCancelled() periódicamente dentro de doInBackground()

Tareas asíncronas - AsyncTaskDetalles sobre uso de AsyncTask



37



Versión 1.1

• se invoca en la hebra UI antes de que la tareas sea ejecutada.

onPreExecute()

Tareas asíncronas - AsyncTaskPasos de la ejecución de AsyncTask



38



Versión 1.1

onPreExecute(), se invoca en la hebra UI antes de que la tareas sea ejecutada.

doInBackground(Params...), invocado justo cuando termine onPreExecute(). Puede hacer uso de publishProgress(Progress...) para comunicar el progreso de una operación, lo cual es ejecutado en la hebra principal en el método onProgressUpdate(Progress...).

onProgressUpdate(Progress...), invocado en la hebra UI tras una llamada a publishProgress(Progress...).

onPostExecute(Result), invocado en la hebra UI después de que la ejecución en segundo plano termine.

Tareas asíncronas - AsyncTaskPasos de la ejecución de AsyncTask. Resumen



39



Versión 1.1

La tarea AsyncTask debe ser siempre llamada desde la hebra de UI.

La instancia de la tarea se debe crear en la hebra de UI. El método execute(Params…) debe ser invocado en la hebra de

UI. Nunca llamar a los métodos onPreExecute(),

onPostExecute(Result), doInBackground(Params...), onProgressUpdate(Progress...) manualmente.

La tarea puede ejecutarse tan sólo una vez (si se intenta un relanzamiento se lanzará una excepción).

Tareas asíncronas - AsyncTaskReglas para el uso de AsyncTask



40



Versión 1.1

private ProgressDialog pbar = null;…

pbar = new ProgressDialog(mContext);pbar.setIndeterminate(true);pbar.setMessage(mContext.getString(R.string.dialogProgress));pbar.setProgressStyle(ProgressDialog.STYLE_SPINNER);pbar.setCancelable(false);pbar.show();…pbar.dismiss();

Tareas asíncronas - AsyncTaskCuadros de diálogo de progreso


Cuadro de progreso infinito

Ocultarlo


41



Versión 1.1

2. Loaders Se introdujeron en Android 3.0 para facilitar las carga

asíncrona de datos en una actividad o fragmento. Están disponibles para cada Activity y Fragment Proporcionan un mecanismo para la carga asíncrona de datos. Monitorizan la fuente de los datos y envían nuevos resultados

cuando el contenido cambia. Reconectan automáticamente al último cursor de carga al ser

recreados después de un cambio de configuración. No necesitan re-solicitar sus datos.


Información obtenida de:• http://developer.android.com/intl/es/guide/components/loaders.html• http://www.androiddesignpatterns.com


42



Versión 1.1

Resumen del API de Loaders

2. Loaders

Clase/Interfaz DescripciónLoaderManager Clase abstracta asociada a un Activity o Fragment para

manejar las instancias a uno o varios Loader.LoaderManager.LoaderCallbacks

Interfaz de llamadas a eventos para interactuar con el LoaderManager.

Loader Clase abstracta para realizar la lectura asíncrona de datos. Normalmente se usa CursorLoader, pero se puede usar como base para loaders personalizados.

AsyncTaskLoader Loader abstracto que proporciona una AsyncTask para hacer la tarea

CursorLoader Una subclase de AsyncTaskLoader que se conecta a un ContentResolver y devuelve un cursor.



43



Versión 1.1

LoaderManager

2. Loaders


Ayuda a que una aplicación pueda manejar operaciones de larga duración en conjunción con el ciclo de vida de la Actividad o fragmentos de la misma.

El uso más habitual es con CursorLoader, pero pueden crearse Loaders para la carga de otros tipos de datos.

Tan solo hay un LoaderManager por actividad o fragmento, pero puede tener varios Loaders.

Nota: un CursorLoader está pensado para trabajar con la calse ContentResolver que gestiona el accesos a proveedores de contenido.


44



Versión 1.1

Usando Loaders en una aplicación

2. Loaders

Una aplicación que use un cargador normalmente incluirá lo siguiente: Una Activity o Fragment. Una instancia a LoaderManager. Un CursorLoader para cargar datos de un ContentProvider (se podría

implementar una subclase de Loader o AsyncTaskLoader para cargar datos de otro tipo de fuentes).

Una implementación para LoaderManager.LoaderCallbacks. Para crear los cargadores y gestionar las referencias a los existentes.

Una manera de mostrar la información, como puede ser un SimpleCursorAdapter.

Una fuente de datos, como un ContentProvider si se usa un CursorLoader.



45



Versión 1.1

Iniciando un Loader

2. Loaders

El LoaderManager es el que gestiona todas las instancias de Loaders dentro de una Activity o Fragment.

Normalmente se inicializa en el método onCreate() en las actividades o en onActivityCreated() en los fragmentos.

getLoaderManager().initLoader(0, null, this);



46



Versión 1.1

Como Android está basada en un kernel de Linux® por lo que contiene una serie de capacidades de comunicaciones muy robustas y versátiles.

Podemos usar por tanto los conocimientos adquiridos al programar aplicaciones de red con Java, como las nuevas oportunidades que aporta Android.

2. Comunicaciones con Android


47



Versión 1.1

.

Paquetes de comunicaciones de Android

Paquete Descripciónjava.net Proporciona las clases multipropósito de Android tales como stream y datagram sockets, Internet

Protocol, y manejo genérico HTTP

java.io No es específicamente para red pero son muy importantes. Permiten la interacción con sockets y conexiones, a la vez que con los ficheros locales

java.nio Contiene clases que representa buffers de datos específicos que lo hacen útil para comunicaciones entre dos sistemas basados en Java

org.apache.* Proporciona clases y paquetes que permiten un control preciso sobre conexiones HTTP

android.net Contiene clases de acceso a red adicionales más allá de java.net.*. Este paquete incluye la clase URI que es muy usada en Android

android.net.http Contiene clases para manipular certificados SSL

android.net.wifi Contiene clases para gestionar todos los aspectos de la WiFi en la plataforma Android.



48



Versión 1.1

Permisos de aplicación para acceso a las comunicaciones Para que una aplicación tenga conectividad con

Internet debe de tener los permisos adecuados (en el archivo manifiest.xml), como por ejemplo:


Permiso Descripciónandroid.permission.INTERNET Acceso a Internet


49



Versión 1.1

Permisos de aplicación para acceso a las comunicacionesEjemplo<?xml version="1.0" encoding="utf-8"?><manifest

xmlns:android="http://schemas.android.com/apk/res/android"package="aptm.android.network"android:versionCode="1"android:versionName="1.0"> …<uses-permission android:name="android.permission.INTERNET"></uses-permission></manifest>



50



Versión 1.1

Comprobar el estado de la conexión a la red

Gestión del uso de la red

En un terminal móvil, antes de iniciar una conexión o envío de datos:1. Comprobar si se está conectado a alguna red.2. En el caso de no estar conectado, la aplicación debe responder

adecuadamente, informando al usuario y posibilitando acciones como activación de la conexión.

3. Si el tipo de conexión no es el adecuado, se debe informar de igual manera al usuario. Ejemplo: descarga masiva de datos por conexiones de red móviles.



51



Versión 1.1



Se usarán fundamentalmente dos clases: ConnectivityManager: permite realizar peticiones para comprobar el

estado de la red y su conectividad, así como también notifica a las aplicaciones de cambios en las conectividad de la red. Métodos típicos son getActiveNetworkInfo(). Obtener la referencia:

ConnectivityManager connMgr = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);

NetworkInfo: describe el estado de un interfaz de red de un determinado tipo, ya sea WI-FI o móvil. Un método típico es isConnected().



52



Versión 1.1



Para conocer el estado de la red deberemos añadir a fichero manifiest.xml de nuestra aplicación el siguiente permiso:

Esto nos permitirá acceder a algunos métodos de la clase ConnectivityManager que necesitan de este permiso, como por ejemplo:

public NetworkInfo getActiveNetworkInfo ()


Permiso Descripciónandroid.permission.ACCESS_NETWORK_STATE Acceso al estado de la red


53



Versión 1.1


Permisos de aplicación para acceso a las comunicaciones

public void myClickHandler(View view){ ... ConnectivityManager connMgr = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);

NetworkInfo networkInfo = connMgr.getActiveNetworkInfo(); if (networkInfo != null && networkInfo.isConnected()){ // obtener los datos } else { // mostrar el error } ...}



54



Versión 1.1

Cambiar estado de la red


La clase ConnectivityManager también permite cambiar la configuración del acceso a redes, pero para ello necesita del siguiente permiso en la aplicación:


Permiso Descripciónandroid.permission.CHANGE_NETWORK_STATE Cambiar e estado de la red


55



Versión 1.1

Detectar el tipo de interfaz con conexión


private static final String DEBUG_TAG = "NetworkStatusExample";... ConnectivityManager connMgr = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);

NetworkInfo networkInfo = connMgr.getNetworkInfo(ConnectivityManager.TYPE_WIFI); boolean isWifiConn = networkInfo.isConnected();

networkInfo = connMgr.getNetworkInfo(ConnectivityManager.TYPE_MOBILE);boolean isMobileConn = networkInfo.isConnected();

Log.d(DEBUG_TAG, "Wifi connected: " + isWifiConn);Log.d(DEBUG_TAG, "Mobile connected: " + isMobileConn);



56



Versión 1.1

Detectar cambios en el estado de la red


Es posible detectar los cambios en la conexión registrando un BroadcastReceiver para la acción CONNECTIVITY_ACTION. Algunos de los valores que se pueden obtener de los

extras son: boolean FAILOVER_CONNECTION (failover): intento

fallido de conexión con una red desconectada. boolean EXTRA_NO_CONNECTIVITY

(noConnectivity): desconexión. NetworkInfo, extra con clave networkInfo.



57



Versión 1.1

Clientes HTTP en Android Dado que la mayoría de aplicaciones emplea

conexiones con HTTP para el acceso e intercambio de información, Android proporciona dos clientes para esta función: HttpURLConnection y el HttpClient de Apache.

Ambos soportan: HTTPS, subida y bajada por streaming, timeouts

configurables, IPv6 y pooling de conexión.



58



Versión 1.1

Se recomienda el uso de HttpURLConnection para aplicaciones diseñadas para Android Gingerbread(API nivel 10 – Android 2.3.x) y superiores.

Clientes HTTP en Android

A partir de Android M preview se ha eliminado el soporte al cliente de Apache y se debe usar la clase HttpURLConnection.También se cambia de OpenSSL a BoringSSL.



59



Versión 1.1

Tareas de comunicaciones


Dado que las comunicaciones pueden ser procesos que se demoren en el tiempo y harían que la aplicación no respondiera, siempre se deben hacer en una hebra de trabajo, como las que proporciona la clase AsyncTask.



60



Versión 1.1

Clase URL


La clase URL proporciona una amplia variedad de métodos para la gestión de conexiones basadas en la especificación de URIs, concretamente URLs.

Formato genérico de una URL1 (RFC 3986):

<scheme>://<user>:<password>@<host>:<port>/<url-path>;<params>?<query>#fragment

1. Realmente, se define en la sintaxis ABNF



61



Versión 1.1

Clase URL


La clase URL proporciona una amplia variedad de métodos para la gestión de conexiones basadas en la especificación de URIs, concretamente URLs.

Formato genérico de una URL1 (RFC 3986):

<scheme>://<user>:<password>@<host>:<port>/<url-path>;<params>?<query>#ref

1. Realmente, se define en la sintaxis ABNF



62



Versión 1.1

Clase URL


Componente Valor de ejemplo También conocido comoProtocol http schemeAuthority username:password@host:8080User Info username:passwordHost hostPort 8080File /directory/file?queryPath /directory/fileQuery queryRef ref fragment


http://developer.android.com/reference/java/net/URL.html#getProtocol()

http://developer.android.com/reference/java/net/URL.html#getAuthority()

http://developer.android.com/reference/java/net/URL.html#getUserInfo()

http://developer.android.com/reference/java/net/URL.html#getHost()

http://developer.android.com/reference/java/net/URL.html#getPort()

http://developer.android.com/reference/java/net/URL.html#getFile()

http://developer.android.com/reference/java/net/URL.html#getPath()

http://developer.android.com/reference/java/net/URL.html#getQuery()

http://developer.android.com/reference/java/net/URL.html#getRef()


63



Versión 1.1

Clase URL



La clase URL puede ser usada para construir URL de diversos protocolos.

Protocolos soportados: file: lee ficheros del sistema local. ftp: File Transfer Protocol http: Hypertext Transfer Protocol https: HTTP sobre TLS jar: lee Jar files del sistema de archivos

Si se intenta crear una URL con otro protocolo se lanzará la excepción MalformedURLException. A pesar de todo, existe la posibilidad de soportar nuevos

protocolos si los implementa el desarrollador.

http://www.ietf.org/rfc/rfc959.txt






http://developer.android.com/reference/java/util/jar/JarFile.html

http://developer.android.com/reference/java/net/MalformedURLException.html


64



Versión 1.1

Clase URL



URLConnection openConnection(Proxy proxy) Devuelven una nueva conexión en función de la URL que almacena la clase.

URLConnection openConnection()

La clase Proxy permite informar de la dirección y tipo de proxy a través del cual se va a realizar la conexión• Proxy.Type DIRECT Direct connection. • Proxy.Type HTTP HTTP type proxy. • Proxy.Type SOCKS SOCKS type proxy.

http://developer.android.com/reference/java/net/URLConnection.html

http://developer.android.com/reference/java/net/URL.html#openConnection(java.net.Proxy)

http://developer.android.com/reference/java/net/Proxy.html

http://developer.android.com/reference/java/net/URLConnection.html

http://developer.android.com/reference/java/net/URL.html#openConnection()


65



Versión 1.1

URLConnection



File: lo recursos locales pueden cargarse usando URIs pero solo para lectura (input).

FTP: File Transfer Protocol (RFC 959) está soportado, pero sin una subclase. Las conexión FTP pueden usarse para leer o escribir, pero no

ambas. Por defecto el usuario es anonymous y la clave una cadena vacía.

Se pueden especificar otros diferentes en la URL:ftp://username:password@host/path.

HTTP y HTTPS: Este tipo de conexiones están soportadas en las subclases HttpURLConnection y HttpsURLConnection.

Jar: soportada en la subclase JarURLConnection.


http://developer.android.com/reference/java/net/HttpURLConnection.html

http://developer.android.com/reference/javax/net/ssl/HttpsURLConnection.html

http://developer.android.com/reference/java/net/JarURLConnection.html


66



Versión 1.1

Ejemplo URLConnection para FTP



URL url = new URL("ftp://mirror.csclub.uwaterloo.ca/index.html");URLConnection urlConnection = url.openConnection();InputStream in = new BufferedInputStream(urlConnection.getInputStream()); try { readStream(in); finally { in.close(); } }


67



Versión 1.1

Ejemplo HTTPUrlConnection



private String downloadUrl(String myurl) throws IOException { InputStream is = null; int len = 500; try { URL url = new URL(myurl); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setReadTimeout(10000 /* milliseconds */); conn.setConnectTimeout(15000 /* milliseconds */); conn.setRequestMethod("GET"); conn.setDoInput(true); conn.connect(); int response = conn.getResponseCode(); Log.d(DEBUG_TAG, "The response is: " + response); is = conn.getInputStream(); String contentAsString = readIt(is, len); return contentAsString; } finally { if (is != null) { is.close(); } }}


68



Versión 1.1

Clase HTTPUrlConnection. Descargar una imagen



InputStream is = null;...Bitmap bitmap = BitmapFactory.decodeStream(is);ImageView imageView = (ImageView) findViewById(R.id.image_view);imageView.setImageBitmap(bitmap);


69



Versión 1.1

Clase HTTPUrlConnection. Leer cadenas



public String readIt(InputStream stream, int len) throws IOException, UnsupportedEncodingException { Reader reader = null; reader = new InputStreamReader(stream, "UTF-8"); char[] buffer = new char[len]; reader.read(buffer); return new String(buffer);}


70



Versión 1.1

Los servicios con componentes de una aplicación pensados para realizar tareas a largo plazo en segundo plano.

No tienen interfaz de usuario. Son iniciados por algún otro

componente de una aplicación. Pueden seguir activos aunque el

usuario cambie a otra aplicación. Un componente de una aplicación

puede vincularse a un servicio cuando sea necesario para interactuar con él.

3. Servicios


71



Versión 1.1

Aplicaciones de los servicios Comunicaciones:

Subida o bajada de archivos. Mensajería y notificaciones. Actualizaciones.

Reproducir música. Manejo de la entrada y salida de

archivos. Gestión de bases de datos. Acceso a proveedores de contenido. Etc…

3. Servicios


72



Versión 1.1

Servicios iniciados (“started”)

Tipos de servicios

Comienzan cuando un componente de una aplicación (como una actividad) ejecuta startService().

Una vez iniciados pueden funcionar indefinidamente, incluso si el componente que lo creó es destruido.

Sus aplicaciones principales son aquellas que no requieren que quien lo creó reciba el resultado.

Normalmente se crean para llevar a cabo una sola tarea, finalizando el servicio cuando esta termina.

Ejemplos: Copiar archivos de una carpeta a otra. Descargar un recurso de Internet.

3. Servicios

http://developer.android.com/reference/android/content/Context.html#startService(android.content.Intent)

http://developer.android.com/reference/android/content/Context.html#startService(android.content.Intent)


73



Versión 1.1

Servicios vinculados (“bound”)

Tipos de servicios

Un servicio es de este tipo cuando un componente de una aplicación se vincula a él a través de bindService().

Proporcionan una interfaz cliente-servidor para su manejo: enviar peticiones, obtener resultados, incluso entre diferentes procesos.

Varios componentes pueden vincularse a un mismo servicio.

Un servicio vinculado está activo mientras tiene componentes que mantienen el vínculo con él. Si tiene varios componentes vinculados, cuando el último

libere el enlace, el servicio será eliminado.

3. Servicios

http://developer.android.com/reference/android/content/Context.html#bindService(android.content.Intent,%20android.content.ServiceConnection,%20int)

http://developer.android.com/reference/android/content/Context.html#bindService(android.content.Intent,%20android.content.ServiceConnection,%20int)


74



Versión 1.1

Tipos de servicios Funcionalmente se han visto dos tipos de

servicios: Servicios iniciados (“started”) Servicios vinculados (“bound”)

Si embargo un servicio puede trabajar de ambas maneras. Depende del método que se emplee para crearlos y

de las llamadas (callbacks) que implementen: onStartCommand() para permitir que los

componentes lo inicien. onBind() para permitir que sea vinculado.

3. Servicios


75



Versión 1.1

Declarando un servicio en el manifiesto de Android Como los demás componentes de una aplicación,

todos los servicios deben declararse en el manifiesto de Android, dentro del elemento application.

3. Servicios

<manifest ... > ... <application ... > <service android:name=".ExampleService" /> ... </application></manifest>


76



Versión 1.1

Definición del elemento Service

Declarando un servicio en el manifiesto de Android

<service android:enabled=["true" | "false"] android:exported=["true" | "false"] android:icon="drawable resource" android:isolatedProcess=["true" | "false"] android:label="string resource" android:name="string" android:permission="string" android:process="string" > . . .</service>

3. Servicios

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#enabled

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#exported

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#icon

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#isolated

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#label

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#nm

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#prmsn

http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#proc


77



Versión 1.1

Acceso a un servicio


Independientemente del tipo de servicio, cualquier aplicación puede indicar un servicio.

Si no se desea permitir esto, se debe declarar como privado en el manifiesto (android:exported="false"). Si tienen declarado un intent-finter el valor por defecto es “true”, si no, es

“false” porque se supone que es para uso interno. Aunque un servicio sea exportable, se puede limitar su acceso a aquellas

aplicaciones que tengan un determinado permiso (android:permission).

3. Servicios

<service android:enabled="true" android:exported="true" android:permission="string" android:process="string" > . . .</service>

Pueden ejecutarse en su propio proceso



http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#enabled



http://developer.android.com/intl/es/guide/topics/manifest/service-element.html#proc


78



Versión 1.1

Ejecutando un servicio


Un servicio es ejecutado en la hebra principal de su proceso anfitrión: Por defecto no crean su propia hebra ni crean

su propio proceso. Como se ha comentado pueden ser

ejecutados en un proceso aparte si así se especifica en el AndroidManifiest.xml.

Si un servicio va a realizar una tarea que haga un uso intensivo de la CPU, operaciones bloqueantes como reproducir un MP3 o acceder a la red deben crear su propia hebra.

3. Servicios


79



Versión 1.1

Funcionamiento básico El primer paso para crear un servicio es crear una clase

que herede de Service. Después sobre escribir algunos métodos de eventos

para: Soportar aspectos clave del ciclo de vida. Proporcionar mecanismos para poder vincular el servicio, si

fuera necesario. Los métodos más importantes son:

onStartCommand() onBind() onCreate() onDestroy()

3. Servicios

http://developer.android.com/reference/android/app/Service.html#onStartCommand(android.content.Intent,%20int,%20int)


http://developer.android.com/reference/android/app/Service.html#onBind(android.content.Intent)


http://developer.android.com/reference/android/app/Service.html#onCreate()

http://developer.android.com/reference/android/app/Service.html#onCreate()

http://developer.android.com/reference/android/app/Service.html#onDestroy()

http://developer.android.com/reference/android/app/Service.html#onDestroy()


80



Versión 1.1

public int onStartCommand (Intent intent, int flags, int startId)

Funcionamiento básico

El sistema llama a este método cuando otro componente (como una actividad) solicita iniciar un servicio con startService().

Una vez este método finaliza el servicio se ejecutará en segundo plano indefinidamente.

El servicio tan solo se parará con stopSelf() o stopService() (o por el sistema si hay pocos recursos disponibles)

3. Servicios

http://developer.android.com/reference/android/app/Service.html#stopSelf()

http://developer.android.com/reference/android/app/Service.html#stopSelf()

http://developer.android.com/reference/android/content/Context.html#stopService(android.content.Intent)

http://developer.android.com/reference/android/content/Context.html#stopService(android.content.Intent)


81



Versión 1.1

public abstract IBinder onBind (Intent intent)


El sistema llama a este método cuando otro componente quiere vincular un servicio con la llamada bindService().

Se debe devolver un interfaz Ibinder para poder acceder al servicio.

Si no se quiere soportar la vinculación este método debe devolver null.

3. Servicios


82



Versión 1.1

public void onCreate ()


El sistema llama a este método cuando el servicio se crea por primera vez.

En él se deben realizar funciones de inicialización y configuración que deban tener lugar una sola vez.

El sistema después llamará a onStartCommand() o onBind().

Nunca se debe llamar a este método en otra parte del código.

3. Servicios






83



Versión 1.1

public void onDestroy ()


El sistema llama a este método cuando el servicio ya no va a ser usado más y va a ser destruido.

En este método se deben realizar todas las tareas de liberación de recursos necesarias, como hebras, listeners, receptores de difusión, etc.

Es la última llamada que recibe un servicio.

3. Servicios


84



Versión 1.1

Ciclo de vida


3. Servicios


85



Versión 1.1

Crear un servicio autónomo (started) El ciclo de vida de un servicio autónomo es

independiente del ciclo de vida del componente que lo creó.

Puede estar en ejecución de manera indefinida. El servicio puede detenerse a sí mismo cuando

termine su tarea con stopSelf(). Otro componente puede eliminarlo usando el

método stopService().

3. Servicios


86



Versión 1.1

Crear un servicio autónomo (started) Un componente inicia un servicio pasando un Intent con

definiendo el servicio y con los parámetros necesarios, que es recibido por el método onStartCommand().

Normalmente se emplean dos clases como base para este tipo de servicios: Service: es la clase base para todos los servicios. Si se emplea,

es fundamental crear una nueva hebra donde se realiza todo el trabajo del servicio.

IntentService: Es una subclase de Service que incorpora una hebra de trabajo para manejar todas la peticiones de comienzo, de una en una. Es la mejor opción si no se necesitan llamadas simultáneas. Simplemente se tiene que implementar el método

onHandleIntent(), el cual recibe el Intent para realizar el trabajo.

3. Servicios


87



Versión 1.1

Gestionar el reinicio si el sistema mata el servicio

Crear un servicio autónomo (started)

START_NOT_STICKY: Si el sistema mata el servicio después de que termine onStartCommand(), no vuelve a crear el servicio, a menos que tenga intents pendientes de repartir. Es la opción mas segura cuando para que un servicio que no es necesario no se

ejecute. La aplicación simplemente lo reiniciará si lo necesita.

START_STICKY: Si el sistema mata el servicio después de que termine onStartCommand(), re-crea el servicio y llama a onStartCommand(), pero no con el último intent, sino con un intent nulo si no hubiera intents pendientes. Es una opción apropiada para reproductores en segundo plano.

START_REDELIVER_INTENT: en este caso el sistema pasa el último intent enviado y los pendientes se pasarán en orden. Es apropiado para tareas cuya tarea debe ser inmediatamente retomada, como la

descarga de ficheros.

3. Servicios

http://developer.android.com/reference/android/app/Service.html#START_NOT_STICKY



http://developer.android.com/reference/android/app/Service.html#START_STICKY





http://developer.android.com/reference/android/app/Service.html#START_REDELIVER_INTENT


88



Versión 1.1

Crear un servicio vinculado (bound) Se crean llamando a bindService(). Devuelven una clase que implemente el interfaz

IBinder(), la clase Binder. Se deber crear una clase que extienda Binder

para dar los servicios que se deseen.

3. Servicios


89



Versión 1.1

Ejemplo

Crear un servicio vinculado (bound)

public class LocalService extends Service { // Binder given to clients private final IBinder mBinder = new LocalBinder(); // Random number generator private final Random mGenerator = new Random();

public class LocalBinder extends Binder { LocalService getService() { // Return this instance of LocalService so clients can call public methods return LocalService.this; } }

@Override public IBinder onBind(Intent intent) { return mBinder; }

/** method for clients */ public int getRandomNumber() { return mGenerator.nextInt(100); }}

3. Servicios