"Android de la A a la Z" -- Unidad 9

Android de la A a la Z

Unidad 9 “Redes”

1 Elaborado por: J. Ulises González Medina [email protected] Noviembre 2011 Versión 1.2

Introducción

Todo operador móvil admite redes de voz y datos de varios tipos. La parte más interesante de los

dispositivos de Android es la red de datos, junto con la posibilidad de vincular los datos de una red a

distintas aplicaciones. Estas aplicaciones se pueden generar con el enfoque basado en Intent y Service

descrito en capítulos anteriores.

Dicho enfoque combina intents incorporados (o personalizados) como navegación Web, con acceso a

componentes de hardware como un subsistema gráfico 3D, un receptor GPS, una cámara, almacenamiento

extraíble, etc. Esta combinación de plataforma abierta, opciones de hardware, arquitectura de software y

acceso a redes de datos es lo que hace que Android resulte tan atractivo.

Con esto no afirmamos que la red de voz no sea importante (como veremos en un capítulo posterior) pero

al hablar de redes nos centraremos en los datos.

En términos de la red de datos, Android proporciona acceso de distintas formas: redes móviles IP

(Protocolo de Internet), Wi-Fi y Bluetooth. En este caso nos centraremos en comunicar aplicaciones de

Android con redes IP, a través de distintos enfoques.

En términos de propiedades de conectividad, utilizaremos la clase ConnectivityManager para determinar

cuándo está activa la conexión de red y de qué tipo es (móvil o Wi-Fi). A partir de aquí, utilizaremos la red

de distintas formas con las aplicaciones de ejemplo.

En este capítulo sobre redes no nos adentraremos en los detalles relacionados con las API Bluetooth o Wi-Fi

de Android. Bluetooth es una tecnología importante para redes inalámbricas entre dispositivos pero las API

relacionadas con Android no están todavía completas (incluso en el SDK 1.0). Los dispositivos Android

admiten Bluetooth pero de forma limitada y no está disponible en el emulador. Wi-Fi, por su parte, no

cuenta con el correspondiente API y tampoco con una capa de emulación. Como el emulador no distingue

el tipo de red utilizada y desconoce todo lo relacionado con Bluetooth y Wi-Fi, y como creemos que la

importancia radica en cómo se utiliza la red, no analizaremos estas API. Si necesita más información al

respecto, consulte la documentación de Android

http://code.google.com/android/reference/android/net/wifi/package-summary.html

http://code.google.com/android/reference/android/net/wifi/package-summary.html




En la aplicación de este capítulo, NetworkExplorer, veremos formas de comunicarnos con la red en Android

e incluiremos diversas utilidades. En última instancia, esta aplica¬ción tendrá varias pantallas para

diferentes técnicas de red

Tras analizar la red IP general y su relación con Android, veremos cómo convertir el servidor en un API más

robusto por medio de servicios Web. Trabajaremos con XML sobre HTTP (POX) y REST (Transferencia de

Estado de Representación). Además, describiremos el protocolo SOAP (Protocolo de Acceso Sencillo a

Objetos). Analizaremos las ventajas e inconvenientes de los distintos enfoques y las razones para elegir uno

u otro para un cliente Android.

Antes de adentrarnos en los detalles de aplicaciones Android en red, repasaremos los conceptos básicos. Si

ya dispone de sólidos conocimientos sobre redes puede pasar al siguiente apartado pero es importante

contar con esta base para el futuro.

Redes por todos lados. Conceptos básicos

Un grupo de equipos interconectados es una red. Con el tiempo, las redes han pasado de ser algo

disponible únicamente para gobiernos y grandes empresas a convertirse en la sorprendente Internet.

Aunque el concepto es sencillo, permitir la comunicación entre ordenadores, las redes implican cierta

tecnología avanzada. No abordaremos todos los detalles pero sí los conceptos básicos de las redes

generales.

En la mayoría de los casos, las API utilizadas para programar aplicaciones Android abstraen los detalles de

red subyacentes. Lo que es positivo. Las API y los protocolos de red se han diseñado para que nos

centremos en las aplicaciones y no nos preocupemos por enrutadores y entrega de paquetes.

No obstante, conviene conocer el funcionamiento de una red para mejorar el diseño y la resolución de

errores de nuestras aplicaciones. Para ello, analizaremos algunos de los conceptos generales de redes, con

parada en TCP/IP (Protocolo de Control de Transmisiones/Protocolo de Internet). Comenzaremos con

