iButterfly: Publicidad con imaginación

(Gracias Alberto 😉 )

Cuando una mariposa virtual mueve sus alas en Kyoto, un señor con gafas llamado Steve Jobs llena sus bolsillos en California. Ese es uno de los efectos que causa iButterfly, una creación de Mobile Art Lab que mezcla mariposas en realidad aumentada, el acelerómetro del iPhone, su GPS y que permite obtener descuentos en comercios.

La agencia japonesa Dentsu ha lanzado una original aplicación para iPhone que reúne aspectos lúdicos y promocionales y que utiliza la realidad aumentada. Bajo el nombre de iButterfly, la “app” ya está disponible en Appstore y la agencia busca ahora anunciantes para que la utilicen como herramienta promocional, una manera de actuar opuesta a la habitual.

La mecánica se inicia con un juego: el usuario debe cazar las mariposas virtuales que vuelan con su iPhone (gracias a la realidad aumentada). Se pueden coleccionar e incluso intercambiar con otros usuarios a través de Bluetooth.

Mobile Arts, la desarrolladora de la aplicación, ha esparcido cientos de miles de mariposas virtuales por todo Japón. Y ahí seguirán mientras los propietarios de iPhone no las ‘cacen’ con sus dispositivos. La combinación del sensor de movimiento, el GPS y la pantalla del dispositivo permitirá observar a esas mariposas virtuales de manera real, a través del display del teléfono, y cazarlas usando el movimiento característico que se realiza con un cazamariposas.

Las mariposas pueden contener información y cupones descuentos de las tiendas próximas adonde han sido cazadas.

Este es un ejemplo más de cómo las nuevas tecnologías, sobre todo los smartphones, pueden convertirse en un gran aliado de los comercios, que se pueden valer de ellas para llevar tráfico a sus tiendas.

Ver el vídeo de la aplicación aquí.

Retrasos del JDK 7 por Oracle

Re-planificado para 2012, aunque ya sabemos qué pasa con las re-planificaciones…  🙂

Con la explicación de Mark Reinhold (Chief Architect de la Java Platform Group en Oracle)

http://blogs.sun.com/mr/entry/rethinking_jdk7

Publicado en Java. Leave a Comment »

Discriminador de dispositivos

Quizá a alguno de vosotros os haya surgido este problema últimamente, a Manuel y a mí nos surgió la semana pasada y en este post he querido recopilar algo de lo que encontramos. Para el que le interese más el tema está ampliamente documentado.

 La mayor parte de las páginas de internet, no son accesibles a través de dispositivos móviles o no son practicables a través de ellos. Esto quiere decir que a pesar de que una página web puede ser visualizada desde un dispositivo móvil, no significa que esa página sea navegable cómodamente desde dicho dispositivo. Por tanto, para que nuestras aplicaciones sean accesible desde diferentes dispositivos móviles, normalmente, tendremos que realizar varios diseños de presentación diferentes.

DIFERENCIAS DE INTERACTUACIÓN ENTRE LOS DISTINTOS DISPOSITIVOS MÓVILES 

Las principales diferencias que encontraremos al interactuar con los distintos dispositivos móviles y que tendremos en cuenta a la hora de desarrollar nuestra aplicación serían las siguientes 

  • El uso de links. Es diferente como un usuario maneja el puntero de una PDA, a como el usuario de un teléfono maneja el puntero a través del teclado. En muchos casos el dispositivo no incorpora un puntero como tal, sino que se mueve a través de la página web mediante el teclado, esto provoca la desaparición de algunos métodos javascript como “onmouseover”.  

Diferencias físicas:

  • El tamaño de la pantalla.
  • En algunos casos ausencia de Teclado.  

Limitaciones en los navegadores (browser):

  • Existen grandes diferencias en la ejecución de código cliente (HTML, javascript y CSS) en distintos navegadores. En el caso de los navegadores de los dispositivos móviles se acentúa aun más, ya que dentro de los dispositivos móviles, existen navegadores que soportan WML, otros CHTML (Compact HTML) y otros XHTML. Además, dentro de cada una de estas especificaciones existen versiones. Tendremos un problema similar para el soporte Javascript y CSS.
  • Cuando realizamos un diseño para un determinado navegador y lo probamos en otro, hay muchas posibilidades de que los elementos de nuestro página web se visualicen de diferente forma o incluso que ni se visualicen. Este hecho en el caso de los navegadores de los dispositivos móviles, es llevado al extremo. Muchos navegadores de este tipo de aparatos no cumple el estándar o si se supone que lo hace, no tiene nada que ver la representación del código cliente en un dispositivo o en otro. 

Limitaciones en la ejecución de contenidos multimedia:

  • Las restricciones relativas a la ejecución de contenidos multimedia vienen dadas por las limitaciones físicas de los aparatos, principalmente por las dimensiones de la pantalla y la escasez de recursos de estos dispositivos (CPU y memoria). Un ejemplo de estas limitaciones sería el límite de tamaño y formato de las imágenes,… 

Según lo mencionado hasta ahora, podremos afirmar y justificar la existencia de diferentes vistas (maquetaciones) para un mismo modelo. Por tanto tendremos que identificar el dispositivo que está realizando la petición a nuestra aplicación y dependiendo de las características del dispositivo y del navegador, ofrecerle una interfaz gráfica adaptada a sus capacidades. 

IDENTIFICADOR DEL NAVEGADOR CLIENTE 

Tradicionalmente, cuando el navegador cliente es el de un PC, lo identificábamos mediante un código JS. En este caso es más complicado, ya que algunos dispositivos móviles no aceptan javascript, o no disponen del objeto “navigator”. También descartaremos este método, ya que javascript es código que se ejecuta en el cliente, y nosotros queremos cargar una página JSP u otra dependiendo del tipo del cliente conectado. 

