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én
Escuela Politécnica Superior de Linares
Versión
1.0
Autor:
Juan Carlos Cuevas Martínez
Networking y gestión de tareas
en segundo plano para
comunicaciones

Tecnologías de comunicación inalámbrica
para terminales móviles Servicios 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. Sockets
2. 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.

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]

4
Versión 1.1
1. Procesos y tareas
1. Procesos
2. Hebras
3. Handlers - Manejadores de mensajes
4. Tareas asíncronas
5. Loaders
2. Comunicaciones con Android
1. Paquetes de comunicaciones de Android
2. Permisos de aplicación para acceso a las comunicaciones
3. Gestión del uso de la red
4. Clientes HTTP en Android
3. Servicios

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.

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.

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 visible
3. Proceso de servicio
4. Proceso en segundo plano
5. 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().

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

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

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

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

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

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)

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.
Protecció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)
Hebras 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.
Hebras de trabajo

22
Versión 1.1
 Ejemplo de mal uso: acceso con problemas al UI
Hebras de trabajo
public void onClick(View v) {
new Thread(new Runnable() {
public void run(){
Bitmap b =
loadImageFromNetwork("http://examp
le.com/image.png");
mImageView.setImageBitmap(b);}
}).start();
}

23
Versión 1.1
 Ejemplo de buen uso: acceso sin problemas al UI
Hebras de trabajo
new Thread(new Runnable() {
public void run(){
Bitmap b =
loadImageFromNetwork("http://example.com/im
age.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.
Problemas 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().
Funcionamiento 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();
Creació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);
}
}
Ejemplo: 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.

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);
}
}…
}
Ejemplo

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> { ... }
Detalles sobre uso de android.os.AsyncTask<Params, Progress, Result>

33
Versión 1.1
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);
}
}
…
}
Ejemplo

34
Versión 1.1
new DownloadImageTask().execute("http://example.com/image.png"); }
private class DownloadImageTask extends AsyncTask<String,
Integer, Bitmap>
{
@Override
protected void onProgressUpdate(Integer... values) {
progressBar.setProgress(values[0]);
progressBar.postInvalidate();
super.onProgressUpdate(values);
}
}…
}
Ejemplo

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.
Detalles 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()
Detalles sobre uso de AsyncTask

37
Versión 1.1
•se invoca en la hebra
UI antes de que la
tareas sea ejecutada.
onPreExecute()
• Puede hacer uso de
publishProgress(Progress...
) para comunicar el
progreso de una operación.
doInBackground()
•invocado en la hebra
UI tras una llamada a
publishProgress(Progr
ess...).
onProgressUpdate()
• Invocado en la
hebra UI después
de que la ejecución
en segundo plano
termine.
onPostExecute()
Pasos 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.
Pasos 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).
Reglas 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();
Cuadros 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ón
LoaderManager Clase abstracta asociada a un Activity o Fragment para
manejar las instancias a uno o varios Loader.
LoaderManager.Loade
rCallbacks
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.

47
Versión 1.1
.
Paquetes de comunicaciones de Android
Paquete Descripción
java.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ón
android.permission.INTERNET Acceso a Internet

49
Versión 1.1
Ejemplo
<?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 ()
android.permission.ACCESS_NETWORK_STATE Acceso al estado de la red

53
Versión 1.1
public void myClickHandler(View view){
...
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:
android.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";
...
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.

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 como
Protocol http scheme
Authority username:password@host:8080
User Info username:password
Host host
Port 8080
File /directory/file?query
Path /directory/file
Query query
Ref ref fragment

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.

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.

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.

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.

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…

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.

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.

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.

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.
<manifest ... >
...
<application ... >
<service android:name=".ExampleService" />
...
</application>
</manifest>

76
Versión 1.1
Definición del elemento Service
<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>

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).
<service android:enabled="true"
android:exported="true"
android:permission="string"
android:process="string" >
. . .
</service>

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.

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()

80
Versión 1.1
public int onStartCommand (Intent intent, int flags, int startId)
 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)

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.

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.

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.

84
Versión 1.1
Ciclo de vida

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

86
Versión 1.1
 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.

87
Versión 1.1
Gestionar el reinicio si el sistema mata el servicio
 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.

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.

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);
}
}

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

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (8)

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

Similar a Capítulo 3 diseño y gestión de acceso a servicios remotos (20)

Último

Último (9)

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