nodos, capas y protocolos.




Nodos y más nodos

El concepto básico de una red es que los datos se envíen entre dispositivos conectados con determinadas

direcciones. Las conexiones se pueden realizar a través de cables, ondas de radio, etc. Cada dispositivo con

dirección se denomina nodo. Un nodo puede ser una centralita, un PC o cualquier otro dispositivo con una

pila de red y conectividad, como un dispositivo manual de Android.

El protocolo TCP/IP

Los protocolos son un conjunto de reglas de comunicación predefinidas y

acordadas. Suelen situarse unos sobre otros ya que asumen distintos niveles de

responsabilidad. Por ejemplo, en la pila TCP/IP, utilizada en la mayoría de tráfico

Web de todo tipo y con Android, las capas principales son las siguientes:

La capa de enlace, que incluye protocolos de resolución de direcciones de

dispositivos físicos como ARP, RARP y otros.

La capa de Internet, que incluye el propio IP, con varias versiones, y los

protocolos ping, ICMP, entre otros.

La capa de transporte, donde encontramos distintos protocolos de

entrega como TCP y UDP.

La capa de aplicaciones, que incluye protocolos conocidos como HTTP,

FTP, SMTP, IMAP, POP, DNS, SSH y SOAP.

Las capas son una abstracción de los distintos niveles de una pila de protocolos de red. El nivel más bajo, la

capa de enlace, se preocupa de dispositivos y direcciones físicos. El siguiente nivel, la capa de Internet, se

preocupa de direcciones y detalles de datos generales. Tras ésta, la capa de transporte se encarga de los

detalles de entrega. Por último, los protocolos de capa de aplicaciones de nivel superior utilizan la capa

situada debajo y son específicos de cada aplicación para enviar archivos y correo electrónico o ver páginas

Web.




Direcciones IP

IP se encarga del sistema de direcciones y de la entrada de datos en pequeños fragmentos denominados

paquetes. Los paquetes, conocidos en términos IP como datagramas, definen la cantidad de datos de cada

fragmento, los límites de carga e información de encabezados, etc. Las direcciones IP indican de dónde

proviene cada paquete (su origen) y a dónde se dirige (su destino).

Las direcciones IP tienen distintos tamaños en función de la versión del protocolo utilizado pero sin duda el

más habitual actualmente es el de 32 bits. Las direcciones IP de 32 bits (IPv4) se suelen escribir en una

notación decimal que separa los 32 bits en cuatro secciones, cada una para representar 8 bits (octeto)

como por ejemplo 74.125.45.100.

Determinadas clases de direcciones IP tienen un papel y un significado especiales. Por ejemplo, 127

siempre identifica una dirección local del equipo; esta clase no se comunica con otros dispositivos

(solamente se puede utilizar dentro de un equipo). Las direcciones que empiezan por 10 ó 192 se pueden

comunicar con otros dispositivos del mismo segmento de red local pero no con otros segmentos. Todas las

direcciones de un segmento de red concreto deben ser exclusivas para evitar conflictos.

El enrutamiento de paquetes en una red IP, cómo recorren la red y pasan de un segmento a otro, se realiza

en enrutadores. Los enrutadores se comunican entre sí por medio de direcciones IP y otra información

relacionada con IP.

Clase Formato (r=red, h=host)

Número de redes

Número de hosts por

red

Rango de direcciones de redes

Máscara de subred

A r.h.h.h 128 16777214 0.0.0.0 - 127.0.0.0 255.0.0.0

B r.r.h.h 16384 65534 128.0.0.0 - 191.255.0.0 255.255.0.0

C r.r.r.h 2097152 254 192.0.0.0 - 223.255.255.0 255.255.255.0

D grupo - - 224.0.0.0 - 239.255.255.255 -

E no válidas - - 240.0.0.0 - 255.255.255.255 -




TCP vs UDP

TCP y UDP son distintos tipos de protocolos de entrega que se suelen utilizar con TCP/IP. TCP es fiable y

UDP es más directo. Esto quiere decir que TCP incluye datos adicionales para garantizar el orden de los

paquetes y para enviar un acuse de recibo (como sucede con el correo certificado tradicional). UDP, por su

parte, no proporciona orden ni acuse de recibo (es como una carta normal, más barata y rápida de enviar

pero no sabemos si el destinatario la recibirá).

UDP TCP

Servicio sin conexión; no se establece una sesión entre los

hosts.

