OpenMoko para todos

OpenMoko anunción en la conferencia de Tecnologías Emergentes que empezará a vender móviles al gran público. Esta compañía taiwanesa ha desarrollado un teléfono móvil usando hardware y software Open Source, usando para ello Linux y Neo, aunque sólo estaba disponible para desarrolladores.

El dispositivo cuenta con un procesador ARM a 400 MHz, una pantalla táctil de 640×480, GPS y diversas conexiones de red. La siguiente versión, “Neo Freerunner” está en desarrollo, y saldrá a la venta en unos meses.

Fuente: Tech-on!

Eye-Phone: Realidad aumentada y GPS

La idea tras Eye-Phone es la de obtener información de los objetos y edificios que tengamos junto a nosotros a través del teléfono móvil sólo capturando imágenes. El funcionamiento sería unir la información proporcionada por el GPS del móvil con lo capturado por la cámara, enviarlas a un servidor que procesaría la imagen para reconocerla, hacer las pertinentes búsquedas en internet y devolvernos la información disponible. Eye-Phone vuelve sobre el concepto de “realidad aumentada“, superponiendo información procedente del “mundo virtual” en el mundo físico. De hecho es pariente de algunas de las iniciativas que venimos comentado por aquí de buscadores a través de imágenes como Otello o el proyecto de Nokia. De momento Eye-Phone está en el laboratorio de la empresa alemana SuperWise Technologies, que anuncia un prototipo para mediados de año y comercialización en 18 meses.

Fuente: esa y error500

Tags:r

El futuro que llega

Con poco que volvamos la vista y miremos lo que la tecnología nos quería dar, vemos que no hace tanto tiempo que los móviles eran aparatos grandotes y toscos. Incluso algunos llevaban antenas extraíbles! Esos modelos analógicos son ya casi como la prehistoria para un historiador, pero hace aún menos que los móviles tenían una pantalla en la que sólo cabía una línea de texto. Todavía vemos muchos terminales que resisten golpes y muchas primaveras, que tan sólo permiten hablar.

En la pasada MWC la convergencia acabó siendo el santo grial de los fabricantes. Si hace tan sólo un año era complicado hacer una lista con más de 7 teléfonos con GPS, ahora surgen como setas, aunque no muy baratos. El año pasado el mayor número de ventas en cámaras digitales no se lo apuntó sony o canon, sino Nokia, que vendió 200 millones de móviles con cámara, y otros 146 millones con reproductores mp3. La compañía finlandesa espera vender 35 millones de terminales con GPS.

Móviles a 1 GHz

A finales de este año aparecerán los primeros móviles con procesadores a 1GHz, de la mano de Qualcomm. Apodado Snapdragon, irá incluido en algunos terminales de Samsung y HTC.

ARM, el principal fabricante de procesadores para móviles está trabajando en una nueva arquitectura, Coretex A9, que permitirá procesadores con cuatro núcleos. De todas formas tal vez deberían seguir la estrategia de la PlayStation, basada en los procesadores Cell de IBM. El rendimiento de esta plataforma no está en incluir más nucleos en cada procesador, sino en duplicar el número de estos. Es decir, es más eficiente el concepto de multi-socket que el de multi-core.

También el concepto de Symmetrical Multi Processing tendrá gran importancia. Pero sobre todo, es el mercado de los juegos el que más espectativas abre. Este sector proporciona ingresos cercanos a los de la industria del cine, por lo que no es de extrañar que los móviles empiecen a incluir tecnología para dar soporte a los juegos. No es nuevo el coprocesador gráfico del N95, y ya hemos visto alguna de sus posibilidades.

Relacionada: BBC

Android y salud

