Androiditis

Si hay una aplicación en la todos, desarrolladores y usuarios estamos de acuerdo en criticar en el universo Android es el Market. Pensado para la facilitar el acceso a las aplicaciones disponibles para la plataforma, el brutal (y quizás, inesperado) crecimiento exponencial en los programas disponibles han desbordado completamente la funcionalidad inicial del Market.

Las aplicaciones se amontonan, es imposible hacer búsquedas mínimamente avanzadas, el mítico “quizás quiso decir…” de Google no está implementado y el sistema de votos es francamente deficiente: una sola votación, de 1 a 5 estrellas, sirve igual para expresar lo interesante que es la aplicación, su usabilidad, su utilidad, el idioma en el que está escrita o si la licencia de código nos convence. No es de extrañar que grandes aplicaciones pasen desapercibidas…

Hace unas semanas leíamos cómo se anunciaba a bombo y platillo la tan esperada reforma del Market. Sin embargo, la decepción ha llegado con las primeras reviews de los que lo han probado: sólo se trata de mejoras menores y poco significativas (la posibilidad de introducir capturas de pantalla en las descripciones, algunas categorías nuevas, un top separado de aplicaciones gratis y de pago… y poco más), por lo que parece que ha llegado el momento de dar definitivamente la espalda al Market y ver qué es lo que se está cociendo para sustituirlo… que es bastante :)

Por un lado, no mucho después de salir el primer Market apareció AndroLib, un buscador de apliaciones más avanzado en el que podemos navegar por todo lo que nos ofrece el Market, con las favoritas del día, estadísticas (muy interesante si queremos ver cuáles son las aplicaciones que más éxito están teniendo), suscribirnos para recibir noticias de las últimas aplicaciones subidas, etc. Además, en la ficha de cada aplicación tenemos directamente el código QR, que nos permite leerlo directamente con el móvil e ir directamente a la fase de instalación sin tener que pasar por el infierno de buscar la aplicación en el Market (hay que ver la expansión que han tenido los códigos QR gracias a las aplicaciones de Android, ¿verdad?). Aquí tenéis un ejemplo de las estadísticas que podemos obtener de nuestra aplicación:

Y por otro lado tenemos la joya de la corona: el AndAppStore. Creado inicialmente por Al Sutton y apoyado firmemente por la comunidad de desarrolladores de Android, se trata de un Market paralelo al Market: un mercado de aplicaciones independiente de Google que nos permite acceder a una cantidad inmensa de nuevos programas de todo tipo y que tiene unas cuantas ventajas adicionales para los desarrolladores que no hay que perder de vista. Aquí tenéis un ejemplo de la ficha de una aplicación:

1) Todo el dinero recaudado por las aplicaciones va directamente al bolsillo del desarrollador, la plataforma no se queda nada (a diferencia del Market oficial, donde el 30% va para Google en concepto de tarifa de transacción). El sistema de pago/cobro es a través de paypal, cómodo y seguro.

2) Las aplicaciones subidas al Market no pasan ningún “exámen” antes de ser subidas. Esto tiene pros y contras, ya que no se nos garantiza que la aplicación que nos descarguemos no sea en realidad un troyano o una herramienta de phising. Sin embargo, gracias a los comentarios de los usuarios, los programas maliciosos se detectan rápidamente, por lo que son eliminados en muy poco tiempo.

3) No hay que pagar dinero para subir aplicaciones al Market, ni siquiera la primera vez. A diferencia de los 25 dólares que nos cobra Google.

4) Hay aún muchos países que no tienen acceso al Market, o al Market sí pero no a aplicaciones de pago a través de él. Para llegar hasta ellos, AndAppStore es la alternativa perfecta.

5) La comunidad de desarrollo que hay detrás (todos voluntarios… hoy por hoy este proyecto es financiado directamente por el propio Al Sutton, así que los gastos están reducidos al mínimo) es enorme y tremendamente involucrada (al fin y al cabo, las mejoras redundan directamente en su beneficio), por lo que las mejoras continuas están garantizadas.

6) ¿He dicho ya que Google no examina las aplicaciones? Ya podéis imaginaros la cantidad de programitas subidos de tono o políticamente incorrectos que podréis encontrar en el AndAppStore :)

Visto lo visto, que el nuevo Market haya sido tan decepcionante importa bastante menos, ¿verdad? Los de Google van a tener que ponerse las pilas si no quieren perder la comba… ya veremos si hacen algo al respecto en los próximos meses o deciden dejar que el Market original muera para centrarse en otras cosas. Estaremos antentos.

Popularity: 89% [?]

¿Quieres un donuts?

Ya ha salido la versión 1.6 del SDK, basada en la rama del proyecto Android Open Source Project, en ella introduce una serie de nuevas funciones y tecnologías. Soporte para CDMA, el estándar propietario de Qualcomm que goza de bastante popularidad en EEUU y Asia. Una característica más interesante es el soporte de un mayor número de resoluciones de pantalla desde el propio framework. También Un motor de texto-a-voz y la posibilidad de integración con la caja de búsqueda rápida.

Para los desarrolladores está disponible la nueva versión del ADT (0.9.3.x) necesaria para esta nueva versión de Android. Tal y como era de esperar, hay retrocompatibilidad.

Una visión más detallada de las novedades (en inglés): http://developer.android.com/sdk/android-1.6-highlights.html

Popularity: 66% [?]