Servicio orientado a la conexión; se establece una sesión entre los

hosts.

UDP no garantiza ni confirma la entrega, y no secuencia los datos.

TCP garantiza la entrega mediante el uso de confirmaciones y la

entrega secuenciada de datos.

Los programas que utilizan UDP son responsables de proporcionar la confiabilidad necesaria para el

transporte de datos.

Los programas que utilizan TCP proporcionan la seguridad del transporte de datos confiable.

UDP es rápido, tiene requisitos de carga pequeños y puede admitir la comunicación punto a punto y de

un punto a varios puntos.

TCP es más lento, tiene requisitos de carga mayores y sólo admite la

comunicación punto a punto.




Protocolos de aplicaciones

Después de enviar y entregar un paquete, la aplicación toma el control.

Para enviar un mensaje de correo, por ejemplo, SMTP define un riguroso

conjunto de procedimientos. Es necesario saludar y presentarse de una

forma concreta; después proporcionar información de origen y destino,

seguida por un mensaje en un formato concreto. Del mismo modo, HTTP

define el conjunto de reglas para Internet, qué métodos se permiten

(GET, POST, PUT, DELETE) y el funcionamiento general del sistema de

solicitudes y respuestas entre cliente y servidor.

Al trabajar con Android y API relacionadas con Java en general, no es necesario adentrarse en los detalles

de nivel inferior pero sí conocer sus principales diferencias para la resolución de problemas, así como tener

conocimientos sobre direcciones IP. Además, es aconsejable conocer el funcionamiento de clientes y

servidores, y cómo se establecen las conexiones a través de puertos.

Puertos

Todo el que haya utilizado un navegador Web está familiarizado con el modelo infor¬mático de

cliente/servidor. Los datos, en cualquier formato, se almacenan en un potente servidor centralizado. Los

clientes se conectan a dicho servidor a través de un protocolo concreto (como HTTP) para recuperar los

datos y utilizarlos.

Este patrón es evidentemente mucho más antiguo que la Web y se ha aplicado

prácticamente en todo desde terminales conectadas a sistemas centrales hasta

modernas aplicaciones de escritorio que se conectan a un servidor para realizar

parte de sus operaciones (como iTunes, básicamente un organizador y reproductor

multimedia pero que también tiene una tienda donde los clientes se conectan a un




servidor para conseguir nuevos contenidos). En cualquier caso, el concepto es el mismo: el cliente realiza

una solicitud al servidor y éste responde.

Es el mismo modelo empleado por la mayoría de aplicaciones Android, al menos de las que usan un

servidor (por lo general, las aplicaciones Android suelen acabar como cliente).

Para procesar varias solicitudes cliente, para distintos propósitos, que una

dirección IP reciba simultáneamente, los sistemas operativos de servidor

modernos recurren al concepto de puertos.

Los puertos no son físicos; son una representación de una determinada zona

de memoria del ordenador. Un servidor puede escuchar en varios puertos

designados en una misma dirección; por ejemplo, un puerto para enviar

correo electrónico, otro para el tráfico Web, dos para la transferencia de

archivos, etc.

Todo equipo con una dirección IP también admite miles de puertos para habilitar múltiples conversaciones

simultáneas. Los puertos se dividen en tres categorías:

Los puertos conocidos se publican y son simplemente eso, conocidos, HTTP es el puerto 80 (y HTTPS, el

puerto 443), FTP utiliza los puertos 20 (control) y 21 (datos), SSH es el puerto 22, SMTP es el puerto 25, etc.

Tras éstos, los puertos registrados siguen estando controlados y publicados pero para funciones más

concretas. Suelen utilizarse para una determinada aplicación o empresa; por ejemplo, MySQL es el puerto

3306 (de forma predeterminada). Si necesita más información al respecto, consulte el documento de

números de puerto ICANN.

Los puertos dinámicos o privados no están registrados intencionadamente ya que los utiliza la pila TCP/IP

para facilitar las comunicaciones. Se registran dinámicamente en cada ordenador y se utilizan en la

conversación. El puerto dinámico 49500, por ejemplo, se puede utilizar para enviar una solicitud a un

servidor Web y procesar la respuesta posterior. Una vez terminada la conversación, el puerto se reclama y

se puede reutilizar localmente para otra transferencia de datos.

Así pues, clientes y servidores se comunican como los nodos con direcciones, por medio de puertos en una

red que admite varios protocolos. Los protocolos implicados en Android se basan en la red IP en la que

