Android++ para Visual Studio

Una nueva extensión para Visual Studio les permite ahora a los desarrolladores crear apps para Android en el IDE de Microsoft. Android ++ es una extensión gratuita que viene con los scripts MSBuild que permiten a la aplicación de Android desarrollarse dentro de Visual Studio. Está pensado de entrada para las apps en C/C++ basadas en el NDK, aunque incorporara algunos otros elementos que permiten manejar los recursos, compilación integrada en Java, etcétera.
Justin Webb, quien creó Android++, es un programador de Android que trabaja para la compañía de juegos NaturalMotion en Oxford, Inglaterra. En un artículo de su blog sobre la nueva extensión dice que Android aumenta Visual Studio para soportar desarrollo nativo en NDK, indicando que “si usted no está familiarizado o se siente confundido sobre lo que quiere decir ‘nativo’, esto significa esencialmente que los proyectos tienen como compilador C/C++. En breve, se intenta dar soporte a apps cuyo desempeño es crítico, como juegos o simulaciones. También permite manejar la depuración de aquellas apps nativas, usando GDB, el cual se puede controlar desde el IDE de Visual Studio, como si se estuviese depurando una app de Windows. No hay soporte para C# o .NET. Si alguien quiere esto, busque en Xamarin o Mono”.
Android++ requiere alguna de las siguientes ediciones de Visual Studio: Premium, Professional o Ultimate (2010, 2012, 2013). No se da soporte a las versiones gratuitas (Express) de dicha herramienta. Permite depurar en la mayoría de los dispositivos. No hay restricciones de uso o de venta. No hay licencias, nada.
La extensión está aún en beta pero Webb piensa que pronto será lo suficientemente estable para cambiar su status. Webb acepta apps (para hacer pruebas) y dice que da prioridad a aquellos que tengan ya experiencia en Android para minimizar el soporte.
www.asociacionaepi.es



Emuladores de Android

No siempre tendremos un dispositivo Android a mano. Incluso teniéndolo, necesitamos verificar de alguna manera que nuestra aplicación funcionará bien en tantos modelos Android diferentes como sea posible. Aquí entran en escena los emuladores. Con ellos podremos evitar caer en algunos errores frecuentes en el desarrollo. Pero, como veremos más adelante, para tener una mayor seguridad lo mejor es echar mano de dispositivos reales.
Creación y gestión de emuladores
Accederemos al gestor de emuladores (Android Virtual Device Manager) a través de este botón:
Veremos una ventana donde podremos acceder a dos listas: la de los dispositivos virtuales que tenemos creados, y de las definiciones de dispositivos. Para crear un dispositivo virtual (AVD) nuevo, pulsaremos en New, y lo rellenaremos de la siguiente manera:
Con esto, habremos creado nuestro primer emulador. Cuando necesitemos editar nuestros AVDs, lo seleccionaremos en la lista y pulsaremos “Edit”, para volver a ver esta pantalla. En ella podemos editar detalles como la cámara frontal, la trasera, las opciones de memoria y almacenamiento, etc. Pero para los primeros desarrollos, estas opciones las dejaremos sin tocar, nos interesan solamente “Device” y “Target”. Con “Device” elegiremos un dispositivo de entre las definiciones que tenemos. Todos los modelos de uso frecuente ya están predefinidos, por lo que en principio no necesitaremos crear nuevas definiciones. Con “Target” podremos decidir la versión del sistema operativo que tendrá nuestro emulador. A día de hoy el valor más adecuado es el API 16 (v 4.1.2), que cubre la mayoría de los terminales. Si necesitamos crear una nueva definición de dispositivo, lo haremos a través de esta pantalla:
Normalmente no lo necesitaremos, ya que las definiciones predefinidas incluyen la mayoría de los modelos que existen. Si necesitamos crear un nuevo modelo de dispositivo -normalmente será porque no tenemos ninguno con una determinada resolución de pantalla-, indicaremos su nombre, tamaño de pantalla en pulgadas, y resolución en píxeles. Los valores “size”, “screen ratio”, y “density” se autocalcularán y lo más probable es que no necesitemos tocarlos. También podemos decidir qué elementos hardware queremos añadir, como el acelerómetro o el GPS, el teclado físico, etc.
Uso de emuladores
Si aún estamos empezando a manejar Android, veremos que al ejecutar nuestro proyecto se elige automáticamente el dispositivo (o AVD) en el que se ejecuta nuestra aplicación. Si necesitamos que se ejecute en un dispositivo (real o emulado) concreto, tendremos que cambiar un ajuste primero. Dentro de Run → Run Configurations, elegiremos la configuración de nuestro proyecto, y en la pestaña Target activaremos elegir siempre el dispositivo:
Con esto, ya estaremos preparados para usar tantos emuladores como necesitemos o queramos.
Ventajas y limitaciones de los emuladores
Un emulador es una aproximación no del todo perfecta hacia un dispositivo real. Hay utilidades que no tendremos disponibles, normalmente relacionadas con características avanzadas. Por ejemplo, no se puede emular Bluetooth, ni Google Maps. Si se diese el caso de estar diseñando juegos que utilicen OpenGL, el emulador nos servirá más bien poco. Entonces, ¿por qué usar emuladores si tienen limitaciones y si tenemos un dispositivo real? Hay una razón muy importante, y es lidiar con los diferentes tamaños de pantalla que existen.
Si sólo trabajamos con el dispositivo que tenemos, podemos encontrarnos con la desagradable sorpresa de que para los demás tamaños no hemos diseñado bien las pantallas. Una de las formas que hay de evitar esto es trabajar siempre con proporciones y medidas relativas y escalables, nunca absolutas. Con el emulador tendremos más fácil el poder comprobar otros tamaños de pantalla sin tener que comprar varios dispositivos.
Este problema es muy importante porque hoy día no hay control sobre los tamaños de pantalla existentes. En la práctica podemos considerar que hay infinitos, y que no podemos hacer una solución expresa para cada uno. Porque el aspect ratio, o relación entre el ancho y el alto, también es variable. En cualquier momento un fabricante puede diseñar un nuevo tamaño y dejar nuestra aplicación obsoleta. Por eso hay que asumir que no podremos comprobarlos todos, porque no podremos comprar todos los modelos existentes.
La mejor solución consiste en trabajar con valores relativos, y comprobar nuestra aplicación con tamaños variados de pantalla. No tendremos el 100% de seguridad, pero si nuestra aplicación funciona bien en una buena variedad de tamaños, tendremos más posibilidades de ir por el buen camino. Por lo tanto, ésta es la razón más importante para combinar nuestro dispositivo real con emuladores: poder probar diferentes tamaños de pantalla sin tener que comprar todos los dispositivos que existen.
Más información – Curso de desarrollo en Android
www.asociacionaepi.es



Cómo usar adecuadamente el Log de Android en tus aplicaciones

Cómo usar adecuadamente el Log de Android en tus aplicaciones

Buenos días desde la Asociación Española de Programadores Informáticos os traemos un nuevo post sobre Android.
Es posible que durante el desarrollo de una aplicación Android, surja la duda de qué nivel de Log se debe usar, qué cosas se deben loggear y cuales no. En la documentación de Android se trata este tema, el cual traduzco para ponerlo a disposición de todos. Aunque el logging es necesario, tiene un impacto negativo significante en el rendimiento y pierde rápidamente su utilidad si no se mantiene razonablemente breve. La herramienta de logging de Android proporciona cinco niveles distintos para el log. A continuación se describe cada uno y se explica brevemente cómo y cuando deberían usarse:
  • ERROR: Este nivel de logging debe usarse cuando haya ocurrido algo fatal, por ejemplo, algo que tendrá consecuencias visibles para el usuario y que no se podrá recuperar sin eliminar explícitamente algunos datos, desinstalar aplicaciones, borrando las particiones de datos o reseteando el dispositivo por completo. Este nivel se loggea siempre. Los problemas que jusifiquen mostrar un log con este nivel son típicamente buenos candidatos para ser recolectados por un servidor de recopilación de estadísticas (statistics-gathering server).
  • WARNING: Este nivel de logging debe usarse cuando haya pasado algo serio e inesperado, por ejemplo, algo que tendrá consecuencias visibles para el usuario pero es probable que pueda recuperarse sin implicar la pérdida de datos realizando alguna acción explícita, oscilando entre esperar o reiniciar la aplicación por completo descargándola para reinstalarla, o reiniciar el dispositivo. Este nivel se loggea siempre. Igual que el nivel anterior, los problemas que impliquen registrar un WARNING son candidatos a ser reportados a un statistics-gathering server.
  • INFORMATIVE:Este nivel de logging debe usarse para indicar que ha pasado algo que puede resultar interesante a la mayoría de la gente, por ejemplo, cuando se detecta una situación que probablemente tenga un amplio impacto, aunque no es necesariamente un error. Esta condición debe ser loggeada sólo por un módulo que sea el considerado más apropiado en ese dominio (Para evitar registrar más de una vez el evento por componentes no autoritativos). Este nivel se loggea siempre.
  • DEBUG: Este nivel de log debe usarse para dar a conocer qué eventos están ocurriendo en el dispositivo que puedan ser relevantes para investigar y depurar comportamientos de la aplicación inesperados. Se debe loggear únicamente lo necesario para obtener la información suficiente sobre qué está pasando. Si los mensajes de log de en este nivel inundan el log, es probable que deban usarse en el nivel VERBOSE.
    Este nivel será loggeado, incluso en las versiones definitivas de la aplicación. Es necesario que estén en un bloque condicional del tipo if(LOCAL_LOG) o if(LOCAL_LOGD). Donde LOCAL_LOG[D] se define en una clase o sub-componente, para que exista la posibilidad de desactivar todos los mensajes de log en este nivel, por tanto, dentro de éstos bloques no puede haber ninguna lógica del programa, solo los mensajes de log.
  • VERBOSE: Este nivel de logging debe usarse para cualquier otra cosa. Solo se mostrará en las aplicaciones destinadas a depuración y debe estar dentro de un bloque if(LOCAL_LOGV) para permitir su desactivación.

