Archivo de la categoría: Móvil

Convierte tu móvil 3G en un punto de acceso wifi con JoikuSpot

Hace unos días tuve un problema, necesitaba conectar dos portátiles a Internet simultáneamente pero sólo disponía de un teléfono 3G, así que, o conectaba uno o conectaba el otro. Buscando por Google llegué a JoikuSpot, una aplicación para Symbian que convierte tu teléfono 3G en un router inalámbrico. Sí, como lo has oído, lo mismo que hacen esos routers pero con un sencillo teléfono S60.

Además de la ventaja de compartir la red, me pareció interesante disponer de  un método de conexión portátil/teléfono alternativo y estándar al Bluetooth y al cable USB.

Obviamente este método sólamente sirve para terminales que dispongan de conexión wifi 😛 . En mi caso tengo un Nokia E51 que la tiene, así que es un dispositivo con dos interfaces de red, la wifi por un lado y la conexión dinámica 3G/HSDPA por el otro, lo mismo que un router normal y corriente.

Existen dos versiones de JoikuSpot,  Light (gratis) y Premium (en oferta por 15$). La diferencia fundamental es la cantidad de protocolos soportados. Mientras que con la primera sólamente tienes HTTP/HTTPS, con la segunda tienes prácticamente todos los necesarios para una navegación completa (smtp, pop3, vpn, messenger, skype…). Para el uso que le voy a dar yo me es suficiente con la versión Light, al menos por el momento.

Una vez descargada habrá que configurar el punto de acceso inalámbrico con los parámetros típicos de cualquier router: nombre de la red, canal, tipo de autentificación, clave…

screenshot0003.jpg

Una vez tenemos nuestro punto de acceso wifi bien configurado no tenemos más que iniciarlo, para lo cual nos pedirá qué punto de acceso de datos queremos utilizar para salir a Internet. Seleccionamos nuestra conexión 3G/HSDPA y nuestro móvil ya será un router inalámbrico.

screenshot0001.jpg

En todo momento tenemos información del tráfico y el tiempo de conexión.

screenshot0002.jpg

Ahora podemos buscar la red inalámbrica desde los portátiles. Veremos que en la lista de redes aparece una nueva con el nombre que le hemos puesto al configurar JoikuSpot. Nos conectamos indicando la clave y por arte de magia tenemos conexión a Internet en todos los equipos que se conecten a nuestro móvil.

screenshot0009.jpg

Todo muy sencillo de configurar.

Una alternativa más que útil para emergencias (Noooooo, no funciona Internet) o viajes.

Screenshot

Para los que se estén preguntando cómo hago las capturas de pantalla directamente desde el móvil, os recomiendo Screenshot, una aplicación Symbian libre para realizar capturas de pantalla y que te permite definir la combinación de teclas que dispararán la captura. Llevo utilizándolo mucho tiempo y siempre me ha dado muy buenos resultados.

Otras utilidades para un servidor de correo

A veces un servidor de correo puede sernos de muchísima utilidad si sabemos cómo manejarlo correctamente. En el artículo de hoy veremos como utilizar nuestro MTA para ejecutar automáticamente acciones cuando se recibe un determinado email o con los parámetros que definamos. Una vez conozcamos la teoría plantearemos dos casos prácticos como ejemplo.

Para comenzar necesitaremos un servidor Linux con Qmail como MTA. Supongo que cualquier otro servidor de correo servirá (Sendmail, Postfix), yo lo personalizo en Qmail porque es el que conozco y utilizo, pero estoy seguro de que con los demás se puede hacer lo mismo.

La teoría

Para entender cómo funciona la idea debemos entender primero cómo Qmail realiza la entrega de mensajes en los buzones locales. Es un tema sobre el que hay bastante literatura buscando en Google pero que puede no quedar muy claro en una lectura rápida. Es el famoso lío de los archivos .qmail.

Cada vez que se crea un usuario del sistema se debe crear, si va a recibir emails, un archivo .qmail-default en su directorio de usuario.

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-default
./Maildir/

Normalmente este archivo se crea automáticamente ya que al instalar qmail se habrá creado una copia de este archivo en el esqueleto de creación de usuarios /etc/skel:

[jiglesias@lerez ~]# ls -la /etc/skel
total 56
drwxr-xr-x  4 root root  4096 Jul 29 18:29 .
drwxr-xr-x 97 root root 12288 Dec 30 04:08 ..
-rw-r--r--  1 root root    33 Feb  1  2008 .bash_logout
-rw-r--r--  1 root root   176 Feb  1  2008 .bash_profile
-rw-r--r--  1 root root   124 Feb  1  2008 .bashrc
drwx------  5 root root  4096 Aug 29  2007 Maildir
-rw-r--r--  1 root root    12 Jan  2  2008 .qmail-default
-rw-r--r--  1 root root   658 Sep 12  2006 .zshrc

Para el que no lo sepa, el esqueleto son los archivos que se copiarán al directorio de usuario (con los permisos de éste) cada vez que se crea uno nuevo. Si quieres que todos tus usuarios tengan algún archivo automáticamente, éste es tu sitio. En nuestro caso vemos que además del .qmail-default está el directorio Maildir, el de entrega por defecto del correo en qmail. Teniendo un usuario este archivo y este directorio, podrá recibir correo.

Vale vale, vas muy deprisa. Todavía no has explicado para que sirve el .qmail-default ese.  Cierto. Los archivos .qmail indican las reglas de entrega de los mensajes en base a dos parámetros:

  • El nombre del archivo .qmail-xx hace referencia a la cuenta de correo sobre la que actúa.
  • El contenido indica qué hacer con el correo.

Supongamos un usuario (jiglesias)  que recibe el correo de dos cuentas distintas (jiglesias@… y osus@…).

Por defecto todo su correo irá a su buzón ya que es lo que indica el archivo .qmail-default. Queremos ahora que el comportamiento sea distinto dependiendo de la cuenta a la que vaya dirigido, creamos entonces los archivos .qmail para las direcciones:

  • .qmail-jiglesias : controla el correo que vaya a jiglesias@…
  • .qmail-osus : controla el correo que vaya a osus@…

Podemos incluso ir un poco más lejos con un archivo .qmail-jiglesias-default, y controlaríamos el correo que vaya a cualquier dirección del tipo jiglesias-XXXX@…, es decir, cualquier dirección que comience por jiglesias- será controlada por este archivo .qmail.

En el caso básico, que es el que veíamos, la entrega se realiza al buzón de correo del usuario (el directorio Maildir) pero podríamos hacer otras cosas en función del contenido del archivo .qmail encargado de procesar la entrega del correo:

Reenvío a otra cuenta:

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-jiglesias
[email protected]

Reenvío a un programa/script:

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-osus
|preline /usr/bin/programa

Combinación de los anteriores

[jiglesias@lerez ~]# cat /home/jiglesias/.qmail-jiglesias
./Maildir/
[email protected]
|preline /usr/bin/programa

El caso que nos interesa es el segundo, es decir, pasar la entrega del email a un script que se encargará de analizar el email y tomar decisiones.

Te habrá llamado la atención el |preline del archivo .qmail. Es el sistema que prepara un email para ser procesado y entregado a otro script añadiendo algunas cabeceras. La salida del script que reciba el email es importante ya que de ella depende el resultado de la entrega final de email, en concreto es importante saber que si queremos rechazar un email habrá que terminar el script con un exit (100), esto indicará a qmail que debe rechazar ese mensaje. Veremos más adelante la utilidad de esta salida.

La práctica

Una vez sabemos cómo pasar el control de un email recibido a un script, veamos como tratarlo. Lo haremos con un script PHP. En nuestro archivo .qmail haremos algo como:

[jiglesias@lerez ~]# more .qmail-jiglesias
|preline /usr/bin/php /home/jiglesias/prueba.php

Con esto hemos terminado el trabajo en el servidor de correo. Veamos ahora como parsear el email desde PHP.

Lo primero que debemos hacer es recoger el contenido del email desde el script a través de la entrada estándar,  después ya podemos procesar el email como una cadena de texto.

<?php
$email=file("php://stdin");
$email=implode("", $email);
?>

Con estas sencillas dos líneas de código tendremos en nuestro script el contenido del email. Ahora sólamente debemos procesarlo. Podemos hacerlo línea por línea por nuestra cuenta o apoyarnos en alguna librería. Yo utilizo Mail_mimeDecode de Pear. La ventaja de esta librería es que podemos obtener, además del texto del email, los archivos adjuntos.

<?php
$email=file("php://stdin");
$email=implode("", $email);
$params['include_bodies'] = true;
$params['decode_bodies'] = true;
$params['decode_headers'] = true;
$params['input'] = $email;
$structure = Mail_mimeDecode::decode($params);
$subject = trim($structure->headers['subject']);
$ddate = trim($structure->headers['date']);
$from = addslashes(trim($structure->headers['from']));
if(ereg("<(.*)>", $from, $p)) $from=$p[1];
if(ereg(""(.*)"", trim($structure->headers['from']), $pp))
    $nombre=$pp[1];
?>

Así podemos ya procesar el email y tomar las decisiones que consideremos oportunas. Podremos insertarlo en una base de datos, lanzar otros procesos automatizados, enviar avisos por SMS… lo que se nos ocurra.

Casos prácticos

La pregunta clave, después de ver la teoría, sería ¿para qué me sirve esto?.  Os propongo dos aplicaciones que yo he hecho.

Sistema de soporte