participa la plataforma. Antes de crear una aplicación Android cliente/servidor completa con la red, es

necesario determinar el estado de la conexión.




Checando el estado de la red

Android ofrece multitud de utilidades para determinar la configuración de los dispositivos y el estado de

diversos servicios, incluida la red. Normalmente se utiliza la clase ConnectivityManager para determinar si

hay conectividad de red y para saber cambios en la misma. El listado 6.1 muestra parte de la actividad

principal de la aplicación NetworkExplorer, para ilustrar el uso básico de ConnectivityManager.

@Override

public void onStart() {

super.onStart();

ConnectivityManager cMgr = (ConnectivityManager)

getSystemService(Context.CONNECTIVITY_SERVICE);

NetworkInfo netInfo = cMgr.getActiveNetworkInfo();

this.status.setText(netInfo.toString());

}

Este breve ejemplo demuestra que se puede acceder a ConnectivityManager a tra¬vés del método

getSystemService del contexto si pasamos la constante CONNECTIVY_ SERVICE. Una vez conseguido,

podemos obtener información de red a través del objeto Networklnfo.

El objeto Networklnfo también permite acceder a información más detallada pero por lo general basta con

la información básica (a menos que sea un caso especial como la creación de una aplicación de

administración del estado de la red).

Una vez que sabemos que estamos conectados, ya sea a través de móvil o Wi-Fi, podemos usar la red IP.

Para nuestra aplicación NetworkExplorer, comenzaremos con la conexión IP más rudimentaria, un socket,

hasta llegar a HTTP y los servicios Web.

Establecer comunicación con un socket de servidor

Un socket de servidor es un flujo en el que puede leer o escribir bytes sin procesar, en una dirección IP y

puerto concretos. De este modo puede centrarse en los datos sin preocuparse de tipos de medios, tamaños

de paquetes, etc. Es otra abstracción de red que pretende facilitar la labor del programador. La filosofía de

los socket de que todo debe parecer E/S de archivos para el programador, proviene de la familia de

estándares POSIX, que han adoptado la mayoría de sistemas operativos actuales.

Antes de pasar a los niveles superiores de la comunicación por red, comenzaremos con un socket sin

procesar. Para ello necesitamos un servidor que escuche en un puerto concreto. El código EchoServer

(mostrado más abajo) se encarga de este aspecto. No es una clase específica de Android, sino un servidor

simplificado que se puede ejecutar en cualquier equipo anfitrión con Java. Posteriormente nos

conectaremos al mismo desde un cliente Android.

public final class EchoServer extends Thread {

private static final int PORT = 8889;

private EchoServer() {

}




public static void main(final String args[]) {

EchoServer echoServer = new EchoServer();

if (echoServer != null) {

echoServer.start();

}

}

public void run() {

try {

ServerSocket server = new ServerSocket(PORT, 1);

while (true) {

Socket client = server.accept();

System.out.println("Client connected");

while (true) {

BufferedReader reader = new BufferedReader(new

InputStreamReader(client.getInputStream()));

System.out.println("Read from client");

String textLine = reader.readLine() + "\n";

if (textLine.equalsIgnoreCase("EXIT\n")) {

System.out.println("EXIT invoked, closing client");

break;

}

BufferedWriter writer = new BufferedWriter(new

OutputStreamWriter(client.getOutputStream()));

System.out.println("Echo input to client");

writer.write("ECHO from server: " + textLine, 0, textLine.length() +

18);

writer.flush();

}

client.close();

}

} catch (IOException e) {

System.err.println(e);

}

}

}

La clase EchoServer es básicamente E/S de Java. Amplía Thread e implementa run, de modo que cada

cliente conectado se puede procesar en su propio contexto. Tras ello utilizamos ServerSocket para escuchar

en un puerto definido. Cada cliente es, por tanto, una implementación de Socket. La entrada del cliente se

añade a BufferedReader del que se lee cada línea. La única consideración de este sencillo servidor es que si

la entrada es EXIT, acaba el bucle y sale. Si la entrada no solicita la salida, el servidor reproduce la entrada

en el OutputStream del cliente por medio de BufferedWriter.

Es una representación muy básica del funcionamiento de un servidor. Procesa las entradas, normalmente

en un subproceso independiente, y después responde al cliente en función de las mismas. Para probar el

servidor antes de utilizar Android, puede acceder por medio de telnet al puerto especificado (una vez

ejecutado el servidor) e introducir una entrada; si todo funciona correctamente, reproducirá el resultado.