Desde el lado servidor, podremos obtener una identificación del cliente a través de los “headers” de la petición, concretamente recogiendo el valor del parámetro “user-agent”. El user-agent, es una aplicación informática que funciona como cliente en un protocolo de red; el nombre se aplica generalmente para referirse a aquellas aplicaciones que acceden a la World Wide Web. Los agentes de usuario que se conectan a la Web pueden ser un teléfono móvil, pero también un navegador web,… 

Cuando un usuario accede a una página web, la aplicación generalmente envía una cadena de texto que identifica al agente de usuario ante el servidor. Este texto forma parte del pedido a través de HTTP, llevando como prefijo User-agent: o User-Agent: y generalmente incluye información como el nombre de la aplicación, la versión, el sistema operativo, y el idioma. 

Normalmente la cadena “User-Agent”, se corresponde con una serie de patrones, por lo tanto podremos trocear la cadena y averiguar ciertas características del navegador cliente. 

IDENTIFICADOR DEL NAVEGADOR DESDE EL LADO SERVIDOR 

Existen distintas maneras de abordar esta tarea. Primero vamos a comentar algunas alternativas y por último la que, a nuestro entender, es la mejor forma de hacerlo, mediante WURFL y su API para java. 

Desde nuestro servlet podremos capturar la cadena “User-Agent” (contenida en la request) y tratarla para averiguar que navegador se está conectando a nuestra aplicación. 

El inconveniente que tiene esta manera de identificar el navegador del cliente sería que a través del user-agent no podemos averiguar las limitaciones del dispositivo tales como tamaño de la pantalla, capacidad para entender HTML,…

UAProf (User Agent Profile) 

Se basa en la obtención de información a través de una uri introducida en una cabecera HTTP. Esta dirección se resuelve devolviendo un documento XML que contiene información de las características del dispositivo.

Las ventajas son que la integración y mantenimiento son teóricamente sencillos, ya que se accede a un documento XML que se parsea de forma manual. Además esta información es actualizada por el fabricante, lo que asegura una gran fiabilidad en la información obtenida.

También tendría ciertas desventajas, definidas a continuación: 

  • No todos los dispositivos usan UAProfs.
  • No todas las publicaciones UAProfs están disponibles (alrededor del 20% de los enlaces ofrecidos por teléfonos están muertos u obsoletos, según las cifras de UAProfile.com)
  • UAProf puede contener un esquema o errores de datos que puede causar problemas al “parsear” el documento.
  • Recibir y parsear los UAProfs en tiempo de ejecución, puede consumir muchos recursos, ralentizando la aplicación.
  • No existe un organismo que controle y estandarice los campos del UAProf.
  • El documento UAProf no contiene los agentes de usuario de los dispositivos que podrían aplicarse en el esquema (Nokia los pone entre los comentarios).Los encabezados de UAProf pueden ser erróneos.  

WURFL (Wireless Universal Resource File) 

Este repositorio de características nace para solventar los inconvenientes detectados en UAProf e intenta unificar en una estructura única las características de los dispositivos inalámbricos. Estas son recopiladas a partir de las características publicadas por los fabricantes en el UAProf y las diferentes contribuciones (desarrolladores y empresas). 

WURFL es un fichero XML que contiene las capacidades y características de la mayoría de los dispositivos. El principal objetivo de este fichero es recolectar toda la información posible de los dispositivos móviles. Se trata de un proyecto open-source y existen multitud de APIs en diferentes lenguajes de programación para trabajar con el XML. En nuestro caso nos centramos en el API para java.

Podemos recuperar, de esta manera, casi cualquier característica que queramos conocer del dispositivo:

http://wurfl.sourceforge.net/help_doc.php

Apache Mobile Filter (AMF) 

AMF es un producto que se adapta a las necesidades de sistemas en los que hay que servir contenidos a diferentes clientes, gestionando los mismos, aportando herramientas para su adaptación y de reconocimiento de dispositivos móviles mediante el repositorio WURFL.

El acceso a WURFL vía AMF puede realizarse desde múltiples lenguajes de programación, incluyendo Java .

Consta de diferentes módulos que pueden ser de utilidad para aplicaciones móviles:

  • AMFWurflFilter: Detección de las características del móvil (WURFL) ofreciendo la posibilidad de ser registradas en variables de entorno para ser utilizadas por otras aplicaciones.
  • AMFMobileCaching: Acceso a diferentes layout para las mismas páginas teniendo en cuenta el dispositivo móvil.
  • AMFImageFilter: Adapta el tamaño de imágenes al vuelo, dependiendo del tamaño de la pantalla del dispositvo.
  • AMFSwitcher: Distribución del contenido dependiendo del cliente (distintos dispositivos móviles, pc)
  • AMFTrace: Log para mostrar las características del dispositivo. Útil para datos estadísticos.

La manera más eficiente para saber si un String es un número

Seguro que en más de una ocasión os habéis encontrado con este problemilla de saber si un String es un número:

Seguro que la primera que os ha venido a la cabeza ha sido esta:

Y si resulta que vuestro proyecto hace plantearos el tema del rendimiento: seguro que ya sabéis que el lanzamiento de excepciones es un proceso costoso…buscando una opción más eficiente podríamos decompilar el Long.parseLong y no lanzar la excepción, entonces tendríamos:

Finalmente también podría ocurrírsenos usar una expresión regular:

En este post estudian el rendimiento de cada uno de estos métodos, resumiendo tendríamos que el segundo método es en media 10 veces más rápido que el primero y el tercero

A %d blogueros les gusta esto: