Como hemos comentado en alguna ocasión, estamos viviendo el auge de las tiendas de aplicaciones. Ahora bien, ¿para qué sirve una tienda de aplicaciones? Evidentemente, si el que pone la tienda (sea Apple, Google, RIM o Microsoft) cobra una cuota a todo aquel que quiere desarrollar y vender aplicaciones y además se queda con un porcentaje de cada venta, al final, algo de dinero gana. Pero, ¿es suficiente para cubrir los costes de disponer de un servidor que ofrece las aplicaciones y el repositorio de las aplicaciones y documentación y demás?

En realidad, el negocio de estos fabricantes es vender terminales. Si yo veo que en un móvil Android se puede ejecutar una aplicación que me permite emular a Luke Skywalker con su sable láser (que casualmente coincide con mi hobby favorito), y eso no se puede hacer en otros modelos, posiblemente acabe comprando ese móvil. Y es que las aplicaciones venden móviles; quizá el iPhone sea el caso más flagrante de esta situación: ¿por qué se compra la gente un iPhone? Porque es el primer móvil que te pone internet en la palma de la mano, porque el interfaz es intuitivo y por las aplicaciones que tiene y cómo las pone a un click de distancia. ¿Quieres un cliente de Twitter? Lo tienes. ¿Uno de Facebook? También. ¿Un juego de plataformas? Pues también lo tienes. Y no tienes que enviar SMSs ni pagar con tarjeta de crédito: está ahí, a un click de distancia.

Y esa inmediatez y avalancha de aplicaciones vende iPhones (y iPod Touch, claro) y es lo que esperan emular los que han venido detrás. Repasemos:

- RIM, con su tienda para Blackberry. Tiene lógica, porque fabrican terminales, se puede copiar el modelo de Apple.
- Google, con su Android Market. No fabrican terminarles, pero sus servicios están disponibles en esos terminales, por lo que les interesa algo que atraiga a compradores a sus terminales para ingresar más por la publicidad que aparece en dichos servicios.
- Microsoft, con su Marketplace para Winwdows Mobile. Lógico, aunque no venden terminales (luego haré un inciso sobre esto), venden licencias de su sistema operativo a los fabricantes, por lo que les interesa que haya más demanda de esos dispositivos. En cuanto al inciso al que me refería, resulta que se rumorea que el Zune HD podría disponer de la posibilidad de descargar contenidos (en principio películas y música) de una tienda. De ahí a descargar aplicaciones desarrolladas con XNA (el kit de desarrollo de videojuegos para PC y Xbox y que no está para Windows Mobile por el momento) hay un paso. POr cierto, esto de la compra de canciones y vídeos también lo tiene Apple con iTunes y es otro de los factores de éxito de sus iPod, pero si lo meten en la tienda accesible directamente desde un icono del iPhone/iPod Touch como se rumorea, darán un paso más en acercar la compra impulsiva al usuario.

Hay otras tiendas, pero generalmente, se puede ver esta pauta que mencionábamos: se pone una tienda porque eso hace vender terminales (o licencias de sistema operativo o tus servicios). Entonces, ¿tendría sentido que, por ejemplo, Sun lanzase una tienda de aplicaciones Java, como hemos visto anunciado? Pues a tenor de lo visto hasta ahora y a no ser que tengan un as en la manga, no parece que eso le vaya a dar más ingresos a Sun. Aunque la noticia habla del escritorio, veamos qué pasariá en el mundo móvil:

Supongo que los terminales J2ME pagan licencia de Sun por su runtime, pero el que haya más aplicaciones J2ME no va a hacer que se vendan más terminales. ¿Por qué? Es fácil: pregunta a cualquier programador J2ME. Es imposible hacer una aplicación mínimamente atractiva que funcione en un número interesante de terminales. Eso significa que si yo hago una versión del Quake en J2ME, sólo será ejecutable en unos pocos terminales (con aceleración 3D, con pantalla de x por y resolución, etc). Y sí, es posible que eso venda unos pocos terminales más de ese modelo, pero no hay nada que hacer frente al resto de los ejemplos comentados. Y es que si os habéis fijado, todos tienen algo en común: se desarrolla para un único modelo. ¿No? Repasemos:

- RIM. Blackberries. Aunque no sea un único modelo, tienen el hardware y el sistema operativo suficientemente restringido para minimizar la fragmentación de la que hablábamos en el caso de J2ME.
- Microsoft. Sólo hay un sistema operativo Windows Mobile y si desarrollas para él con Visual Studio y .NET Compact Framework, te da igual el terminal que sea (Smartphone, teléfono, etc). Eso sí, si haces invocaciones a código nativo con el famoso PInvoke, es posible que tengas que testear modelo por modelo.
- Apple. iPhone=iPod Touch=único terminal. Única resolución de pantalla, único hardware (memoria, procesador), único interfaz, etc. Eso hace las cosas mucho más sencillas para un desarrollador.
- Android. Parecido a Apple: la capa de Google (una máquina virtual, como hace .NET Compact Framework) hace que el terminal sea el mismo de cara a las aplicaciones se trate de lo que se trate. Si sale nueva versión del sistema operativo, tu terminal es actualizable (andá, es lo mismo que hace Apple) y el SDK te permite desarrollar aprovechando la nueva funcionalidad.