Andago, empresa española en tecnología open source, ha presentado al concurso Android Developer Challange, Health Assistant, una aplicación socio-sanitaria basada en la dualidad paciente/cuidador. Health Assistant proporciona servicios de cumplimiento terapéutico, localización y seguimiento de pacientes, localización de servicios sanitarios e integración de dispositivos biomédicos para monitorización on-line de pacientes, etc. Es un proyecto que pretende cubrir las expectativas y necesidades de personas que necesitan un seguimiento de su enfermedad, además de favorecer una vida mas independiente y autónoma.

Fuente: http://www.openhealthassistant.com/ y Barrapunto

Ciencia ficción móvil

Los siguientes no son móviles de gama alta, ni siquiera prototipos de futuros móviles, sino los diseños ganadores de los premios TANCHER DESIGN AWARD 2008.
Ganador y esperemos que lleve manual: Gorlov Timofey (1000€)

Segundo Puesto para la petaca móvil: Peter Zsolt Koren (500€)

Tercer Puesto: Shkinder Maxim (300€)

Apple ha patentado una pantalla dual táctil, así que este último diseño parece no muy lejano.

Fuente: tancher

Interfaces hápticos y móviles

Aunque el reducido tamaño y prestaciones de los actuales teléfonos móviles no permite incorporar interfaces hápticas como joysticks, se pueden llevar a cabo acciones que pueden proporcionar una mejor experiencia con el teléfono. Es lo que pretenden investigadores de la universidad de Glasgow usando VibeTonz, un software que utilizando la capacidad de vibrar de muchos móviles, pretende dar una sensación táctil cuando se llevan a cabo acciones como escribir, pulsar un botón en pantalla, etc. Por ejemplo, un pulso de 30 ms puede proporcionar la sensación de pulsar un botón, mientras que pasar el dedo de un botón a otro genera un zumbido de medio segundo, dando una sensación al usuario de que se ha movido a otra tecla. Los resultados se presentarán en la próxima conferencia Computer Human Interaction

Fuente: New Scientist

La juventud, control por GPS

La Facultad de Medicina de la Unviersidad de Indiana ha publicado un informe en la revista Journal of Adolescent Health sobre la viabilidad de usar teléfonos móviles con GPS para seguir su movimiento diario. Según se desprende del informe, los adolescentes pasan más tiempo fuera de sus casa, del colegio y sus alrededores del esperado. Por lo visto, a los jóvenes les importaba poco que siguieran sus movimientos con tal de obtener el teléfono. Con esta experiencia, y han obtenido fondos para continuar, se espera sacar conclusiones sobre el comportamiento urbano, para en una fase posterior determinar las características de esos entornos y su influencia.

Fuente: Science Daily

Bases de datos para móviles (J2ME) Parte III

Análisis de Rendimiento
En la Parte I y II se comentaban las opciones de base de datos en móviles con J2ME. Ahora veremos cómo se comportan en cuanto a rendimiento, lo que puede significar descartar una o todas las soluciones. El usuario de un teléfono móvil admite una espera de más de algunos segundos.
Para comprobar la efiencia en cuanto a tiempo de ejecución, se han realizado distintos test usando las tres implementaciones de prueba que se han comentado en el capítulo anterior. Las pruebas han sido iguales y se ha buscado probar las funciones más básicas de la forma más simple posible.

Para que sirva de muestra, para comprobar la velocidad de inserción de registros en PointBase, se ha usado la aplicación de muestra que ofrece esta empresa, añadiendo algunas líneas para la medición del rendimiento. Por ejemplo, para insertar 100 registros simples en PointBase, se ha modificado la clase Prices.java, en la parte donde se insertan registros de la siguiente forma:

int N = 100;
long begin = System.currentTimeMillis();
for (int i=0;i<N;i++){
m_dbaccess.newItem(i, l_name);
}
long end = System.currentTimeMillis();
System.out.println("PointBase, "+N+" registros:"+ String.valueOf( end – begin) );


La siguiente figura muestra los tiempos que las tres implementaciones han necesitado para insertar 100 registros en la base de datos. Todos los tiempos son en milisegundos.