www.asociacionaepi.es



Instalación del entorno de desarrollo y primer proyecto en Android

En Internet encontraremos muchos tutoriales dedicados a este tema, pero la mayoría tiene un problema: se han quedado obsoletos. Con el paso del tiempo, Google ha ido haciendo cambios en las herramientas para desarrollar Android. No siempre han sido del agrado de los usuarios porque se veían obligados a cambiar su forma de trabajar, o incluso se encontraban con que los manuales y las guías que usaban dejaban de estar al día.
Afortunadamente, el proceso de instalación del entorno de desarrollo de Android es más fácil que nunca, y aquí lo vamos a ver en detalle. Partiremos del supuesto de no tener nada instalado, y nuestro objetivo es desarrollar nuestra primera aplicación en Android, el famoso Hola Mundo.

Descarga del SDK
En este enlace descargaremos en un solo paso todo el entorno de desarrollo. El paquete incluye casi todo lo que necesitaremos:
  • Eclipse + plugin ADT
  • Las tools del Android SDK
  • Las herramientas de plataforma Android
  • La plataforma Android más reciente
  • Emuladores más recientes
Si estás más familiarizado con Android, puedes descargarte solamente el SDK. La web te mostrará un único enlace en función de tu sistema operativo, pero también puedes descargar las otras versiones. Existen para Windows de 32 y 64 bits, Linux de 32 y 64 bits, y Mac. En caso de duda, ve directamente a la descarga sugerida, Mac para este ejemplo:
Instalación
Para las 3 plataformas tendremos que tomar nota del directorio donde se instala el SDK, lo necesitaremos más adelante.
Mac
Descargaremos un zip que se descomprimirá en una carpeta con un nombre del tipo adt-bundle-mac-x86_64-xxxx . La moveremos a un directorio que conozcamos, típicamente ~/Development.
Linux
Funcionará de forma muy parecida a Mac, seguiremos los mismos pasos.
Windows
Descargaremos un .exe que nos guiará durante todo el proceso, descargando el Java JDK si es necesario.
Por último arrancaremos Eclipse, y nos iremos a Preferences → Android, y pondremos la ruta al SDK que nos corresponda.
Con estos sencillos pasos, ya estamos preparados para hacer nuestro primer proyecto y arrancarlo.
Primer proyecto
Haremos File → New → Android Application Project, y pondremos “Hola Mundo” como nombre de la aplicación. Pondremos el tema a “none”.
Aceptamos todo, y cuando lleguemos a la pantalla de crear actividad, la dejaremos vacía, y continuamos hasta finalizar el asistente.
Pulsaremos sobre la flecha verde en la barra de herramientas superior, y ejecutaremos nuestro proyecto como una aplicación de Android:
Como aún no tenemos ningún emulador virtual (AVD) creado, tendremos un mensaje de error al que contestaremos que sí. Cuando tengamos abierto el Android Virtual Device Manager, crearemos uno nuevo de este modo:
Aceptamos, continuamos, y si todo ha salido bien, tras unos instantes de carga, tendremos nuestro primer proyecto andando. 

www.asociacionaepi.es



Desarrollando en Android, Action Bar y Listeners

Hoy toca un tema sencillo pero esencial para el buen funcionamiento de la aplicación. Hemos de añadir listeners. También añadiremos una action Bar a nuestra aplicación con un par de botones.
La Action Bar
La Action Bar en android es la típica barra superior que vemos en muchísimas aplicaciones. Añadirla es muy sencilla y depende totalmente de nuestros intereses. Como mi aplicación no tendrá muchos botones/opciones, voy a añadir un par de botones a esta barra que comentaré más al final. Veamos como implementarla.
AndroidManifest.xml
Para escoger el color y diseño de la barra rápidamente, en nuestro AndroidManifest.xml definiremos el tema de nuestra aplicación.
<application android:allowBackup=“true” android:icon=“@drawable/ic_launcher” android:label=“@string/app_name”android:theme=“@android:style/Theme.Holo.Light” >
Hay unas cuantas combinaciones: Holo Light (blanco), Holo Dark (negro) o Holo Light DarkActionBar (aplicación blanca con barra negra). Y para Android 3.0 o superior se puede incluso personalizar el color.
Main.xml
A continuación, en res/menu/ hemos de definir un fichero main.xml (o el nombre que queramos) donde definiremos el contenido de nuestra ActionBar
Como podéis ver, defino un primer item llamado action_reload que me permitirá recargar los datos en un futuro. El segundo item será un botón para acceder a los futuros ajustes. Con el tag: showAsAction=”ifRoom” le decimos que nos muestre el icono si hay sitio en la barra, y si no, que muestre un texto en un menú desplegable. El icono lo definimos con el @drawable/XXXX. y poniendo dicha imagen en las carpetas res/drawableXXX.
MainActivity.java
Y finalmente, en nuestro programa hemos de añadir un par de cosillas. Básicamente, con el código siguiente le decimos que añada la barra con las opciones definidas en el Main.xml
Y ya tenemos nuestra ActionBar que de momento no hace nada.
Lógicamente hay más opciones para gestionar menús/links en una aplicación:
  • Si la ActionBar se os queda corta a nivel de personalización, probad SherlockActionBar
  • Otra opción que cada vez se ve con mayor asiduidad es la implementación de un menú lateral. Aquí más información al respecto.
Pasemos al siguiente punto.
Los Event Listeners
Un Event Listener, o listener a secas es un método o conjunto de acciones que esperan alguna acción para ser ejecutados. Esta acción puede ser un click del ratón, pulsar algún sitio en la pantalla, mover el teléfono y muchísimas cosas más. Nosotros tenemos muchos elementos en la pantalla en los cuales queremos que sucedan cosas:
  • Los botones de la ActionBar
  • Al pulsar encima de un marcador, nos lleve con el GPS hasta dicho lugar
  • Al pulsar encima de un parking de la lista, también nos lleve con el GPS.
Así pues, vamos a poner unos cuantos.
 Los botones de la ActionBar: Utilizaremos el método llamado onOptionsItemSelected, que detecta cuando seleccionamos un método de nuestra barra. A continuación detectamos qué botón hemos pulsado mirando su R.id. Y finalmente, le decimos qué tiene que hacer.
– Al pulsar un botón de la lista: utilizaremos el OnItemClickListener. Lo siguiente es un pelín complicado. Yo quería saber si el parking estaba libre o no, y por ello quiero recuperar una variable del objeto. Eso se hace llamando al adapter y recuperando el item en la posición que hemos pulsado. Y de todo ello recuperamos la variable que nos interesa. Luego podemos hacer lo que queramos con ella.
– Al pulsar en un marcador: con el setOnInfoWindowClickListener controlamos este caso. No tiene mucho secreto, con eventMarkerMap.get(marker) recuperamos el marcador y ya está. Lo interesante es el Intent que he añadido a continuación. Este trozo de código nos permite lanzar automáticamente el Google Navigation para que nos lleve con GPS a la dirección que digas.
– Finalmente, para hacerlo más sencillo y limpio, he recogido estos dos últimos listeners relacionado con los marcadores y la lista y los he puesto en un método llamado addListeners que invoco al añadir los parkings a la lista.
Como véis, el mundo de los listeners está lleno de posibilidades. Básicamente todos tienen la misma estructura: al realizar una acción se activa el método, recuperamos el valor o objeto que necesitamos y finalmente, lanzamos una acción.
www.asociacionaepi.es