Desarrollando aplicaciones para dispositivos móviles: vuelta al pasado

Parecía que la idea de estandarizar los desarrollos y las plataformas ya estaba asentada, que todo el mundo tenía claro que el desarrollo "cross-platform" era preferible a tener que lidiar con distintos sistemas, dispositivos, APISs y demas.

Pero no. De un tiempo a esta parte, con la creciente implantación de los "smartphones", estamos volviendo atrás en este aspecto. En estos momentos ya tenemos unas cinco plataformas a las que atender si queremos desarrollar aplicaciones para móviles (seguro que me dejo alguna en el tintero):

• iPhone y familia (iPod Touch)


• BlackBerry


• Nokia - Symbian


• Android


• J2ME (otros terminales).

Cada plataforma utiliza sus propias herramientas, APIs y lenguajes. Así no hay manera.

Parece que se pretende excluir a los desarrolladores "amateurs" del mercado de vendedores de aplicaciones o que estos se decanten por una plataforma en exclusiva.

Personalmente me sentía muy tentado por empezar a programar algunas cosillas para móviles, pero esta situación me desanima mucho. La única forma que me parece asumible es usar el mínimo común múltiplo, J2ME, y no estoy seguro de que todas las plataformas lo acepten, aparte del propio lío de "configurations" y "profiles" de J2ME.

A Python se le pasó el arroz en el 'Desktop'

Durante mucho tiempo he deseado que la gente de Python incluyera como 'toolkit' para hacer 'GUI's wxPython, pero no. Llegó Python 3000 y han mantenido el obsoleto Tkinker.

Escribir una aplicación de escritorio con Python + wxPython es una gozada, cómodo, fácil, documentado, etc. Pero distribuirla ... éso es otro cantar, sobre todo si lo haces para las tres plataformas mayoritarias (Windows, MacOSX y Linux). 

En Windows no hay Python ni wxPython, o pides que lo instalen o te curras un instalador que meta Python y todas las bibliotecas que use tu aplicación. Otro script a mantener.

En MacOSX por fortuna tenemos Python y wxPython, aunque no siempre la última versión.

En Linux es fácil instalar wxPython a través del gestor de paquetes, pero tienes que instruir al usuario cómo hacerlo si no es muy experto. También puedes encontrarte con problemas de versiones.

Es una pena. En el 'server-side', Python ya es un lenguaje consolidado y juega en la liga de los grandes (en parte gracias a Google, que fichó a GvR y lo utilizó como base de su AppEngine).

El último invento que me lleva un tiempo sorprendiendo es Adobe Air (vale, ya sé que es propietario). Es lo que AWT y Swing debió ser y nunca llegó. El 'runtime' de Java es enorme. ¿Por cuánto anda ya el JRE? ¿200 Mb?

El 'runtime' de Air es mucho más ligero y proporciona un instalador de las aplicaciones que nos bajemos muy chulo. Por otra parte, las aplicaciones se escriben en HTML+JavaScript (o Action Script/Flash/Flex), algo que muchos desarrolladores conocen.

Es una tecnología que tengo en cuarentena, estoy leyendo, haciendo "hola mundos" y poco más, pero promete mucho.

Tira nº 65: Android

Tira nº 64: redes sociales

Ya que está tan de moda el asunto };->

KDE4 en MacOSX

En la entrada anterior comentaba que había instalado KDE (3.5) en el Mac usando la herramienta Fink.
La gente de KDE también tiene preparada la versión 4 para instalarlo en el Mac, además no hay que compilarlos.

He probado a instalarlo, no hay más que ejecutar el instalador y ya está.
Novedades respecto a KDE3 en Mac:

• No necesita el sistema XWindow para correr.


• Las aplicaciones aparecen bajo un directorio propio bajo /Applications

Esto último es un problema: por ejemplo, Konqueror o Dolphin esperan encontrarse los programas auxiliares (Kate para editar textos, Okular para visualizar pdf, Gwenview para ver imágenes, etc) en el PATH, pero estas aplicaciones no están como tal, no existe el ejecutable, sino el "Application Bundle" o directorio .app. 

Como curiosidad no está mal, pero no veo muy estable este KDE4 como para usarlo habitualmente, además falla de vez en cuando.

Para desinstalarlo hay que borrar /Applications/MacPorts/Qt, /Applications/KDE4 y una buena ristra de ficheros y directorios bajo /opt/local (cuidado ahí, que otros programas también dejan ahí sus ficheros).

[gallery link="file" columns="5"]