Aunque los tests se han realizado en condiciones ideales, la diferencia es abismal entre PointBase y las otras dos. En cuanto a memoria consumida, los resultados son similares, como se muestra en la siguiente figura.

Como vemos en la comparativa, el hecho de soportar consultas SQL no compensa en absoluto la extrema ineficiencia de esta base de datos. De lejos PointBase es la que sale peor parada en los test a los que hemos sometidos a los tres candidatos.

Bases de datos para móviles (J2ME) Parte II

Soluciones actuales

A pesar de lo que comentábamos en la Parte I, y los beneficios que prometen las bases de datos rientadas a objetos, sobre todo para dispositivos móviles, son contadas las soluciones que han aparecido para J2ME. La razón principal es que casi todas las bases de datos orientadas a objetos dependen de características de Java que son limitadas o no existen en la plataforma J2ME. Tengamos en cuenta que hasta la aparición de la configuración CLDC 1.1, que aún no soportan muchos móviles, no se podía operar con números en punto flotante.

Para intentar encontrar la solución que más se ajusta a nuestras necesidades vamos a realizar un nálisis y comparación entre las soluciones más prometedoras. En concreto eestudiaremos las características de tres bases de datos para teléfonos móviles en J2ME. Y nos centraremos en estas tres porque, de hecho, tampoco hay muchas más donde elegir. Estas tres soluciones son:

1. PointBase Micro

2. SimpleOODBMS

3. Perst LiteBertiente

PointBase Micro

PointBase Micro es un gestor de base de datos relacional y que soporta SQL como lenguaje para realizar consultas. Se trata de una solución comercial y su licencia no da acceso al código fuente. La idea de partida de PointBase es buena, implementar una RDBMS como se hace en el entorno empresarial, intentando ser una solución robusta y que sigue los estándares y hábitos de la industria tradicional, anclada en sistemas heredados y obsoletos. Y aunque la idea es atractiva, se tropieza con el gran muro que supone la falta de recursos computacionales de los dispositivos móviles.

Bertiente SimpleOODBMS

En Bertiente se ha desarrollado y una base de datos orientada a objetos que es muy rápida para el modelo de datos para el que fue concebida, y cuya virtud radica también en la
pequeña cantidad de memoria física que requiere y lo compacto de su tamaño, 7 Kbytes. El análisis de rendimiento nos va a mostrar que es mucho más rápida que PointBase, y la cantidad de memoria es también mucho menor. Sin embargo, su velocidad está por detrás de la solución que comentaremos a continuación, aunque no la memoria consumida.

Perst Lite

Esta es la solución que más se acerca a lo que se necesita (y puede soportar) un teléfono móvil. Esta es una implementación en Código Abierto para J2ME de una base de datos orientada a objetos. Aunque no entraremos en detalle en materia técnica, las principales
ventajas que nos puede aportar el uso de esta DB son las siguientes:

✔ Persistencia transparente y heredada
✔ Carga recursiva de objetos.
✔ Relaciones uno a uno, uno a muchos, muchos a uno y muchos a muchos.
✔ Acceso secuencial y aleatorio mediante Indices
✔ Implementaión de algoritmos eficientes para estructuras, B+Tree, T-Tree, R-Tree para búsquedas geoespaciales
✔ Posibilidad de búsquedas por valores exactos o rangos inclusivos o exclusivos
✔ Implementación de índices espaciales para búsquedas en objetos geoespaciales.
✔ Open Source

También comentaremos los inconvenientes principales:

✔ Open Source. Si antes era una ventaja, hay que tener en cuenta que es una herramienta muy compleja, que no se tiene soporte técnico, y sobre todo, que no se dispone de documentación técnica.
✔ Su tamaño no es pequeño, así que habrá que sumergirse en el código en busca de material y funcionalidades que no nos sea imprescindible.

