Aprendiendo a programar Android en 12 clases gratuitas (+ video)

Por si alguno no se enteró, el equipo de JetBrains adaptó su excelente IDE para Java IntelliJ lanzando junto a Google una versión gratuita llamada Android Studio, que se encuentra en Preview, pero ya disponible para descarga.

Como esta gente no se queda quieta, además de lanzar la IDE, que es una alternativa más moderna y mejorada (al menos en mi opinión) a Eclipse, se asociaron también con el sitio de entrenamiento en línea Tuts+ para publicar una serie gratuita de entrenamiento sobre desarrollo en Android, presentada por el italianísimo Dino Esposito (el contenido está en inglese), una personalidad del mundo .NET pero también reconocido por su ductilidad para moverse entre plataformas, y sus cualidades como autor y entrenador.

La serie, llamada Android for the Busy Developer, compuesta por doce episodios, está basada en IntelliJ y no en Android Studio (no se bien por qué, pero para todo lo básico es lo mismo).

La serie completa cubre:

1. Introducción (~12m) 
2. Diseñador de Interfaces (~18m)
3. Interactividad mínima (~11m)
4. Ciclo de vida (~20m)
5. Más actividades (15m)
6. Vistas de Lista (~16m)
7. HTTP (~14m)
8. Almacenamiento (~15m)
9. Menúes (~16m)
10. Diálogos (~11m)
11. Preferencias (~15m)
12. Publicación (~6m)