El típico sistema de tickets de soporte. En el asunto del email se arrastra el identificador del ticket, por ejemplo [#123445]. Tendremos que analizar el asunto y comprobar si aparece el patrón predefinido. Si no existe estamos ante un nuevo ticket e insertamos los datos en nuestra base de datos, en caso contrario es una respuesta a una incidencia anterior y ahí tendremos el identificador. Sencillo ¿no?. Podemos incluso adjuntar a nuestras indicendias archivos que puedan llegar en el email.

Envío de archivos desde el movil

El segundo ejemplo sería semejante al anterior técnicamente pero distinto conceptualmente. La mayoría de los móviles (salvo los de gama alta) no pueden enviar archivos desde los formularios wap (<input type=”file”>). La alternativa es que el usuario envie un email o un MMS (la mayoría de operadoras permiten el envío a direcciones de email) con sus archivos. Nuestro script procesará el contenido del mail recibido, decodificará los archivos y los tratará como sea oportuno.

Son dos sencillos ejemplos de cómo utilizar el email para automatizar tareas, pero, como he comentado, podríamos hacer todo lo que se nos ocurra, desde enviar un SMS de aviso hasta incluso reiniciar nuestro servidor o lanzar cualquier otra tarea.

Conversión de vídeos a 3gpp bajo demanda en un entorno web

Hoy veremos como aplicar conversiones de vídeo en un entorno web donde los usuarios suben sus vídeos en cualquier formato. Sí, tienes razón, ni más ni menos que lo que hace YouTube, de hecho utilizaban un sistema muy similar a lo que veremos ahora y basado en el mismo software. En realidad el artículo se podría aplicar a prácticamente cualquier tipo de conversiones, incluso para iPod o PSP, sólo hay que utilizar los parámetros adecuados. Nosotros nos centraremos en la conversión a 3gp para después poder hacer streaming con ellos además de permitir su descarga.

Nuestro entorno se basará en un servidor con Linux (Centos5 en mi caso). Como software sólamente necesitaremos ffmpeg, herramienta imprescindible para cualquier aplicación (tanto web como de escritorio) bajo Linux.

¿Qué es ffmpeg?

Hace unas semanas veíamos cómo utilizar ffserver para convertir flujos de vídeo y hacer streaming. ffmpeg es la utilidad en la que se apoya ffserver para realizar las conversiones.

ffmpeg es una herramienta de software libre que permite realizar conversión entre la mayoría de formatos de vídeo más utilizados. Una inmensa mayoría de programas de conversión bajo Windows no son más que frontends gráficos para ffmpeg.

Normalmente los paquetes precompilados de ffmpeg no vienen con las extensiones adecuadas para las conversiones que necesitamos, así que deberemos compilar nuestra propia versión.

Necesitas instalar los siguientes paquetes, son más de los imprescindibles, pero así nos ahorraremos problemas futuros:

libmp4v2
libvorbis
libvorbis-devel
lame
lame-devel
faac
faac-devel
faad2
x264
x264-devel
xvidcore
xvidcore-devel

Debo decir que para mi Centos no están todos disponibles como rpm con lo cual habrá que compilar manualmente algunos de ellos. No deberías tener ningún problema para localizar cada librería.

Finalmente habrá instalar los siguientes paquetes:

http://ftp.penguin.cz/pub/users/utx/amr/amrnb-7.0.0.2.tar.bz2

http://ftp.penguin.cz/pub/users/utx/amr/amrwb-7.0.0.3.tar.bz2

Con esto tenemos ya todo preparado para compilar nuestro propio ffmpeg. Descarga el paquete desde la web oficial, descomprímelo y:

./configure --enable-libmp3lame --enable-libvorbis --enable-libogg --enable-libamr-nb --enable-libamr-wb --enable-libfaac --enable-gpl --enable-libxvid --enable-libx264 --enable-libfaad --enable-shared
make
make install

Si has seguido bien todos los pasos tendrás el software de conversión preparado.

Convirtiendo a 3gp

Para realizar las conversiones algo tan sencillo como:

ffmpeg -y  -i original.avi -s qcif -r 12 -b 30 -ac 1 -ar 8000 -ab 12200 video.3gp
/usr/local/bin/MP4Box -3gp -mtu 1450 -hint video.3gp

Cuando vimos cómo hacer streaming a móviles veíamos como utilizar la utilidad MP4Box para que nuestros vídeos 3gp se puediesen utilizar para emitir en vivo.

Para nuestro proyecto es probable que necesitemos algo más. Si queremos que también se puedan visualizar los vídeos desde una web necesitaremos convertirlos a flv:

ffmpeg -y -i original.avi -acodec libmp3lame -ac 2 -ar 22050 -r 12 -b 196 -s 176x144 video.flv
/usr/bin/flvtool2 u video.flv

Flvtool es una herramienta que inserta en los flv los metadata necesarios para que funcione bien en el reproductor flash.

Y necesitaremos capturar algún fotograma del vídeo para mostrar como demo:

ffmpeg -i original.avi -y -ss 00:00:01 -vframes 1 -an -sameq -s 160x120 -f image2 thumbnail.jpg

Ahora ya sabemos:

  • cómo crear nuestro vídeo 3gp que nos sirva tanto para descarga como para streaming.
  • cómo crear el vídeo flv que nos sirva para ver vía web.
  • cómo generar thumbnails de escenas del vídeo.

Creando el entorno web

Supongamos que queremos desarrollar una web al estilo Youtube donde el usuario sube vídeos desde un formulario y posteriormente se desea mostrarlos categorizados, con un buscador, una preview (flv), descarga para móviles, etc.

La parte de la web propiamente dicha resulta obvia, no vamos a entrar en detalles. Lo que nos ocupa aquí es como realizar la conversión según las instrucciones que hemos visto. Obviamente no podemos ejecutar la conversión cada vez que un usuario sube un vídeo, sería un proceso lento y pesado. La mejor manera es crear una cola de conversión. Cuando se sube un nuevo vídeo no esta disponible públicamente (no se ha convertido todavía). Podríamos definir tres estados diferentes para un video:

  1. Sin procesar (convertir).
  2. Procesando.
  3. Procesado.

Según esto sería sencillo tener en una tabla el estado de los vídeos. Sólo los procesados se listarían públicamente.

Por otro lado tendríamos una tarea encargada de buscar vídeos en estado “sin procesar” y realizar su conversión. Esta tarea podría ser o bien un demonio residente que está permanentemente buscando vídeos o bien, si el tráfico de nuevos vídeos no va a ser elevado, podría ejecutarse periódicamente para realizar las conversiones.

Si el tráfico fuese muy elevado podría incluso haber varias tareas en paralelo ya que una vez una de ellas encuentra un vídeo “no procesado” actualiza su estado a “procesando” de manera que la siguiente tarea ya no escogerá ese mismo vídeo.

La teoría es mucho más sencilla de lo que parece. La tarea que realiza la conversión creará los formatos que estimemos oportunos según ya hemos visto antes.

Convirtiendo a otros formatos

Con ffmpeg se pueden generar los vídeos para casi cualquier formato existente incluyendo PSP, iPod/iPhone/iTouch… Googleando un poco encontrarás los parámetros adecuados para cada formato.

Conclusiones

En este artículo he explicado cómo realizar conversiones de vídeos a distintos formatos y cómo aplicarlo a un entorno web dónde los usuarios suben sus propios vídeos. He dado los pasos básicos para entender el sistema, vosotros tendríais que adaptarlo a vuestras necesidades.

Error con el smtp autentificado con los clientes de Nokia a través de Qmail

Como os decía hace unos días, recientemente he cambiado el Nokia N70 que llevaba desde hace algo más de dos años por un Nokia E51. La característica más importante de este nuevo terminal es la disponibilidad de conexión WIFI, con lo cual, si tienes un poco de suerte y encuentras un punto de acceso abierto, puedes tener acceso a tu correo desde cualquier punto. No he tenido muchos problemas para encontrar puntos de acceso y habitualmente he podido leer el correo. El problema llega a la hora de enviarlo ya que siempre obtengo un error en el envío. Cansado de no saber qué ocurría y dado que voy a estar unos días fuera de casa, decidí investigar un poco.

Comencé por ver cual era la comunicación del cliente de correo con mi servidor. Para ello lancé un sniffer en mi máquina, en este caso Wireshark, nombre actual del Ethereal de toda la vida. Para no volverme loco con todo el tráfico que iba a ver añadí un filtro, de manera que sólo se mostraría el tráfico que venía desde la IP de mi conexión ADSL (11.22.33.44), así sólo vería lo que estaba generando mi propio móvil.

tshark -i2 -f "src host 111.222.333.444"

Y este fué el resultado:

3.197223 11.22.33.44 -> 55.66.77.88 TCP 49537 > smtp [SYN] Seq=0 Win=64240 Len=0 MSS=1460 TSV=1218449730 TSER=0 WS=0
3.197263 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=389435772 TSER=1218449730 WS=7
3.347274 11.22.33.44 -> 55.66.77.88 TCP 49537 > smtp [ACK] Seq=1 Ack=1 Win=64240 Len=0 TSV=1218663480 TSER=389435772
3.356257 55.66.77.88 -> 11.22.33.44 SMTP Response: 220 servidor ESMTP
3.509426 11.22.33.44 -> 55.66.77.88 SMTP Command: EHLO
3.509451 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [ACK] Seq=29 Ack=22 Win=5888 Len=0 TSV=389436084 TSER=1218828105
3.509490 55.66.77.88 -> 11.22.33.44 SMTP Response: 250-servidor
3.663467 11.22.33.44 -> 55.66.77.88 SMTP Command: AUTH CRAM-MD5
3.813384 11.22.33.44 -> 55.66.77.88 SMTP Command: amlxxxxxxWFzIDkxNTM4MxxxxxxyYjVjOTdmYxxxxxxxDFhZDg2MjEw
3.853554 55.66.77.88 -> 11.22.33.44 TCP smtp > 49537 [ACK] Seq=197 Ack=95 Win=5888 Len=0 TSV=389436428 TSER=1219132230
8.817212 55.66.77.88 -> 11.22.33.44 SMTP Response: 535 authorization failed (#5.7.0)

Es decir, me estaba fallando la autentificación a través de CRAM-MD5 a pesar de que en el programa de correo del móvil tenía correctamente introducidos el usuario y la clave y el servidor, obviamente, se presentaba diciendo que soportaba este método.

[osus@servidor ~]# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
220 servidor ESMTP
ehlo
250-servidor
250-AUTH LOGIN CRAM-MD5 PLAIN
250-PIPELINING
250 8BITMIME

Investigando un poco averigué que para habilitar la autentificación CRAM-MD5 en Qmail, el MTA de correo que utilizo, además de instalar el parche qmail-smtp-auth es necesario sustituir el original checkpasswd  por cmd5checkpw. Con este argumento caí en la cuenta de que nunca jamás he tenido esta autentificación funcionando en mis servidores 😀 , el servidor indicaba que sí pero la realidad era que no 😛 . Ocho años utilizando Qmail y ahora me doy cuenta de que no funcionaba.

No quería complicarme mucho así que, si hasta ahora no la tenía, tampoco me importaba seguir así. Pensé entonces que, si en vez de responder a los clientes que soportaba CRAM-MD5, no se lo decía, el cliente del E51 escogería el AUTH LOGIN de toda la vida y funcionaría. ¿Cómo hacer esto? Sencillo, Qmail es de código abierto y tenemos el código fuente a nuestra disposición.

Parcheando Qmail

En los fuentes de mi Qmail (con todos sus parches) busqué la cadena en cuestión:

grep  CRAM-MD5 *

Y ahí me apareció el objetivo de nuestro parche, qmail-smtpd.c.

Dicho y hecho, abrimos el archivo con vi y buscamos la cadena en cuestión (:/CRAM-MD5) llegando a:

out("rn250-AUTH LOGIN CRAM-MD5 PLAIN");

Esto va a ser sencillo. Modificamos esa/s línea/s de manera que quede/n:

out("rn250-AUTH LOGIN PLAIN");

De este modo, cuando el cliente pregunte le diremos que soportamos LOGIN y PLAIN, pero no CRAM-MD5. He explicado esto en plural porque es más que probable que tengas dos líneas iguales y no sólo una. Puedes dejar sólo una modificada como he indicado o modificar las dos.

Compilamos ahora con un simple make. Como sólo hemos  modificado este archivo únicamente se compilará este. Hacemos una copia de seguridad de nuestro /var/qmail/bin/qmail-smtpd (por si algo no va bien) y copiamos el nuevo a esta ruta dejando los permisos, owner y group igual que tenía el que había.

Si ahora pruebas a enviar un email desde el Nokia E51 comprobarás que funciona correctamente, el cliente del teléfono escoge otro de los sistemas. Utilizando de nuevo el sniffer verás que ahora escoge AUTH LOGIN como método de autentificación.

Ya puedo enviar correo desde mis servidores con el teléfono. Gracias a un sencillo ejercicio de escucha del tráfico de red hemos averiguado cual era el problema.

Desbloquea tu teléfono móvil sin desbloquear el teléfono

Suena raro, lo se, pero veréis que todo tiene sentido.

Esto es un post algo fuera de lo que suelo escribir, pero creo que a muchos de los lectores les interesará tener acceso a Internet vía móvil y el invento es, cuanto menos, curioso.

Necesitaba un teléfono libre para utilizar la tarjeta SIM de Simyo para conectarme a Internet y lo único que tenía era mi viejo T630, sin 3G. Sin embargo la suerte quiso que acabe de cambiarme mi viejo Nokia N70 por un flamante Nokia E51 con wifi, con lo que tenía el compañero perfecto en el N70. Sólo quedaba un paso, desbloquearlo, pero me pedían 50 euros. Buscando por Internet y sin saber bien cómo, llegué a esto en una tienda en Hong Kong donde aseguraban vender una especie de adaptadores que puestos entre la SIM y el teléfono de la mayoría de compañías y terminales los desbloqueaban. Buscando alguna referencia sobre el cacharro en cuestión todo era alabanzas y buenas referencias.

Era la primera vez que oía hablar de ello, pero por el precio que proponían, 7,76 dólares (poco más de cinco euros) gastos de envío incluídos, tampoco tenía mucho que perder. Así que dicho y hecho, me compré una. Sorprendentemente cuatro días después tenía una carta en mi buzón con el adaptador en cuestión.

El aparato no es más que una lámina de plástico del tamaño de una SIM que hace de base del circuito y unas cuantas pistas para conectar ambas caras del adaptados ya que por un lado pondrás la SIM original y por el otro el teléfono. En una esquina lleva un pequeño microchip que será lo que, como veremos después, nos de algún problema para introducirla.

Esto sería mi equipo de pruebas. El Nokia N70, la SIM de Simyo y el adaptador de cinco euros. Obviamente no me creía yo mucho que esto funcionase, pero habia que probar.

img_4016.JPG

Para los incrédulos, esto es lo que dice el teléfono al poner la tarjeta directamente, está bloqueado por Vodafone.

img_4035.JPG

Cuando tienes en tu mano el adaptador y la sim ves que vas a tener problemas. Aunque yo pude colocarla más o menos bien en mi N70 reconozco que es a costa de forzar un poco el cierre. En un terminal donde la tarjeta entra en su compartimendo deslizándola no va a ser posible ponerla, así que lo mejor es operarla. Lo que tendremos que hacer, tal como véis en las siguientes fotos, es hacer un pequeño recorte en el extremo de la sim del tamaño del microchip del adaptador, de manera que al colocar una sobre otra el chip sobresale por este hueco y ámbas tarjetas quedan perfectamente unidas.

img_4021.JPG

img_4020.JPG

Procedemos ahora a colocar el adaptador y la sim en su compartimento. Primero dejamos caer el adaptador. En la foto véis como en la parte superior sobresale el microchip del que hablábamos. Si pusiésemos la sim tal cual sobre él, el compartimento no cerraría bien y habría que forzarlo un poco.

img_4023.JPG

Sin embargo, al hacerle el recorte que hemos visto, todo encaja a la perfección.

img_4024.JPG

Aquí vemos en detalle el cómo queda todo montado. Véis que encaja perfectamente.

detalle.jpg

Nos queda la prueba de fuego. ¿Funcionará?. Mejor lo véis en la foto directamente 😐 .

 img_4036.JPG

En efecto, funciona a la perfección, el teléfono no se queja de nada. Sólo tendremos que poner el adaptador debajo de cualquier SIM y funcionará en la mayoría de teléfonos. ¿Será esto cierto?. Lo probamos. Nokias, Sony Ericsson, HTC y hasta Blackberry. Todo lo que probamos funcionó. Estamos ahora pendientes de probarlas en un iPhone. Ya veremos, pero en general parece que el invento funciona.

Si tu teléfono es de esos donde la SIM entra deslizándola en su compartimento, recomiendo pegar el adaptador a la sim con pegamento, te quitarás problemas para meterla y sacarla.

Me parece simplemente genial el poder utilizar cualquiera de tus sim’s en cualquier teléfono (familia, amigos…). Ya no dependes del terminal sino simplemente de la tarjeta, la que te da el servicio y, a fin de cuentas, la que te cobra. Sencillo, barato y sin perder la garantía de tu teléfono 🙂 .

Las operadoras móviles y el control de Internet

Hace algo más de un año saltaba la noticia: Vodafone UK había implantado un proxy-transcoder en su red de datos de manera que todas las conexiones de sus clientes pasaban por este sistema. Con la excusa de hacer accesibles a todos los terminales cualquier página web ya existente, modificaban completamente el aspecto de la misma, añadiendo publicidad, accesos directos a Vodafone Live! y lo que es peor, modificando las hojas de estilos de los portales, con lo que tu trabajo perdía su apariencia original.

El movimiento internacional dentro del sector fué considerable. Gente como Andrea Trasatti o Luca Passani, verdaderos gurús de la adaptación, se revelaron contra la medida. Mucha gente lo criticó.

El problema no era sólo la apariencia de los portales, eso es lo que se veía directamente, el problema serio era (es) que se estaban cargando uno de los conceptos básicos de la adaptación para móviles: el UserAgent. Aunque existe en todos los navegadores web, el UserAgent cobra especial importancia en un dispositivo móvil ya que lo identifica, te aporta información sobre marca y modelo del mismo con lo que, con una buena base de datos de terminales (por ejemplo wurlf), puedes obtener compatibilidades (vídeo, mp3, mms…) y tamaños de pantalla. Al eliminarse el UserAgent se eliminaba la posibilidad de ofrecer contenido compatible con ese terminal. Pensemos en los juegos Java para móvil donde es imprescindible saber qué modelo tiene el cliente puesto que hay que darle un archivo compilado para ese mismo.

Después de algunas protestas, desde Vodafone UK decidieron enviar el UserAgent del teléfono original pero en una cabecera HTTP distinta, con lo cual tendrías que modificar TODOS tus desarrollos por culpa de esta maravillosa idea.

Finalmente se sacaron de la manga dos soluciones al transcoder:

  • Si tu dominio es .mobi no modifican el contenido ya que asumen que YA es contenido optimizado para pequeños dispositivos.
  • Una whitelist donde, si enviabas tus dominios, dejaban de filtrarlos y adaptarlos.

En realidad no sé si el segundo método llegó a funcionar alguna vez. El primero sí.

En octubre del año pasado llegaba la debacle a España. Vodafone ES ponía el famoso transcoder y todos nuestros portales móviles perdían su look&feel además de verse modificados para incluir todos los enlaces directos de Live!. También tuvimos voces de alarma.

Aquí el problema fue peor, nunca llegaron a enviar el UserAgent original. No sé si ahora lo hacen, pero en su momento no lo hicieron. Esta medida de Vodafone hizo mucho daño al sector.

Hoy, casi un año después, he descubierto, por pura casualidad, que Movistar también tiene el famoso proxy-transcoder, aunque por el momento parece que no hacen un uso abusivo de él. No modifican nada visualmente ni esconden el UserAgent, pero adaptan algunas cosas. Os explico la situación que me tuvo loco durante dos días.

Preparando un portal para una importante promoción me encontré con que en un Nokia N95 las imágenes no se veían al tamaño adecuado. Nuestra plataforma adapta automáticamente el tamaño de las imágenes en función del ancho de pantalla del terminal del cliente (obtenido a partir del UserAgent).  Pues resulta que en el servidor estábamos generando las imágenes correctamente, a 240px de ancho, mientras que en el teléfono se estaban recibiendo a 95px de ancho. ¡Imposible!

Probamos con el mismo teléfono pero con tarjetas SIM de otras operadoras y voila, funcionaba a la perfección. Finalmente pruebo con otros terminales y descubro que, en efecto, están adaptando las imágenes, imagino que para reducir el tráfico de red y optimizar el ancho de banda. El problema del N95 es que, por alguna extraña razón, lo tienen mal configurado en su base de datos de terminales  y, en vez de ponerle el tamaño real de pantalla que tiene (240×320), le han puesto 95px de ancho, incluso a lo mejor es el tamaño por defecto que devuelve el transcoder si no existe ese terminal en la base de datos, razón todavía peor, el N95 es uno de los dispositivos más populares a pesar de su coste.

¿Qué hago ahora cuando  el cliente nos diga que el portal se ve mal en su N95? ¿Se creerá que la culpa es de Movistar?

¿Por qué ahora, Google?

No, no voy a hablar de Chrome. Bastante se ha hablado ya sin que casi nadie se haya preguntado porqué Google saca un navegador web justo cuando menos necesario es. Siempre he pensado que algo no triunfará hasta que gente como mis hermanas o mis amigos puedan ser potenciales usuarios. Si aún no lo son de Firefox (a pesar de tenerlo instalado), ¿lo van a ser de Chrome?. Seamos realistas, Chrome es para techies y frikies. A Firefox le ha costado años y años y más años llegar a donde está hoy.

En fin, que ese no es el tema. La pregunta es, ¿por qué ahora?. ¿Por qué todo el mundo habla de Chrome y parecen olvidarse de Android?. Hace casi un año ya que Google anunción a bombo y platillo la plataforma Android y todavía no se ha visto ningún dispositivo sobre ella. Apple anuncia su iPhone seis meses antes de lanzarlo al mercado y todo son críticas y cortinas de humo, pero lo hace Google y es como si el Todopoderoso bajase de los Cielos para hacernos ver la luz. Y no seré yo el que salga en defensa de Apple.

Google ha tenido muchos problemas en el desarrollo de Android. A pesar de contar con el apoyo de las principales empresas del sector, tecnológicamente se ha encontrado limitaciones que han tenido que ir sorteando, y una de las principales en un mundo 2.0 ha sido, sin duda, el navegador web sobre el que basar su plataforma. Los que trabajamos con dispositivos móviles conocemos bien los navegadores que traen los terminales y sus limitaciones, tanto de procesamiento como de compatibilidad. Obviamente, si Google dejase el navegador web de su flamante Android en manos de un simple navegador wap, su teoría de movilizar el mundo de Internet sería no menos que utópica. Y eso por no hablar de la utilidad de toda la nueva generación de aplicaciones online (basadas en su mayoría en Ajax).

En este escenario Google tiene claro que, para triunfar en Internet móvil, independientemente de la plataforma sobre la que esté construido el terminal, debe tener un buen navegador web, que funcione en dispositivos móviles, que sea rápido y, a ser posible, estandar. Por esta época (hace un año) los terminales de gama alta de Nokia (N7x, N95…) ya salen de fábrica con un nuevo navegador web basado en Webkit (sí, el de Apple, el del iPhone), abandonando los antiguos navegadores wap y abriendo un nuevo mundo de oportunidades y aplicaciones. Las alternativas para el gigante de las búsquedas son dos: Gecko (de la Fundación Mozilla y motor de Firefox) y Webkit. La respuesta es clara, Webkit se concibió desde un principio como un motor HTML ligero y rápido.

Basándose en estas circustancias el equipo de desarrollo de Google se pone a trabajar en el que será el futuro navegador web de Android. Y llegados a este punto digo yo,

si ya tengo el motor optimizado a mi gusto, he desarrollado una máquina javascript impresionante y todo funciona bien… ¿por qué no compilarlo y lanzar un navegador web de escritorio?

No creo que sea descabellado, pero el paso importante NO es el escritorio, donde sabe que apenas conseguirá cuota de mercado (es la realidad), su objetivo es el móvil y, visto lo visto, si consiguen el mismo rendimiento que en el escritorio, van por el buen camino.

Por cierto, a mi también se me colgó Chrome 😉 .

Movilizando Joomla

Hace unos días me llegó desde la lista de correo de dev.mobi un interesante artículo sobre la creación de sitios para móviles con Joomla.

No es que me encante Joomla, de hecho probablemente haga un artículo crítico al respecto, pero creo que es muy interesante para determinados websites por su aparente sencillez. El problema que tenía es que quería una solución que me permitiese, a partir de un portal web, tener acceso desde el móvil a una versión adaptada. Gracias a este artículo encontré este plugin que prácticamente te lo da todo hecho.

Hay algo, sin embargo, que no tiene en cuenta el plugin: las imágenes. Las imágenes que insertas en tus artículos serán, normalmente, de un tamaño bastante elevado, sobre todo si hablamos de terminales móviles donde la media es de 174px de ancho de pantalla. La solución pasa por toquetear un poco el plugin haciendo que las imágenes de los articulos pasen a través de un redimensionador automático que crearemos nosotros. Os recomiendo los artículos que escribí acerca del escalado de gifs transparentes y animados (aquí y aquí) para tener una idea de como hacerlo. La solución llega en dos pasos

1) Parcheando el plugin

Este es el cambio que debemos hacer en el archivo pdabot.php del plugin. Busca al final de todo la función onAfterRenderer y haz que quede asi:

function onAfterRender()
{
	global $mainframe;
	//DESDE AQUI
	if($GLOBALS['ispda']==true){
		$body = JResponse::getBody();
		$body = preg_replace( '/<img src="(.*)"(.*)>/i', '<img src="/redimensionar.phtml?imagen=\1">', $body );
		$body = preg_replace( '/<img(.*)width="(.*)"(.*)>/i', '<img\1\3>', $body );
		$body = preg_replace( '/<img(.*)height="(.*)"(.*)>/i', '<img\1\3>', $body );
		JResponse::setBody($body);
	}
	//HASTA AQUI

Como ves, sustituimos el atributo src de todas las imágenes por nuestro script de autoescalado redimensionar.php al que le pasamos la url original de la imagen. Además aprovechamos para quitar los atributos de width y height porque en este punto no sabemos cuales serán los resultantes, si los dejásemos se vería a su tamaño original. Hemos terminado con el plugin.

2) Escalando las imágenes

Si has entendido todo el proceso hasta aquí estarás pensando, vale, pero nos falta un dato: ¿a qué tamaño escalamos las imágenes?. En efecto, no lo sabemos… todavía.

Y aquí viene W urfl en nuestra ayuda. Wurfl es una base de datos de características de terminales móviles que te permiten conocer datos como el ancho de pantalla simplemente pasándole el UserAgent del mismo. No voy a explicar el funcionamiento de Wurfl puesto que se sale del alcance de este artículo, pero en su web tienes todo lo necesario.

Crearemos entonces nuestro redimensionar.php donde simplemente buscamos mediante Wurfl el ancho de pantalla del terminal cliente y reescalamos la imagen al tamaño adecuado. Es recomendable no hacerlo al 100% para evitar que los scrolls verticales reduzcan el espacio útil y nos aparezca también el scroll horizontal (suele pasar en los Nokia). Yo suelo descontar 10px al ancho. Para imágenes de artículos puedes aplicar un escalado porcentual, pueden no quedar bien imágenes muy grandes, déjalas al 70% por ejemplo.

Conclusiones

Rápidamente y de un modo sencillo hemos adaptado para terminales móviles tu portal en Joomla, no se puede pedir más. No olvides diseñar la plantilla pda a tu gusto y necesidades.

En webs móviles es habitual utilizar una imagen como cabecera del portal. Puedes utilizar también tu redimensionador para adaptarla automáticamente al ancho de pantalla de los clientes.

Se podrían hacer muchas más cosas si integramos Wurfl directamente en el plugin, incluso podríamos hacer que el código generado estuviese adaptado a las capacidades del terminal del cliente (xHTML, iMode, WML) creando plantillas para cada lenguaje distinto. ¿Te atreves a hacerlo tu?

Enlaces interesantes de los últimos días

Nueva API de Wurfl

Tenía pendiente desde hace unos días comentar los cambios producidos en la API de Wurfl.

La teoría

Para los que no sepan de qué estamos hablando, Wurlf es una base de datos de características de dispositivos móviles. A la hora de desarrollar sites para terminales ligeros, uno de los problemas principales es la diversidad de características distintas: tamaños de pantalla, formatos multimedia soportados, lenguajes de programación… Para solucionarlo, los proveedores necesitamos mantener bases de datos de modelos con sus características principales. Una de las opciones es mantener esa base de datos manualmente, de hecho se debe hacer para responder rápidamente a nuevos terminales. Para ello registramos los UserAgents de nuevos modelos que acceden a nuestras aplicaciones para, posteriormente, buscar sus características y añadirlos a nuestra base de datos.

Wurfl es un intento de solucionar este problema desde el software libre y colaborativo. Wurfl es, fundamentalmente, un archivo XML con la información relativa a más de 10.000 terminales distintos. Para consultar este XML la gente del proyecto ha desarrollado API’s en la mayoría de lenguajes utilizados (Java, PHP, Python, Perl…). Lo más curioso es la forma de acceder a los datos. A partir del XML se crean varios miles de archivos de manera que a la hora de buscar las características de un modelo sólo hay que buscar en un archivo. A mi personalmente no me gusta mucho el modelo. Un proyecto paralelo muy interesante es Tera-Wurfl, basándose en el XML de Wurfl crea una base de datos MySQL y modifica la API PHP para consultar los datos en ella en vez de en los miles de archivos. Nosotros hicimos en su día modificaciones sobre este proyecto para utilizarlo con Sql Server.

Wurfl lo mantiene la gente, gente como nosotros, añadiendo nuevos UserAgents. Obviamente esto no es perfecto, lleva a incongruencias y datos erróneos. Recientemente han publicado también una aplicación web para enviar nuevos UserAgents y nuevos modelos. Hemos llegado a la conclusión de que no hay un modelo único válido, sino que debe ser una combinación de Wurfl y de tu base de datos propia.

¿Existen alternavitas a Wurfl? Sí, por supuesto, alguna hay, aunque en general son de pago para uso en producción.

De DetectRight, cuando lo probamos, no me gustaba el modelo, las consultas se hacen online, añadiendo un retardo y tráfico no necesario. Device Atlas me ha parecido más interesante. Lo probamos el día que lo publicaron y no nos convenció, tenia muchas carencias de características, pero estos días lo hemos vuelto a probar y ha mejorado considerablemente, aunque al no ser gratuito, aunque sea poco, no me convence, habrá que seguirle la pista de todos modos..

¿Qúe es lo que ha cambiado entonces en la API?

El proceso por el cual Wurfl averigua a qué modelo pertenece un UserAgent es muy curioso. No se basa en UserAgents o modelos concretos, sino en grupos de UserAgents, de manera que sin llegar a tener un UserAgent ni su modelo registrado puede devolvernos las posibles caracteríscias comparándolo con un modelo semejante. Por ejemplo, es posible que las característias de un Nokia N73 que no tengamos registrado sean iguales o superiores a las de un Nokia N70, luego asumimos las características de este último. Esto es extremadamente útil a la hora de tratar con modelos nuevos ya que oficialmente Wurfl libera actualizaciones un par de veces al año, aunque puedes descargar las versiones diarias del cvs.

Originariamente, el procedimiento para obtener las características de un UserAgent se basaba en que, si no se encontraba un UserAgent idéntico al del cliente, se iba reduciendo la cadena del mismo un caracter hasta encontrar un UserAgent que conincidiese con esa cadena reducida. Obviamente muy eficiente no es el método, pero funcionaba hasta ahora. La introducción de navegadores avanzados en dispositivos de gama alta, derivados de Safari, Opera, etc. llevó a la aparición de UserAgents móviles derivados de Mozilla, como los navegadores web tradicionales. Nokia95 (y la mayoría de nuevos modelos de Nokia), iPhone, Blackberry… casi todos tienen cadenas del tipo:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; de-de) AppleWebKit/420.1
(KHTML, like Gecko) Version/3.0 Mobile/3B48b Safari/419.3

Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/11.0.026;
Profile MIDP-2.0 Configuration/CLDC-1.1) AppleWebKit/413
(KHTML, like Gecko) Safari/413

El método de reducción es poco eficiente con UserAgents de este tipo. Esto es, pues, lo que han cambiado. El nuevo sistema establece un análisis en dos pasos:

  1. Primero se averigua qué tipo de UserAgent estamos tratando (basado en Mozilla, Microsoft, etc.).
  2. Según el tipo del primer paso, se procesa el UserAgent con el manejador adecuado para encontrar la información requerida.

Por ejemplo, en el primer paso, si la cadena contiene la palara Blackberry sabemos que es un navegador de este tipo de dispositivos. Un algoritmo concreto para éstos nos devolverá el modelo.

Era una modificación imprescindible hoy en día. No por el iPhone como puedan pensar muchos, sino porque la mayoría de nuevos terminales de Nokia ya tienen derivados de Safari, navegadores que por cierto nos han dado algunos problemas desarrollando sites 100% correctos y estandard pero que no se visualizaban bien (a pesar de que en los navegadores de escritorio Safari sí que funcionaba bien).

Luca Passani, alma mater de Wurfl junto a Andrea Trasatti, lo explica mejor que yo aquí.