by Jorge Ulises Gonzalez Medina

1. Android de la A a la Z
Unidad 9 “Redes”
1
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

2. Android de la A a la Z
Unidad 9 “Redes”
2
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.

3. Android de la A a la Z
Unidad 9 “Redes”
3
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.

4. Android de la A a la Z
Unidad 9 “Redes”
4
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 -

5. Android de la A a la Z
Unidad 9 “Redes”
5
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.

6. Android de la A a la Z
Unidad 9 “Redes”
6
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:

7. Android de la A a la Z
Unidad 9 “Redes”
7
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.

8. Android de la A a la Z
Unidad 9 “Redes”
8
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("EXITn")) {
System.out.println("EXIT invoked, closing client");
break;
}

9. Android de la A a la Z
Unidad 9 “Redes”
9
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);

10. Android de la A a la Z
Unidad 9 “Redes”
10
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("EXITn", 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) {

11. Android de la A a la Z
Unidad 9 “Redes”
11
// 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

12. Android de la A a la Z
Unidad 9 “Redes”
12

13. Android de la A a la Z
Unidad 9 “Redes”
13
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;
}

14. Android de la A a la Z
Unidad 9 “Redes”
14
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.