Como pueden ver, son más de dos horas y media de entrenamiento, totalmente gratis, y más allá de que Dino muestre cómo se usa IntelliJ, los conceptos aplican al desarrollo Android utilizando la herramienta que uno prefiera (incluso si uno prefiere programar en C#, utilizando Xamarin Studio), porque hay mucho sobre la arquitectura y APIs básicas de la plataforma.

Les dejo el primer episodio (~12 minutos), en el que Dino explica cómo hacer el clásico Hello, World, para que vean más o menos el tono de la serie.

 

Firefox OS: ¿hace falta otra plataforma para móviles? ¡Tal vez si!

En julio del año pasado la fundación Mozilla anunció el arranque de un nuevo proyecto llamado "Boot to Gecko" (B2G), en referencia a la idea de un sistema operativo orientado a móviles que iniciara directamente Gecko, el motor visual detrás de Firefox.

Semejante idea, en un mundo de dispositivos dominado por iOS y Android, en el que aún a Microsoft le está costando entrar, parece disparatada, pero Mozilla no tiene como objetivo necesario ganar mercado, sino impulsar mayor adopción de estándares web en el terreno de mayor crecimiento actualmente, que son celulares y tablets.

La característica fundamental del nuevo sistema operativo, actualmente conocido como Firefox OS (aunque encontrarán más referencias aún a B2G) es que está basado en un kernel de Linux, una capa de abstracción para el hardware (llamada "Gonk") y por encima el motor del navegador Gecko, soportando HTML, CSS y JavaScript que es sobre lo que corren todas las aplicaciones. Y esto significa todas, como la aplicación principal del teléfono, la lista de contactos, portada, etc.

El entorno de ejecución sobre el que corren las aplicaciones se llama Gaia, y para los que quieran probarlo, pueden obtenerse los builds nocturnos de Gaia clonando la cuenta de GitHub (git://github.com/mozilla-b2g/gaia; los builds corren en Mac OS, Linux y Windows). Hay un guía completa sobre el tema, llamada Gaia Hacking, en la Wiki de Mozilla.

Básicamente Gaia ofrece a los desarrolladores la posibilidad de producir aplicaciones web con el stock estándar de HTML5, más un API JavaScript que les da acceso a características especiales del dispositivo.

El otro factor importante es qué nivel de adopción se pueda esperar de esta plataforma, y en ese sentido es alentador ver que el sistema (inicialmente apuntando a hardware muy económico basado en Snapdragon) está siendo adoptado para próximas ofertas de varias operadoras europeas como Deutsche Telekom, Etisalat, Smart, Sprint, Telecom Italia, Telefónica y Telenor. De hecho, en una conferencia de febrero de este año en España, Telefónica y Mozilla mostraron una versión preliminar del sistema corriendo en dispositivos Galaxy II de Samsung, que vienen nativamente con Android. Otras organizaciones soportando directamente el proyecto son Adobe y Qualcomm (más información en esta gacetilla de prensa).

Como es recurrente en todo proyecto de Mozilla, absolutamente toda la plataforma es abierta, permitiendo a los operadores o fabricantes implementar una capa mínima que provee acceso a sus recursos propietarios. Más allá de eso, todo el diseño del sistema está alineado a respetar los mismos estándares web que se impulsan en los navegadores de escritorio, unificándolos aún más, y con un claro objetivo de que otros jugadores de la industria como Apple, Google o Microsoft sigan adoptando ese camino.

PhoneGap: un entorno para gobernar a todos (+ videos)

El terreno del desarrollo de aplicaciones para móviles es cada vez más complejo. Incluso a medida que avanza el dominio de iOS y Android, hay una cantidad de dispositivos y sistemas operativos que aun son relevantes, y las variantes entre formatos, restricciones impuestas por las tiendas de cada fabricante y demás particularidades tienden a complicar la tarea enormemente.

En estos casos siempre han surgido intentos de proveer un único entorno que permita generar aplicaciones para diferentes objetivos, pero en general los resultados no son demasiado buenos porque suelen apuntar a un denominador común que usualmente es bajo y desaprovecha el potencial de muchas de las plataformas. No es el caso con PhoneGap, una plataforma que permite desarrollar aplicaciones nativas para múltiples dispositivos, a partir de su desarrollo en HTML5 (HTML, CSS y JavaScript).

PhoneGap es código abierto y gratuito y fue creado por una pequeña empresa llamada Nitobi que fue comprada en octubre por Adobe, que mantuvo el compromiso de mantener las características abiertas de la plataforma, delegando incluso la base de código a la Apache Software Foundation.

Desarrollando en HTML/JS, PhoneGap permite acceder a todas las API nativas de cada plataforma (salvo en casos ne que no existen) y el empaquetado posterior genera aplicaciones nativas y ajustadas a los requerimientos de los mercados de cada proveedor. Las plataformas cubiertas actualmente son:

• iOS
• Android
• Blackberry (OS 4.6 hasta 6.0)
• WebOS (de hp)
• Windows Phone 7
• Symbian
• Bada (la plataforma de Samsung)

Y las APIs cubiertas cubren casi todo lo que cada tipo de dispositivo tiene disponible (muchos no tienen brújula o no soportan video, por ejemplo), incluyendo:

• acelerómetro
• cámara
• brújula (si hay)
• contactos
• archivos (en los sistemas que lo permiten)
• posición geográfica
• media (audio/video)
• red
• notificaciones visuales, sonoras o vibrador
• almacenamiento

Veamos un ejemplo rápido de cómo utilizar el acelerómetro en JS:

function onSuccess(acceleration) {
    alert('Acceleration X: ' + acceleration.x + '\n' +
          'Acceleration Y: ' + acceleration.y + '\n' +
          'Acceleration Z: ' + acceleration.z + '\n' +
          'Timestamp: '      + acceleration.timestamp + '\n');
};

function onError() {
    alert('onError!');
};

navigator.accelerometer.getCurrentAcceleration(onSuccess, onError);

Esta interfaz funciona en Android, iOS y BlackBerry OS 5.0 o superior. De manera similar puede accederse a casi todos los recursos de los dispositivos, y la funcionalidad es la mejor posible para cada uno de ellos, ya que no se reduce todo al denominador común, sino que hay soporte para toda la funcionalidad de las plataformas. Es importante entender que no hay magia y cada plataforma final mantiene sus requerimientos originales. Por ejemplo, para generar aplicaciones iOS es necesario trabajar en Mac OS, y para genera aplicaciones Windows Phone es necesario Windows; Android requiere en el SDK y Eclipse, etc.

Quedan a continuación un par de vídeos (en inglés) mostrando PhoneGap en acción para iOS y Android.

Se acaba Flash, poco a poco (+video)

Después de mucho ruido en la comunidad a partir de la decisión de Apple de no soportar Flash en iOS, hace más de un año atrás, esta vez fue Adobe quien decidió dejar de insistir con una plataforma que efectivamente nunca funcionó correctamente en dispositivos móviles.

En un comunicado anteayer, Danny Winokur, gerente general de desarrollo interactivo de Adobe expresó claramente que Adobe dejará de desarrollar Flash para dispositivos móviles (teléfonos y tabletas) para concentrarse en computadoras.

Winokur dice en el comunicado (traducciones mías) cosas como: "Durante los últimos dos años hemos entregado Flash Player para navegadores móviles y provisto la expresividad completa de la web a muchos dispositivos móviles". Personalmente creo que pensar que Flash es definitorio para la expresividad de la web es un acto de arrogancia que Adobe está pagando. Por otro lado, estas versiones de Flash para móviles nunca funcionaron correctamente, por problemas genéricos en su diseño básico, tal como detallara Jobs en su momento, en sus durísimas aclaraciones al vedar este producto en sus plataformas.

El texto continúa explicando el nuevo foco de Adobe respecto a estos dispositivos (el énfasis también es mío): "sin embargo, HTML5 ya es soportado universalmente en los dispositivos móviles principales, en algunos casos exclusivamente. Esto convierte a HTML5 en la mejor solución para crear y desplegar contenido en el navegador a través de las plataformas móviles. Estamos excitados con esto y continuaremos trabajando con los principales jugadores de la comunidad HTML incluyendo a Google, Apple, Microsoft y RIM para producir innovación en HTML5 que ellos puedan utilizar para avanzar sus navegadores móviles".

Me suena como una dósis de realidad, y también una manera de tratar de mantenerse relevante en un escenario que claramente les ha restado protagonismo. Más allá de herramientas de edición (algo en lo que Adobe todavía mantiene un liderazgo considerable) no veo cuánto puedan aportar a los navegadores, que realmente avanzan tecnológicamente liderados por Mozilla, Google y Apple, seguidos por Microsoft que está comenzando a ponerse a tono.

Como cierre de la noticia, les dejo un video (en inglés) de unos dos minutos de una entrevista en la que Jobs explicaba brevemente el porque veía a Flash como una plataforma nociva para la web, sobre todo desde el punto de vista móvil.

Grandes noticias sobre MonoTouch y Mono for Android

Esta semana Novell / SUSE anunció que firmó un amplio acuerdo de colaboración con Xamarin, la compañía formada por el equipo que trabajaba para ellos en el desarrollo de estos productos, liderada técnicamente por el infatigable Miguel de Icaza y comercialmente por su socio de años, Nat Friedman.

El acuerdo incluye transferencia a perpetuidad a Xamarin de todos los derechos de propiedad intelectual de todos los productos de la familia Mono (incluyendo MonoTouch, Mono for Android and Mono for Visual Studio) y el control de todas las propiedades relativas al proyecto Mono, como MonoDevelop y la organización Mono en GitHub, y a cambio se compromete a brindar soporte a todos los clientes de SUSE utilizando la plataforma, lo que es un factor importante para grandes cuentas de Novell utilizando las ediciones Enterprise de Mono.

Básicamente, desde mi punto de vista, es una acuerdo de colaboración basado en el hecho de que Novell no puede hacer mucho con esos productos sin el equipo detrás, pero necesita seguir dando respaldo a muchos clientes que los están utilizando. Como menciona el gerente general de SUSE en el anuncio oficial, con este acuerdo ganan las tres partes: Novell, Xamarin y los clientes de ambos.

Inmediatamente después de sellado el trato, Xamarin puso nuevamente disponibles los productos en su tienda en línea, y en el anuncio de Miguel se entiende que gran parte del esfuerzo que Xamarin inició para construir estos productos desde cero (mientras negociaban este acuerdo) va a aplicarse directamente como correcciones e implementación de nuevas características en los productos existentes.

La noticia es muy buena también para la comunidad de código abierto, ya que aunque estos productos que permiten programar en C# en plataformas móviles son pagos, son también la fuente de financiamiento que la empresa necesita para continuar liderando el desarrollo del proyecto Mono, MonoDevelop y los demás componentes abiertos y gratuitos, que nunca se detuvieron.

Prueba de que todos estos cambios nunca afectaron demasiado a la comunidad es que este sábado 23, y hasta el lunes 25 se llevará a cabo la conferencia MonoSpace 2011, dedicada a la plataforma abierta, y alojada en el NERD Center de Microsoft en Boston. La conferencia se empezó a organizar antes de que el equipo de Mono fuera despedido de Novell, y la organización nunca se detuvo a pesar de todas las idas y vueltas que felizmente han concluido en este acuerdo que deja en completo control al equipo original.

Page Speed online: una nueva herramienta para medir el rendimiento de sitios web

Parte del desarrollo de sitios web de calidad es hacer un análisis correcto de su rendimiento, sobre todo desde temprano, utilizando recomendaciones y técnicas modernas para asegurar un sitio correctamente optimizado. Esto no quiere decir ir en contra de la famosa máxima de Donald Knuth, quien nos ensenó que "la optimización prematura es la causa de todos los males" en programación.

Cualquier sitio web público con una expectativa mínima de tráfico debería responder a una línea base para garantizar una buena experiencia a sus usuarios, y hoy día no necesitamos aplicar técnicas extravagantes o perder mucho tiempo para esto, sino más bien aplicar recursos estándares y sencillos, disponibles en todas las plataformas.

Entre las herramientas para realizar el análisis de rendimiento frecuentemente mencionamos la clásica Firebug (y su plugin YSlow) para Firefox, y Page Speed para Firefox o Chrome. Ambas son excelentes y complementarias, cada una con sus fortalezas, pero ahora Google aporta una alternativa más que puede ser útil en muchas circumstancias: Page Speed online.

A diferencia de las anteriores, en lugar de un plugin, este es un servicio en línea que realiza el mismo tipo de análisis, con lo que podemos ejecutarlo desde cualquier navegador, pero sobre todo puede orientar el análisis sobre navegadores desktop (corriendo en una computadora) como sobre navegadores móviles (sobre todo corriendo en smartphones), para los que incluye algunas reglas específicas como la de eliminar redirecciones en la página inicial que no puedan mantenerse en cache, o reducir la cantidad de Javascript durante la carga de la página. Estas son todas situaciones que no son tan problemáticas en otro ambiente, pero en un teléfono que tiene usualmente un ancho de banda y procesamiento limitados, hacen mucha diferencia.

Veamos un ejemplo. Realicé un análisis para navegadores desktop sobre un sitio popular como Twitter, ingresando la dirección:

Y el resultado dio 77 sobre 100 (bastante bueno). El detalle es el siguiente:

Prioridad alta: Estas son reglas que pueden generar mayor impacto en el rendimiento del sitio y que uno debería atacar inicialmente. En el caso de Twitter sólo queda en este nivel la regla: Combinar imágenes como sprites CSS.

Prioridad media: En el siguiente nivel las reglas son: entregar imágenes a escala, optimizar imágenes y minificar Javascript.

Prioridad baja: En este nivel ya hay unos cuantos más. Si quieren pueden ver el informe completo.

Para terminar ejecuto el mismo análisis para la versión móvil de Twitter:

... y: ¡Oh, sorpresa! me da 100/100. No es de extrañar que Twitter esté muy optimizado para su acceso desde móviles. Así que pruebo con otro servicio que tiene buena tradición en cuando a rendimiento (es donde se empezó a trabajar en estas áreas): http://news.yahoo.com/

El resultado para móviles es de 79/100, que es bastante bueno.

No hay reglas de alta prioridad para atacar, y en las de media, ambas son muy específicas para teléfonos: diferir la interpretación de Javascript y hacer que las redirecciones de la página de inicio puedan mantenerse en cache.

Como siempre, lo importante de estos análisis es leer con atención la información acerca de cada regla, entender de qué se trata y que prácticas tenemos que adoptar de manera permanente para que no vuelva a producirse.

 

Mono en Android disponible para todos

Después de un tiempo bajo un programa beta limitado, el equipo de Mono ha abierto finalmente la versión preliminar de MonoDroid para todo el mundo.

Con esta nueva versión preliminar, además, agregaron soporte para desarrollo en Mac OS utilizando MonoDevelop con el AddIn corespondiente.

Mono en Android instala la máquina virtual de Mono, con una versión reducida de las bibliotecas conteniendo sólo lo que tiene sentido en un dispositivo Android.

Además de permitir de esta manera programar en C# en lugar de Java (el único lenguaje completamente soportado por Google en Android), MonoDroid incluye una adaptación completa de las APIs de Dalvik (la máquina virtual de Android) con una interfaz mucho más familiar para desarrolladores C#, incluyendo propiedades, eventos, tipos genéricos, y realizando conversiones de manera automática cuando es necesario.

Más detalles en el post de anuncio de Miguel de Icaza (en inglés).

Aprovechando que se ha liberado y agregaron soporte completo para Mac, les dejo unas imagenes capturadas tras actualizar mi entorno y probar la aplicación que viene como plantilla (estilo Hello, World).

Así se ve la solución y la actividad principal inmediatamente después de crear un nuevo proyecto Android:

Se puede hacer debugging en emuladores o dispositivos reales. El SDK de Android trae emuladores genéricos y se pueden generar otros para modelos específicos obteniendo el kit del fabricante para Android. Motorola, por ejemplo, los provee para mi Milestone y otros dispositivos con Android.

En la práctica es muchísimo más rápido probar contra el teléfono. La primera vez tarda un poco más porque instala el runtime, pero las siguientes va mucho más rápido. Los emuladores me dan la impresión de ser unas 5 o 6 veces más lentos (al menos que mi teléfono). La ventaja de los emuladores es que se pueden capturar más fácilmente las pantallas, como en el ejemplo debajo, que muestra uno genérico recién iniciado:

Y finalmente, la emocionante aplicación de ejemplo, funcionando en el emulador. Cada vez que tocamos el botón incrementa el número de clicks. No está tan mal para ser algo que el entorno  genera solo, sin tener que modificar un solo caracter:

 

Regalo de navidad: Code & Beyond versión móvil

Para quienes leen este blog usualmente desde su celular, acabamos de agregar un estilo mejorado para navegadores con pantallas reducidas, como teléfonos o iPods.

Esperamos que el formato les sea más cómodo para leer.

Si tienen instalada una aplicación de lectura de códigos de barras bi-dimensionales (la mayoría de los teléfonos la tienen actualmente) pueden apuntar su cámara directamente al código debajo para navegar hacia este blog:

 

 

 

 

 

¡Felíces fiestas!

Android 2.3 (Gingerbread) recién salido del horno

Siguiendo la tradición de ponerle nombres de cosas dulces a las versiones de sus sistema operativo para dispositivos, Google lanzó Android 2.3, conocido como Gingerbread, y su correspondiente Kit de Desarrollo.

Como curiosidad, estos son los nombres de las versiones anteriores:

1.5	1.6	2.0/2.1	2.2	2.3
Cupcake	Donut	Eclair	Froyo	Gingerbread

Las mejoras principales de esta versión se enfocan en:

• Mejoras para desarrollo de juegos Principalmente a través de mejoras en el tiempo de respuesta gracias a retoques en el garbage collector y manejo de eventos, y exponiendo más APIs nativas que permiten acceder a bajo nivel las entradas y sensores (incluyendo giróscopos), EGL/OpenGL ES, OpenSL ES, etc.
• Más riqueza multimedia La plataforma soporta ahora estándares de video abiertos como VP8 / WebM, audio y voz AAC y  ARM-wideband, y agrega efectos como reverb, ecualización, virtualización de audífonos y mejora de bajos.
• Más formas de comunicación La plataforma soporta múltiples cámaras, típicamente para una frontal utilizada en video chats, soporte de llamadas via internet via SIP/VOIP,  y NFC (Near Field Communications) para permitir que los dispositivos se comuniquen con otros dentro de un rango de proximidad de unos 10 centímetros.

Aquí dejo el video promocional:

Y la liberación de la nueva versión se cristaliza con la aparición en conjunto de un primer dispositivo que trae esta versión de fábrica, el Nexus S, que Google desarrolló en conjunto con Samsung. Dejo también el video promocional para que se entretengan:

 

Blackberry Developer Day 2010 (Buenos Aires)

Sobre la fecha, pero no podíamos dejar de avisar de este evento para desarrolladores en la plataforma Blackberry organizado por la gente de RIM mañana, en el Hotel Sheraton de Buenos Aires.

El seminario es gratuito y apunta a cualquier desarrollador que enfrenta el desafío de integrar sus aplicaciones a esta plataforma de comunicaciones, o a quienes quieren aprovechar sus características para ampliar los servicios de aplicaciones existentes.

La plataforma cuenta con servicios PUSH y con BES (Blackberry Enterprise Server) del lado del servidor, y puede complementarse con aplicaciones en los dispositivos utilizando Java y Widgets específicos.

En el evento se presentarán los kits para desarrollo propios y plugins para otros entornos.

Google DevFest en Buenos Aires (Día 1)

En el coqueto auditorio de la Universidad Católica Argentina arrancó el Google DevFest de este año.

El primer día estuvo dedicado exclusivamente a Android. Por la mañana hubo un evento previo al que no asistí, destinado a que los participantes instalaran el SDK y desarrollaran su primer aplicación Android.

Los comentarios fueron variados, pero al parecer sirvió como una primer experiencia, aunque algunos decían que se perdió mucho tiempo instalando (algo que se suponía que los asistentes debían hacer previamente).

Por la tarde, el evento principal estuvo compuesto por cuatro charlas:

Un vistazo a Android SDK y lo nuevo en Froyo, que debía presentar Billy Rutledge pero presentó Tim Bray, como puede verse en la foto.

Bray es un gran presentador, aunque me pareció un desperdicio dando esta introducción.

Construcción de Aplicaciones de Alto Desempeño fue la siguiente charla de Bray, que mantuvo el nivel básico, y era en realidad como hacer aplicaciones que no tengan pobre desempeño. Mucho foco en cosas como no utilizar reflection, no acceder el file system o -peor aún- la red desde el thread de la interfaz de usuario, y otros temas que los desarrolladores profesionales deberían saber a esta altura. Como temas interesantes mostró algunas herramientas de profiling como TraceView e hizo foco en el clásico "no suponer nada; medir y corregir".

Continuó Fred Chung con Adaptación al Hardware y Locale, una sesión de 45 minutos explicando temas muy básicos como la relación de puntos por pulgada de los dispositivos, como usar wrappers para soportar diferentes versiones del SDK, o como usar archivos de recursos. Confirmó mi apreciación de que el evento se dirige a un nivel muy básico de desarrollador.

Cerró Tim Bray (el dueño de la tarde) con la mejor sesión a mi criterio, sobre Mejores Prácticas para el diseño de IU en Android, en la que recorrió tips realistas sobre diseño de interfaz, bastante genéricos pero útiles, y con detalles específicos de la plataforma. Muy interesante la mención a utilizar Analytics for Mobile para medir qué funcionalidad usan los usuarios en la práctica, y cómo. Y un buen consejo con ejemplo incluido fue el de tener diseñadores profesionales (de interacción, agregaría yo, no gráficos solamente) en el equipo de desarrollo, algo que suele marcar la diferencia con una aplicación que se populariza en el Market y las que no lo hacen.