En la última parte de esta serie veremos cómo se comportan en cuanto a rendimiento y consumo de recursos.

Bases de datos para móviles (J2ME) Parte I

Para analizar el mercado del software de bases de datos para terminales móviles hemos de
comenzar preguntándonos qué es un terminal móvil. Sin entrar en detalle, la definición más perceptible a día de hoy es la que distingue entre teléfonos móviles y el resto (PDAs, SmartPhones, etc.) La diferencia entre ambos radica principalmente en la limitación de memoria y velocidad del procesador. Si una PDA de gama media cuenta con una memoria RAM de al menos 64 Mbytes y varios cientos de megahertzios, los teléfonos convencionales difícilmente superan los 600 Kbytes de memoria física y los 60 MHz.

De entre todos los modelos de bases de datos que han surgido, son dos tipos los que prácticamente centran toda la atención. Por un lado las bases de datos relacionales (RDMS) como SQL Server, Oracle, MySQL, etc. Y por otro las bases de datos orientadas a objetos (OODBMS). Las grandes bases de datos o que deben ser accedidas concurrentemente por gran cantidad de usuarios, han apostado por el modelo relacional. Sin embargo, el debate sobre su idoneidad en determinados casos se lleva cuestionando desde hace tiempo, debido a que:

• Casi todas las RDMS usan SQL como lenguaje para peticiones. Este es un lenguaje con más de 30 años de antigüedad, que en su origen no estaba pensado para modelos relacionales, y que apenas ha sufrido mejoras en su vida.
• SQL, para acelerar el procesado de las peticiones genera archivos de gran tamaño.
• No todos los modelos de datos requieren un modelo relacional para su almacenamiento. Gran parte de las bases de datos geoespaciales usan el modelo orientado a objetos, como es el caso de PostGis.

Cuando una aplicación (móvil o no) necesita acceder a datos de forma remota, el modelo relacional está plenamente justificado, ya que la carga de trabajo la soporta un servidor tan potente como queramos.

Sin embargo, cuando una aplicación necesita procesar información almacenada de forma local, la base de datos debe estar en el terminal móvil. En este caso, una base de datos relacional no es una solución práctica, por la gran cantidad de recursos que un motor SQL y
su optimizador necesitan. Para el tipo de aplicación común en teléfonos móviles, no es necesario implementar una base de datos relacional, ya que existen mejores opciones.

Las bases de datos orientadas a objetos pueden mejorar el rendimiento en dispositivos móviles y facilitan mucho el desarrollo. La principal ventaja es la integración transparente con lenguajes de programación orientados a objetos, como es el caso de Java. Con una base de datos relacional, la aplicación debería transladar la representación relacional de los datos a la representación en forma de objetos que requiere el lenguaje (en Java todo son objetos). Veámoslo con un ejemplo:

class Persona {
public String nombre;
public String apellido;
public int edad;
public long sueldo;
};


Con una base de datos relacional, la aproximación que seguiríamos para consultar los datos sería algo parecido a esto:


// Aproximación con una RDBMS
Person consultarPorNombre(string apellido){
Statement stmt = con.createStatement();
stmt.setString(1, apellido);
ResultSet cursor = stmt.executeQuery
("SELECT * FROM Persona where apellido like " + apellido + "'%'");
if (!cursor.next()) {
cursor.close();
return null;
}
Persona p = new Persona();
p.nombre = cursor.getString("nombre");
p.apellido = cursor.getString("apellido");
p.edad = cursor.getInt("edad");
p.sueldo = cursor.getLong("sueldo");
return p;
}

Usando el modelo orientado a objetos, la cercanía al propio lenguaje de programación nos
proporciona una integración casi automática:


// Con una base de datos orientada a objetos
Person consultarPorNombre(string apellido){
return personIndex.prefixSearch(apellido);
}


En el siguiente capítulo veremos las soluciones disponibles y se analizarán en cuanto a rendimiento.