Para ejecutar el servidor debe invocarlo localmente con Java. Tiene un método principal, de modo que se

ejecuta independientemente; comience desde la línea de comandos o desde el IDE. Recuerde que al

conectarse a un servidor desde el emulador, debe conectarse a la dirección IP del host en el que ejecute el

proceso del servidor; no 127.0.0.1. El emulador se considera a sí mismo 127.0.0.1, así que debe utilizar la




dirección del host al intentar conectarse desde Android. (Para averiguar la dirección IP del equipo en el que

se encuentre, introduzca ifconfig en Linux o Mac, o ipconfig en Windows.)

La parte correspondiente al cliente del ejemplo es donde comienza NetworkExplorer, con el método

callSocket de la actividad SimpleSocket, dicho código se presenta a continuación.

public class SimpleSocket extends Activity {

private static final String CLASSTAG = SimpleSocket.class.getSimpleName();

private EditText ipAddress;

private EditText port;

private EditText socketInput;

private TextView socketOutput;

private Button socketButton;

@Override

public void onCreate(final Bundle icicle) {

super.onCreate(icicle);

this.setContentView(R.layout.simple_socket);

this.ipAddress = (EditText) findViewById(R.id.socket_ip);

this.port = (EditText) findViewById(R.id.socket_port);

this.socketInput = (EditText) findViewById(R.id.socket_input);

this.socketOutput = (TextView) findViewById(R.id.socket_output);

this.socketButton = (Button) findViewById(R.id.socket_button);

this.socketButton.setOnClickListener(new OnClickListener() {

public void onClick(final View v) {

socketOutput.setText("");

String output = callSocket(ipAddress.getText().toString(),

port.getText().toString(), socketInput.getText().toString());

socketOutput.setText(output);

}

});

}

private String callSocket(final String ip, final String port, final String

socketData) {

Socket socket = null;

BufferedWriter writer = null;

BufferedReader reader = null;

String output = null;

try {

socket = new Socket(ip, Integer.parseInt(port));

writer = new BufferedWriter(new

OutputStreamWriter(socket.getOutputStream()));

reader = new BufferedReader(new InputStreamReader(socket.getInputStream()));

// send input terminated with \n

String input = socketData;

writer.write(input + "\n", 0, input.length() + 1);

writer.flush();




// read back output

output = reader.readLine();

Log.d(Constants.LOGTAG, " " + SimpleSocket.CLASSTAG + " output - " + output);

// send EXIT and close

writer.write("EXIT\n", 0, 5);

writer.flush();


Log.e(Constants.LOGTAG, " " + SimpleSocket.CLASSTAG + " IOException calling

socket", e);

} finally {

try {

writer.close();


// swallow

}

try {

reader.close();


// swallow

}

try {

socket.close();


// swallow

}

}

return output;

};

}

En este caso utilizamos el método onCreate para invocar un método de ayuda privado callSocket y

establecer el resultado en TextView. Dentro del método callSocket creamos un Socket para representar el

lado cliente de la conexión y establecemos el componente de escritura de la entrada y un lector para el

resultado. Una vez abordadas las tareas de mantenimiento, escribimos en el socket, que se comunica con el

servidor, y obtenemos el valor de resultado que devolver.

Un socket es probablemente el uso de red de nivel inferior en Android. Aunque ofrece una gran

abstracción, debemos encargarnos de muchos de los detalles (en concreto del lado del servidor,

subprocesos y cola). En muchos casos tendrá que utilizar un socket (si el lado del servidor ya existe), pero

las soluciones de nivel superior como HTTP ofrecen numerosas ventajas.

Solicitudes HTTP

Como vimos en el apartado anterior, puede utilizar un socket para transferir datos IP con Android. Es un

enfoque importante que hay que tener en cuenta para disponer de dicha opción y conocer los detalles

subyacentes. No obstante, puede evitar esta técnica siempre que pueda y aprovechar en su lugar

productos de servidor ya existentes para enviar sus datos. La forma más habitual de hacerlo consiste en

utilizar un servidor Web con HTTP.




A continuación veremos cómo realizar solicitudes HTTP desde un cliente Android y enviarlas a un servidor

HTTP. Permitiremos que el servidor HTTP procese todos los detalles y nos centraremos en la aplicación

Android cliente.

¿Qué es java.net?

Se refiere a la API o paquete de Java: java.net, el cual permite realizar

conexiones y transacciones a través de la red. Utilizando el paquete java.net

podemos comunicar dos o más computadoras que estén en distintas partes

del mundo.

Se usa en combinación con las clases del paquete java.io para leer y escribir

datos en la red.

Para consultar de manera detallada la documentación de java.net, se sugiere consultar la página web:

http://download-llnw.oracle.com/javase/6/docs/api/index.html

http://download-llnw.oracle.com/javase/6/docs/api/index.html




El método de solicitud HTTP más básico es GET. En este tipo de solicitud, los datos enviados se incrustan en

el URL de la cadena de consulta. La siguiente clase de la aplicación NetworkExplorer, (véase el listado 6.4),

incluye una actividad que lo demuestra.

public class SimpleGet extends Activity {

private static final String CLASSTAG = SimpleGet.class.getSimpleName();

private EditText getInput;

private TextView getOutput;

private Button getButton;

@Override

public void onCreate(Bundle icicle) {

super.onCreate(icicle);

setContentView(R.layout.simple_get);

this.getInput = (EditText) findViewById(R.id.get_input);

this.getOutput = (TextView) findViewById(R.id.get_output);

this.getButton = (Button) findViewById(R.id.get_button);

this.getButton.setOnClickListener(new OnClickListener() {

public void onClick(View v) {

getOutput.setText("");

String output = getHttpResponse(getInput.getText().toString());

if (output != null) {

getOutput.setText(output);

}

}

});




};

/**

* Perform an HTTP GET with HttpUrlConnection.

*

* @param location

* @return

*/

private String getHttpResponse(String location) {

String result = null;

URL url = null;

Log.d(Constants.LOGTAG, " " + SimpleGet.CLASSTAG + " location = " + location);

try {

url = new URL(location);

Log.d(Constants.LOGTAG, " " + SimpleGet.CLASSTAG + " url = " + url);

} catch (MalformedURLException e) {

Log.e(Constants.LOGTAG, " " + SimpleGet.CLASSTAG + " " + e.getMessage());

}

if (url != null) {

try {

HttpURLConnection urlConn = (HttpURLConnection) url.openConnection();

BufferedReader in = new BufferedReader(new

InputStreamReader(urlConn.getInputStream()));

String inputLine;

int lineCount = 0; // limit the lines for the example

while ((lineCount < 10) && ((inputLine = in.readLine()) != null)) {

lineCount++;

Log.v(Constants.LOGTAG, " " + SimpleGet.CLASSTAG + " inputLine = " +

inputLine);

result += "\n" + inputLine;

}

in.close();

urlConn.disconnect();


Log.e(Constants.LOGTAG, " " + SimpleGet.CLASSTAG + " " + e.getMessage());

}

} else {

Log.e(Constants.LOGTAG, " " + SimpleGet.CLASSTAG + " url NULL");

}

return result;

}

}

Para obtener una respuesta HTTP y mostrar las primeras líneas en nuestra clase SimpleGet, invocamos un

método getHttpResponse. En este método construimos un objeto java.net. URL, que se encarga

automáticamente de muchos de los detalles, y después abrimos una conexión a un servidor por medio de

HttpurlConnection.

Seguidamente utilizamos BufferedReader para leer datos de la conexión una línea por vez. Recuerde que

mientras lo hacemos, utilizamos el mismo subproceso de la IU y, por tanto, la bloqueamos, lo que no es

aconsejable. Únicamente lo hacemos para ilustrar el funcionamiento de la red; en un apartado posterior

veremos cómo utilizar un subproceso independiente. Una vez obtenidos los datos, los añadimos a la

cadena de resultado devuelta por el método y cerramos el lector y la conexión. Gracias a la sencilla

compatibilidad de Android con java.net, podemos acceder a los recursos de red HTTP.




Esta forma de comunicación con HTTP es muy sencilla pero se puede complicar si necesitamos algo más

que recuperar datos y, como hemos indicado, el bloqueo que genera esta técnica no es aconsejable.

Podemos solucionar algunos de estos problemas si utilizamos subprocesos independientes y realizamos su

seguimiento, y si creamos nuestra propia estructura de API para cada solicitud HTTP, pero no será

necesario. Afortunadamente, Android proporciona otro conjunto de API en la biblioteca HttpClient de

Apache que abstraen las clases de java.net y que ofrece una mayor compatibilidad con HTTP para

solucionar el problema de los subprocesos independientes.

"Android de la A a la Z" -- Unidad 9

Documents