¿Y en J2ME? En J2ME, tu compras un terminal que lleva una máquina virtual con un soporte concreto de APIs y eso no se puede actualizar. Si haces una aplicación para el mismo, funcionará, pero si necesitas cosas un poco más "exóticas" (acceso al GPS, a la agenda, a otras aplicaciones, a la cámara de fotos, etc), te tocará recabar información sobre qué terminales soportan qué API para saber dónde más podría funcionar tu aplicación. Y eso es un obstáculo muy grande para desarrollar en este lenguaje.

Veremos a ver si en el escritorio no hay tanto problema, porque al fin y al cabo, tenemos la máquina virtual de Java para abstraernos del hardware subyacente. Pero los desarrolladores en Java sabemos que las implementaciones de esta máquina para los diferentes sistemas operativos no siempre ejecutan exactamente igual el código.

Como conclusión, podemos decir que no a todo el mundo le saldrá rentable su tienda. Y eso, sin contar con que los compradores de un terminal no pueden acceder a cualquier tienda: sólo a la suya. ¿Eso es malo? Evidentemente, en tu tienda sólo vas a ver aplicaciones que te funcionen en tu terminal, por lo que evitarías el bajarte cosas que luego no funcionasen, pero eso es relativamente fácil de imitar con sólo detectar el modelo de terminal desde el que accedes al servidor, cosa que vimos que era perfectamente posible con herramientas como WURFL. Así que el futuro nos dirá si el binomio terminal-tienda puede ser roto y cómo.

Estos días se está celebrando el Mobile World Congress, una de las ferias más importantes sobre móviles y servicios sobre ellos del mundo. Me enorgullece pensar que algunas de las demos que se pueden ver allí se han desarrollado en mi empresa, como la del coche conectado, que usará WiFi, HSDPA y bluetooth para conectarse con todo lo que le rodea y saber así el estado del tiempo, del tráfico y de las carreteras.

Aparte de eso, se han presentado muchísimos terminales, como el HTC Magic (o Android G2), móviles con cámaras de un montón de megapíxeles, pantallas de alta resolución, etc. Cada vez son más fabricantes los que anuncian que sus terminales llevarán Android, aunque Windows Mobile no se queda atrás. La versión 6.5 del sistema operativo para móviles de Microsoft no está mal, pero aún le queda por recorrer para ser lo que podría ser. Por cierto, Eduardo publicó el otro día un post sobre cómo flashear una TyTn II con la nueva ROM.

Sin embargo, el móvil que me ha llamado la atención ha sido el INQ, que permite acceder a Facebook, Skype, MSN y no sé cuántas redes sociales más de manera muy intuitiva.

Lo que está claro es que el hardware ya no es tan importante como el software que permite usarlo. No hay más que ver el éxito del iPhone con un hardware relativamente modesto, pero que es tan fácil de usar que es el dispositivo móvil con el que más se accede a internet. Y eso, en un mundo donde el tráfico de voz ya ha tocado techo (o casi), significa poder enganchar a más consumidores con una tarifa de datos.

Un post de esos que le gustan a mi amigo Martín:

Interesante post sobre el efecto Menéame

Primer móvil con Android el 23 de Septiembre

Primer picoproyector comercial

Ventas de Smartphones en el segundo trimestre de 2008. Blackberry sigue llevando una gran delantera a Windows Mobile

Interesante artículo sobre el móvil en economías emergentes

La saturación de la web 2.0

Premios de TechCrunch50 a las startup más prometedoras. Ganó Yammer, una especie de Twitter empresarial

10 compañías open source a vigilar. Por si queréis invertir...

Pensaba escribir un post sobre el NVIDIA APX 2500, pero los chicos de Noticias 3D se me han adelantado y han reunido los vídeos disponibles en una noticia. También tenemos información en el gadgetoblog de El Mundo y en Xataka. Yo os podría poner todas las características técnicas del chip, pero como en estos temas vale más una imagen que mil palabras:

Para los más aficionados a los tecnicismos, las características concretas las podéis ver en la web de NVIDIA.

Dado que el chip soporta D3D Mobile, podríamos verlo en las próximas PDAs con Windows Mobile 7, quién sabe...

Si alguna vez habéis desarrollado para .NET Compact Framework, os habréis dado cuenta de las muchas limitaciones que tiene y que incluso muchas veces tienes que acudir al código nativo para acceder a cierto hardware de la PDA.

También suele pasar que lo que has aprendido en .NET de escritorio no suele ir bien en la PDA por cuestiones de velocidad o la escasa memoria de que disponen y que el uso de TableAdapters y cosas así carga mucho la aplicación.

Pero no os preocupéis: traigo la solución a vuestros problemas. Mobile Development Handbook es un compendio de lecciones aprendidas de desarrolladores en .NET Compact Framework: cómo acelerar el acceso a datos, compresión en servicios web, sincronización con bases de datos, librerías que pueden venir bien (OpenNetCF, 32feet.net, etc), cómo diseñar interfaces de usuario, trabajar en modo ocasionalmente conectado, etc, etc. Altamente recomendable.

Por otro lado, tras acabar con Un mundo sin fin de Ken Follet, me he puesto con Security Development Lifecycle un libro sobre cómo desarrollar aplicaciones más seguras (metodología, herramientas, código, interfaces de usuario, métodos de securización, etc). De momento tiene buena pinta, así que ya os comentaré si merece la pena. Por cierto, ¡gracias a Eduardo por regalármelo!