android de la a a la z - unidad 9

Android de la A a la Z

Unidad 9 “Redes”

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

1

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.

2



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.

3



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 -

4



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.

5



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:

6



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.

7



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

8



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

9



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

} catch (IOException e) { Log.e(Constants.LOGTAG, " " + SimpleSocket.CLASSTAG + " IOException calling socket", e); } finally { try { writer.close(); } catch (IOException e) { // swallow } try { reader.close(); } catch (IOException e) { // swallow } try { socket.close(); } catch (IOException e) {

10



// 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

11

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



12



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

13



in.close(); urlConn.disconnect();

} catch (IOException e) { 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.

14

android de la a a la z - unidad 9

Technology