En la red se pueden encontrar cantidades ingentes de ejemplos de tu primera aplicación con Google Android, si bien rara vez nos encontramos con uno que difiera de lo que podemos encontrar en la web oficial para desarrolladores. Incluso los libros de 300 o 400 páginas no van mucho más allá de ahí. Por suerte, hay excepciones, y acaban de publicar en commonsware.com La Guía para Programadores Ocupados de Desarrollo de Aplicaciones Avanzadas con Android. Me llama la atención porque en el título original ‘Avanzados’ lo ponen en cursiva, por lo que interpreto que es más bien para un nivel intermedio. Ideal para aquellos que necesiten ejemplos para ir más alá del Hola Mundo.

En esta guía se cubre el uso de sensores, widgets en la pantalla de inicio, reproducción de contenido multimedia, o la implementación de servicios sofisticados. Desgraciadamente para la obtención el PDF es necesario registrarnos en CommonsWare por 35$ anuales, y con ello tenemos acceso a su biblioteca virtual sin restricciones durante un año. Pero al menos tenemos la oportunidad los ejemplo de código completamente ejecutables de cada capítulo a través de github.com: https://github.com/commonsguy/cw-advandroid/tree Yo ya me he hecho con ellos, ¿tú a qué esperas? ;-)

Otra gran iniciativa es la web OpenIntents, que espero vaya creciendo en número de Intents OpenSource que podemos usar.

Popularity: 24% [?]

A pesar de que un dirigente de Google digera recientemente que el futuro de las aplicaciones móviles pasa por el navegador web, hay toda una serie de beneficios en crear aplicaciones nativas en lugar de basarse exclusivamente en la web:

Ancho de banda
Los recursos estáticos como imágenes, rejillas y sonidos puede llevar a un excesivo consumo de datos en el dispositivo. Con las aplicaciones nativas el ancho de banda es menor, requiriéndo solo conexión para la actualización de datos.

Caché
Las soluciones móviles todavía no poseen el dónde la ubicuidad. Basándonos en el navegador puede que tengamos acceso intermitente a la aplicación. En una solución nativa los datos cacheados proveen de funcionaldiad a la aplicación sin necesidad de conexión contínua.

Características nativas
Los terminales con Android poseen muchas más características más allá del navegador; servicios de geolocalización, cámara, acelerómetro, etc. Con las aplicaciones nativas puedes combinar el acceso a información online con características propias del terminal para dar una experiencia de usuario más rica.

Del libro (en inglés) Android Application Development (Ed.Wrox)

Popularity: 12% [?]

Almacenamiento de archivos en Android

Según la guía oficial de desarrolladores Android, todos los datos de la aplicación (archivos incluidos) son privados de la aplicación. Realizando la compartición de información con otras aplicaciones mediante Content Providers. Son componentes opcionales que dan acceso a la lectura y escritura de datos de una aplicación. Android trae por defecto proveedores de contenido básicos para imágenes, video, audio, archivos y información personal de contacto.

Independientemente si queremos compartir información con otras aplicaciones, la forma de almacenar archivos (que no información, para lo que podemos usar el sistema de almacenamiento datos clave-valor o el API de sqlite) es mediente el uso de métodos del paquete android.content.*, especialmente de la clase Context.

Context.openInputFile()

public FileInputStream openFileInput (String name)
Abre un archivo privado en el paquete Context de la aplicación.

Parámetros:
name El nombre del archivo a abrir para su lectura; no puedo contener separadores.
Devuelve
FileInputStream input stream resultante
Lanza
FileNotFoundException

Análogamente,

Context.openOutputFile() abre un archivo para escritura.

En ambos casos especifican claramente que no es posible incluir un path en su ubicación, ya que esta siempre será el contexto de la aplicación en curso. Y por tanto no podemos usar directamente el framework de desarrollo de alto nivel si lo que queremos es estructurar de alguna manera el contenido que vamos guardando, y por ello tengamos que implementarlo con las librería de bajo nivel incluidas en Android 1.5. O bien, usar el path como nombre del archivo almacena, pero esta solución me parece menos limpia.

Usando la librería de bajo nivel convencional java.io.* necesitamos apuntar a la ruta de ubicación de archivos propia de la aplicación que estamos corriendo, pues es la única en la que tendremos permisos de lectura/escritura. Esta es/data/data/NOMBRE_DEL_PAQUETE/files/

A partir de ahí ya se puede crear subdirectorios y archivos con los correspondientes métodos del paquete.

Popularity: 17% [?]

Para que un proyecto genérico Java que sirva para la creación tanto de aplicaciones bajo JavaSE, JavaME y Java Android hay que tener en cuenta las siguientes consideraciones:

• No hacer uso de librerías específicas de JavaME ni Java Android
• Ser JDK compliance 1.3
• En el proyecto Android deben estar vinculadas todas las dependencias, aunque éstas sean de segundo nivel o superior (esto es debido a la operativa del plugin Android para Eclipse). En el caso de MIDP no es necesaria esta consideración.
• El uso de un JAR JavaSE en Android es inmediatamente convertido a bytecode ejecutable en la DalvikVM, que difiere del resto de implementaciones por estar orientada a registros, y no haciendo uso de clases ME, ni de AWT ni Swing, teniendo entonces su propio conjunto de paquetes que es un subconjunto de la implementación Java OpenSource Apache Harmony.

Popularity: 9% [?]