Author Archives: admin

Android diseño de apps: Principios de Diseño

Principios de Diseño

[fuente: http://developer.android.com/design/index.html]

Enfocaremos los trabajos de diseño de nuestras apps en tres puntos (que son los mismos sobre los que se diseña el propio sistema operativo de Android).Estos principios de diseño son programados por y para el Android User Experience Team para intentar preservar el interes de los usuarios. Consideramos cuando aplicas tu creatividad y pensamiento de diseño . Desviate con proposito.

Enganchame (Enchant Me)

Las aplicaciones deberían combinar belleza, simplicidad y el proposito de crear una experiencia mágica que no sea dificil de utilizar y que sea potente.

Sorprendeme

Un fondo bonito, una animación cuidadosamente colacada, o un efecto de sonido elegante son atractivos a los usuarios. Los efectos sutiles contribuyen a dar una sensación de comodidad y potencia en la palma de tu mano.

Los objetos reales son más divertidos que los botones y los menus

Permite que la gente directamente toque y manipule objetos en tus apps. Eto reduce el esfuerzo cognitivo necesario para realizar una tarea y la hace más emocionante.

Dejame hacerlo mio

A la gente le encanta añadir un toque personal porque ayuda a sentirse como en casa y en control de la situación. Proporciona opciones por defecto sensible y atractivos a la vez que considera customizaciones opciones divertidas que no escondan las tareas principales.

Intenta conocerme

Que tu app aprenda de las preferencias que el usuario utiliza. De forma que antes de pedirle que configure las mismas opciones una y otra vez, permítele que pueda recuperar elecciones previas de una forma fácil.

Simplificame la vida

Las apps de Android te hacen la vida más fácil y son fáciles de entender. Cuando la gente usa tu app la primera vez, debe de ser lo suficientemente intuitiva para averiguar las características más importantes.

Házlo breve

Utiliza frases cortas con palabras simples. La gente se salta las frases si son muy largas.

Las imágenes son más rápidas que las palabras

Considera utilizar imagenes para explicar ideas para conseguir así la atención de la gente y puede ser mucho más eficiente.

Decide por mi pero dejame decir la última palabra

Demasiadas decisiones y elecciones hace a la gente infeliz.Permite que haya ‘undo’ para el caso de equivocaciones.

Solo muestra lo que necesito y cuando lo necesito

La gente se harta cuando ellos ven demasiados elementos a la vez. Divide las tareas y la información en trozos pequeños y digeribles. Esconde las opciones que no son esenciales en ese momento, y guialos cuando ellos quieran ir a esas opciones.

Yo siempre debería saber donde estoy

Da a la gente confianza sobre donde están según naveguen por la app. Reserva un lugar en tu app que parezca distinto y utiliza transiciones para mostrar relaciones entre pantallas. Proporciona feedback de tareas en progrreso.

Nunca pierdas mis cosas

Guarda bien lo que a la gente le llevó tiempo crear y déjales acceder a esas cosas desde cualquier sitio. Recuerda sus settings , sus toques personales y creaciones entre teléfonos, tablets y ordenadores. Haz que la actualización sea la cosa más fácil del mundo.

Si hay opciones parecidas , deben actuar de la misma forma

Ayuda a la gente a diferenciar funcionalidades distintas haciendolas visualmente distintas más alla de los subtitulos. Elimina modos, es decir sitios que parecen similares pero que actuan diferentes con la misma entrada de datos.

Solo interrumpeme si es importante

Como un buen asistente personal, protege a la gente de los detalles menos importantes. La gente tiene que permanecer atenta en lo importante , y a menos que sea algo crítico, una interrupción puede ser fea y frustante.

Házmelo divertido

No es suficiente con hacer apps que son fáciles de utilizar. Las apps de Android invita a los usuarios a utilizar las apps de una forma inventiva. Android te permite combinar aplicaciones en workflows de multitasking, notificaciones y compartición de datos.

Dame trucos que funcionen en todos sitios

La gente se siente bien cuando ellos averiguan cosas por si mismos. Haz tus apps fáciles para aprender por medio de utilizar patrones visuales conocidos y memoria eficiente desde otras Android apps. Por ejemplo, el gesto de un toquecito puede ser un buen atajo de tipo navegacional.

No es mi culpa

Se educado en como pides a la gente que haga correcciones. Ellos quieren sentirse gent lista cuando utilizan tu app. Si algo va mal, dales instrucciones claras de recuperación pero sin explicarle demsiados detalles técnicos. Si lo puedes solucionar sin que el usuario se entere , incluso mejor.

Divide y vencerás

Divide las tareas complejas en pasos más pequeños que puedan ser fácilmente hechos. Dales feedback sobre las tareas realizandose, incluso si es un efecto gráfico satil como añadirle brillo a un elemento.

Hazme creer que soy experto

Haz que los novatos se sientan como expertos habilitandoles a hacer cosas que nunca pensarian ellos hacer. Por ejemplo, los atajos que combinan multiples efectos sobre fotos pueden hacer que los fotógrafos amateurs se sientan orgullosos con solo unos pocos pasos.

Que las tareas importantes sean rápidas

No todas las acciones son iguales. Decide que es lo más importante en tu app y hazlo fácil de encontrar y rápido de utilizar, como por ejemplo el botón de shutter  de una cámara, o el botón de pausa de un reproductor.

Android: firmando tu app con un certificado

[Fuente: http://developer.android.com/guide/publishing/app-signing.html]

El sistema Android requiere que todas las aplicaciones instaladas sean firmadas digitalmente con un certificado con un clave privada que es proporcionada por el desarrollador de la aplicación. El sistema Android utiliza el certificado como una forma de identificar al autor de una aplicación y establecer relaciones con confianza entre las aplicaciones. El certificado no se utiliza para controlar qué aplicaciones puede instalar el usuario. El certificado no necesita estar firmado por una autoridad certificadora: se permite , y es típico, que las apps Android utilicen certificados auto-firmados.

Los puntos principales para entender sobre firmado de aplicaciones Android son:

  • Todas las aplicaciones deben ser firmadas. El sistema no instalará una aplicación en un emulador o en un dispositivo si no está firmada.
  • Para probar y depurar tu app, las herramientas de compilación firman tu app con una debug key especial que es creada por el Android SDK build tools.
  • Cuando estás listo para publicar tu app para usuarios finales, debes firmarla con un clave privada conforme. No puedes publicar una app que está firmada con la debug key de las SDK tools
  • Puedes utilizar certificados auto-firmados para firmar tus aplicaciones. No se necesita ninguna autoridad certificadora.
  • El sistema comprueba la fecha de caducidad del certificado solo en tiempo de instalación. Si el certificado caduca después de haber sido instalada la app , la app seguirá funcionando normalmente.
  • Puedes utilizar herramientas estandar – como Keytool y Jarsigner – para generar keys y firmar tus ficheros .apk.
  • Después de firmar tu app para publicar, recomendamos que utilices la herramienta zipalign para optimizar el APK final.

El sistema Android no instalará o ejecutará una aplicación que no está firmada apropiadamente. Esto se aplica dondequiera el sistema este instalado, tanto en un dispositivo como en un emulador. Por esta razón, debes configurar tu aplicación (ver cómo más adelante) para que se firme antes de ejecutarla o depurarla en un emulador o dispositivo.

El proceso de firmado

El proceso de build de Android firma tu aplicación de forma diferente dependiendo de qué modo de compilación estés utilizando.Hay dos modos de build: debug mode y release mode. Cuando se está en fase de desarrollo y de prueba utilizamos el debug mode, y se usa el release mode cuando se va a publicar la app o distribuirla de alguna forma.

Cuando compilamos en debug mode el Android SDK build tools utiliza la herramienta Keytool (incluida en el JDK) para crear una debug key. Como las SDK build tools crean la debug key, son las propias herramientas de SDK tools las que conocen el alias y la password de la key. Cada vez que compilas tu app en mode debug, la build tools utilizan la debug key junto con la utilidad Jarsigner (también incluida en el JDK) para firmar los .apk de tu app.Como el alias y la password son conocidos por las SDK build tools, las tools no necesitan pedirte estos datos cada vez que compilas.

Cuando compilamos en modo release utilizamos nuestra propia key para firmar nuestra aplicación. Si no tienes una private key, puedes utilizar la utilidad Keytool para crearte una. Cuando compilas tu aplicación en modo release, las build tools utilizand tu private key junto con el Jarsignet para firmar los .apk de tu app. Debido a que el certificado y el private key que utilizas son de tu propiedad, en este caso tienes que proporcionar la password para el keystore y el key alias.

El proceso de debug signing sucede automaticamente cuando ejecutas o depuras tu app utilizando Eclipse con el ADT plugin. El firmado de debug también se utiliza automaticamente cuando utilizas un script de Ant con la opción “debug”  habilitada. Puedes automatizar el proceso de release signing utilizando el Export Wizard de Eclipse o modificando el script Ant y compilando con la opción “release”.

Estrategias de firmado

Algunos aspectos del firmado de las aplicaciones pueden afectar como llevas a cabo el desarrollo de tu aplicación, especialmente si estás planeando publicar múltiples aplicaciones.

En general, se recomienda a todos los programadores que firmen todas sus aplicaciones con el mismo certificado y a lo largo de toda la vida de tus aplicaciones. Hay varias razones para hacerlo así:

  • Application upgrade – As you release updates to your application, you will want to continue to sign the updates with the same certificate or set of certificates, if you want users to upgrade seamlessly to the new version. When the system is installing an update to an application, it compares the certificate(s) in the new version with those in the existing version. If the certificates match exactly, including both the certificate data and order, then the system allows the update. If you sign the new version without using matching certificates, you will also need to assign a different package name to the application — in this case, the user installs the new version as a completely new application.
  • Application modularity – The Android system allows applications that are signed by the same certificate to run in the same process, if the applications so requests, so that the system treats them as a single application. In this way you can deploy your application in modules, and users can update each of the modules independently if needed.
  • Code/data sharing through permissions – The Android system provides signature-based permissions enforcement, so that an application can expose functionality to another application that is signed with a specified certificate. By signing multiple applications with the same certificate and using signature-based permissions checks, your applications can share code and data in a secure manner.

Otra consideración importante es decidir el periodo de válidez de la key que utilizarás.

  • If you plan to support upgrades for a single application, you should ensure that your key has a validity period that exceeds the expected lifespan of that application. A validity period of 25 years or more is recommended. When your key’s validity period expires, users will no longer be able to seamlessly upgrade to new versions of your application.
  • If you will sign multiple distinct applications with the same key, you should ensure that your key’s validity period exceeds the expected lifespan of all versions of all of the applications, including dependent applications that may be added to the suite in the future.
  • If you plan to publish your application(s) on Google Play, the key you use to sign the application(s) must have a validity period ending after 22 October 2033. Google Play enforces this requirement to ensure that users can seamlessly upgrade applications when new versions are available.

As you design your application, keep these points in mind and make sure to use a suitable certificate to sign your applications.

Configuración básica para el  Signing

Before you begin, make sure that the Keytool utility and Jarsigner utility are available to the SDK build tools. Both of these tools are available in the JDK. In most cases, you can tell the SDK build tools how to find these utilities by setting your JAVA_HOME environment variable so it references a suitable JDK. Alternatively, you can add the JDK version of Keytool and Jarsigner to your PATH variable.

If you are developing on a version of Linux that originally came with GNU Compiler for Java, make sure that the system is using the JDK version of Keytool, rather than the gcj version. If Keytool is already in your PATH, it might be pointing to a symlink at /usr/bin/keytool. In this case, check the symlink target to be sure it points to the Keytool in the JDK.

Signing in Debug Mode

The Android build tools provide a debug signing mode that makes it easier for you to develop and debug your application, while still meeting the Android system requirement for signing your APK. When using debug mode to build your app, the SDK tools invoke Keytool to automatically create a debug keystore and key. This debug key is then used to automatically sign the APK, so you do not need to sign the package with your own key.

The SDK tools create the debug keystore/key with predetermined names/passwords:

  • Keystore name: “debug.keystore”
  • Keystore password: “android”
  • Key alias: “androiddebugkey”
  • Key password: “android”
  • CN: “CN=Android Debug,O=Android,C=US”

If necessary, you can change the location/name of the debug keystore/key or supply a custom debug keystore/key to use. However, any custom debug keystore/key must use the same keystore/key names and passwords as the default debug key (as described above). (To do so in Eclipse/ADT, go to WindowsPreferencesAndroidBuild.)

Caution: You cannot release your application to the public when signed with the debug certificate.

Eclipse Users

If you are developing in Eclipse/ADT (and have set up Keytool and Jarsigner as described above in Basic Setup for Signing), signing in debug mode is enabled by default. When you run or debug your application, ADT signs the .apk file with the debug certificate, runs zipalign on the package, then installs it on the selected emulator or connected device. No specific action on your part is needed, provided ADT has access to Keytool.

Ant Users

If you are using Ant to build your .apk file, debug signing mode is enabled by using the debug option with the ant command (assuming that you are using a build.xml file generated by the android tool). When you run ant debug to compile your app, the build script generates a keystore/key and signs the APK for you. The script then also aligns the APK with thezipalign tool. No other action on your part is needed. Read Building and Running Apps on the Command Line for more information.

Expiry of the Debug Certificate

The self-signed certificate used to sign your application in debug mode (the default on Eclipse/ADT and Ant builds) will have an expiration date of 365 days from its creation date.

When the certificate expires, you will get a build error. On Ant builds, the error looks like this:

debug:
[echo] Packaging bin/samples-debug.apk, and signing it with a debug key...
[exec] Debug Certificate expired on 8/4/08 3:43 PM

In Eclipse/ADT, you will see a similar error in the Android console.

To fix this problem, simply delete the debug.keystore file. The default storage location for AVDs is in ~/.android/ on OS X and Linux, in C:Documents and Settings<user>.android on Windows XP, and in C:Users<user>.android on Windows Vista and Windows 7.

The next time you build, the build tools will regenerate a new keystore and debug key.

Note that, if your development machine is using a non-Gregorian locale, the build tools may erroneously generate an already-expired debug certificate, so that you get an error when trying to compile your application. For workaround information, see the troubleshooting topic I can’t compile my app because the build tools generated an expired debug certificate.

Signing en Release Mode

When your application is ready for release to other users, you must:

  1. Obtain a suitable private key
  2. Compile the application in release mode
  3. Sign your application with your private key
  4. Align the final APK package

If you are developing in Eclipse with the ADT plugin, you can use the Export Wizard to perform the compile, sign, and align procedures. The Export Wizard even allows you to generate a new keystore and private key in the process. So if you use Eclipse, you can skip to Compile and sign with Eclipse ADT.

1. Obtain a suitable private key

In preparation for signing your application, you must first ensure that you have a suitable private key with which to sign. A suitable private key is one that:

  • Is in your possession
  • Represents the personal, corporate, or organizational entity to be identified with the application
  • Has a validity period that exceeds the expected lifespan of the application or application suite. A validity period of more than 25 years is recommended.If you plan to publish your application(s) on Google Play, note that a validity period ending after 22 October 2033 is a requirement. You can not upload an application if it is signed with a key whose validity expires before that date.
  • Is not the debug key generated by the Android SDK tools.

The key may be self-signed. If you do not have a suitable key, you must generate one using Keytool. Make sure that you have Keytool available, as described in Basic Setup.

To generate a self-signed key with Keytool, use the keytool command and pass any of the options listed below (and any others, as needed).

Warning: Keep your private key secure. Before you run Keytool, make sure to read Securing Your Private Key for a discussion of how to keep your key secure and why doing so is critically important to you and to users. In particular, when you are generating your key, you should select strong passwords for both the keystore and key.

Keytool Option Description
-genkey Generate a key pair (public and private keys)
-v Enable verbose output.
-alias <alias_name> An alias for the key. Only the first 8 characters of the alias are used.
-keyalg <alg> The encryption algorithm to use when generating the key. Both DSA and RSA are supported.
-keysize <size> The size of each generated key (bits). If not supplied, Keytool uses a default key size of 1024 bits. In general, we recommend using a key size of 2048 bits or higher.
-dname <name> A Distinguished Name that describes who created the key. The value is used as the issuer and subject fields in the self-signed certificate.Note that you do not need to specify this option in the command line. If not supplied, Jarsigner prompts you to enter each of the Distinguished Name fields (CN, OU, and so on).
-keypass <password> The password for the key.As a security precaution, do not include this option in your command line. If not supplied, Keytool prompts you to enter the password. In this way, your password is not stored in your shell history.
-validity <valdays> The validity period for the key, in days.Note: A value of 10000 or greater is recommended.
-keystore <keystore-name>.keystore A name for the keystore containing the private key.
-storepass <password> A password for the keystore.As a security precaution, do not include this option in your command line. If not supplied, Keytool prompts you to enter the password. In this way, your password is not stored in your shell history.

Here’s an example of a Keytool command that generates a private key:

$ keytool -genkey -v -keystore my-release-key.keystore
-alias alias_name -keyalg RSA -keysize 2048 -validity 10000

Running the example command above, Keytool prompts you to provide passwords for the keystore and key, and to provide the Distinguished Name fields for your key. It then generates the keystore as a file called my-release-key.keystore. The keystore and key are protected by the passwords you entered. The keystore contains a single key, valid for 10000 days. The alias is a name that you — will use later, to refer to this keystore when signing your application.

For more information about Keytool, see the documentation at http://docs.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html

2. Compile the application in release mode

In order to release your application to users, you must compile it in release mode. In release mode, the compiled application is not signed by default and you will need to sign it with your private key.

Caution: You can not release your application unsigned, or signed with the debug key.

With Eclipse

To export an unsigned APK from Eclipse, right-click the project in the Package Explorer and select Android ToolsExport Unsigned Application Package. Then specify the file location for the unsigned APK. (Alternatively, open your AndroidManifest.xml file in Eclipse, select the Manifest tab, and click Export an unsigned APK.)

Note that you can combine the compiling and signing steps with the Export Wizard. See Compiling and signing with Eclipse ADT.

With Ant

If you are using Ant, you can enable release mode by using the release option with the ant command. For example, if you are running Ant from the directory containing yourbuild.xml file, the command would look like this:

$ ant release

By default, the build script compiles the application APK without signing it. The output file in your project bin/ will be <your_project_name>-unsigned.apk. Because the application APK is still unsigned, you must manually sign it with your private key and then align it using zipalign.

However, the Ant build script can also perform the signing and aligning for you, if you have provided the path to your keystore and the name of your key alias in the project’sant.properties file. With this information provided, the build script will prompt you for your keystore and alias password when you perform ant release, it will sign the package and then align it. The final output file in bin/ will instead be <your_project_name>-release.apk. With these steps automated for you, you’re able to skip the manual procedures below (steps 3 and 4). To learn how to specify your keystore and alias in the ant.properties file, see Building and Running Apps on the Command Line.

3. Sign your application with your private key

When you have an application package that is ready to be signed, you can do sign it using the Jarsigner tool. Make sure that you have Jarsigner available on your machine, as described in Basic Setup. Also, make sure that the keystore containing your private key is available.

To sign your application, you run Jarsigner, referencing both the application’s APK and the keystore containing the private key with which to sign the APK. The table below shows the options you could use.

Jarsigner Option Description
-keystore <keystore-name>.keystore The name of the keystore containing your private key.
-verbose Enable verbose output.
-sigalg The name of the signature algorithim to use in signing the APK. Use the value MD5withRSA.
-digestalg The message digest algorithim to use in processing the entries of an APK. Use the value SHA1.
-storepass <password> The password for the keystore.As a security precaution, do not include this option in your command line unless you are working at a secure computer. If not supplied, Jarsigner prompts you to enter the password. In this way, your password is not stored in your shell history.
-keypass <password> The password for the private key.As a security precaution, do not include this option in your command line unless you are working at a secure computer. If not supplied, Jarsigner prompts you to enter the password. In this way, your password is not stored in your shell history.

Here’s how you would use Jarsigner to sign an application package called my_application.apk, using the example keystore created above.

$ jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore my-release-key.keystore
my_application.apk alias_name

Running the example command above, Jarsigner prompts you to provide passwords for the keystore and key. It then modifies the APK in-place, meaning the APK is now signed. Note that you can sign an APK multiple times with different keys.

Caution: As of JDK 7, the default signing algorithim has changed, requiring you to specify the signature and digest algorithims (-sigalg and -digestalg) when you sign an APK.

To verify that your APK is signed, you can use a command like this:

$ jarsigner -verify my_signed.apk

If the APK is signed properly, Jarsigner prints “jar verified”. If you want more details, you can try one of these commands:

$ jarsigner -verify -verbose my_application.apk

or

$ jarsigner -verify -verbose -certs my_application.apk

The command above, with the -certs option added, will show you the “CN=” line that describes who created the key.

Note: If you see “CN=Android Debug”, this means the APK was signed with the debug key generated by the Android SDK. If you intend to release your application, you must sign it with your private key instead of the debug key.

For more information about Jarsigner, see the documentation at http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html

4. Align the final APK package

Once you have signed the APK with your private key, run zipalign on the file. This tool ensures that all uncompressed data starts with a particular byte alignment, relative to the start of the file. Ensuring alignment at 4-byte boundaries provides a performance optimization when installed on a device. When aligned, the Android system is able to read files with mmap(), even if they contain binary data with alignment restrictions, rather than copying all of the data from the package. The benefit is a reduction in the amount of RAM consumed by the running application.

The zipalign tool is provided with the Android SDK, inside the tools/ directory. To align your signed APK, execute:

$ zipalign -v 4 your_project_name-unaligned.apk your_project_name.apk

The -v flag turns on verbose output (optional). 4 is the byte-alignment (don’t use anything other than 4). The first file argument is your signed .apk file (the input) and the second file is the destination .apk file (the output). If you’re overriding an existing APK, add the -f flag.

Caution: Your input APK must be signed with your private key before you optimize the package with zipalign. If you sign it after using zipalign, it will undo the alignment.

For more information, read about the zipalign tool.

Compile and sign with Eclipse ADT

If you are using Eclipse with the ADT plugin, you can use the Export Wizard to export a signed APK (and even create a new keystore, if necessary). The Export Wizard performs all the interaction with the Keytool and Jarsigner for you, which allows you to sign the package using a GUI instead of performing the manual procedures to compile, sign, and align, as discussed above. Once the wizard has compiled and signed your package, it will also perfom package alignment with zipalign. Because the Export Wizard uses both Keytool and Jarsigner, you should ensure that they are accessible on your computer, as described above in the Basic Setup for Signing.

To create a signed and aligned APK in Eclipse:

  1. Select the project in the Package Explorer and select File > Export.
  2. Open the Android folder, select Export Android Application, and click Next.The Export Android Application wizard now starts, which will guide you through the process of signing your application, including steps for selecting the private key with which to sign the APK (or creating a new keystore and private key).
  3. Complete the Export Wizard and your application will be compiled, signed, aligned, and ready for distribution.

Utiliza una  Private Key segura

Maintaining the security of your private key is of critical importance, both to you and to the user. If you allow someone to use your key, or if you leave your keystore and passwords in an unsecured location such that a third-party could find and use them, your authoring identity and the trust of the user are compromised.

If a third party should manage to take your key without your knowledge or permission, that person could sign and distribute applications that maliciously replace your authentic applications or corrupt them. Such a person could also sign and distribute applications under your identity that attack other applications or the system itself, or corrupt or steal user data.

Your reputation as a developer entity depends on your securing your private key properly, at all times, until the key is expired. Here are some tips for keeping your key secure:

  • Select strong passwords for the keystore and key.
  • When you generate your key with Keytool, do not supply the -storepass and -keypass options at the command line. If you do so, your passwords will be available in your shell history, which any user on your computer could access.
  • Similarly, when signing your applications with Jarsigner, do not supply the -storepass and -keypass options at the command line.
  • Do not give or lend anyone your private key, and do not let unauthorized persons know your keystore and key passwords.

In general, if you follow common-sense precautions when generating, using, and storing your key, it will remain secure.

Android: preparando una release

Antes de distribuir tu aplicación Android a usuarios de la red, necesitas prepararla para release. El proceso de preparación es una tarea requerida por todos los desarrolladores de apps Android y es el primer paso en el proceso de publicación (ver figura 1)

Cuando preparas tu aplicación para release, debes configurar, construir y probar un versión release de tu aplicación. Las tareas de configuración son simples, incluyendo un limpiado básico del código y modificaciones del código que ayudan a optimizar tu aplicación.

El proceso de compilación es similar al proceso de compilación cuando estás desarrollando y puede ser hecho utilizando las herramientas del JDK y del Android SDK.

Las tareas de pruebas sirven como un chequeo final, asegurandote que tu aplicación realiza lo esperado en condiciones reales.

Cuando has acabado de preparar tu aplicación para release entonces tienes un .apk firmado , que puedes distribuir directamente a usuarios o distribuit a través de un mercado de aplicaciones como Google Play.

En este tuto resumimos las principales tareas que necesitas realizar para preparar tu aplicación para release. Las tareas que son descritas en este documento se aplican a todas las aplicaciones Android independientemente de como ellas son distribuidas al usuario. Si estás sacando tu aplicación a través de Google Play, debes leer  Publishing on Google Play para estar seguros de que cumple todos los requerimientos de Google Play.

Nota: Como una buena práctica, tu aplicación debe cumplir todos los criterios de funcionalidad, rendimiento, y estabilidad antes de realizar las tareas subrayadas en este documento.

Shows how the preparation process fits into the development process

Figure 1. Preparing for release is a required development task and is the first step in the publishing process.

Introduction

Para sacar una release de tu aplicación a los usuarios necesitas crear un paquete release-ready que los usuarios puedan instalar y ejecutar en sus dispositivos Android. El paquete release-ready contiene los mismos componentes que el fichero .apk de la fase de debug- codigo fuente compilado, recursos, fichero de manifest, etc – y es compilado por las mismas herramientas de build. Sin embargo, a diferencia del fichero .apk, el .apk release ready está firmado con tu propio certificado y es optimizado con la herramienta zipalign.

Shows the five tasks you perform to prepare your app for release

Figure 2. Se realizan cinco tareas básicas para preparar tu aplicación para release.

Las tareas de firmado y optimización van generalmente juntas si estas compilando tu aplicación con Eclipse y el plugin ADT o con el script de Ant (incluido con el Android SDK). Por ejemplo, puedes utilizar el Eclipse Export Wizard para compilar, firmar, y optimizar tu aplicación todo de una vez. Puedes también configurar el script de Ant para hacer lo mismo si compilas desde la linea de comando.

Para preparar tu aplicación para una release tienes que realizar 5 tareas principales (ver figura 2).Cada una de estas tareas pueden incluir una o más subtareas más pequeñas dependiendo de cómo estas publicando tu app. Por ejemplo, si se está publicando tu app a través de Google Play puedes querer añadir reglas especiales de filtrado a tu manifest mientras preparas la release. De forma similar, conocer las reglas de publicación de Google Play puede que tengas que hacer capturas de pantalla y algún texto promocional en el proceso de recogida de materiales para la release

Generalmente las tareas listadas en la figura 2 después de que has depurado y testeado  concienzudamente tu app. El Android SDK contiene varias herramientas que te ayudan a probar y depurar las Android apps. Para más info ver the Debugging and Testing sections in the Dev Guide.

Recopilando material y recursos

Para empezar a preparar tu aplicación para una release necesitas recopilar varios elementos de soporte. Como mínimo esto incluye unas claves criptográficas para firmar tu app y un icono de aplicación. Podrías también incluir un licencia de usuario final.

Claves criptográficas

El sistema Android requiere que todas las aplicaciones instaladas sean firmadas digitalmente con un certificado cuyo propietario sea el programador de la app (es decir, un certificado que contiene la clave privada del programador). El sistema Android utiliza el certificado como un medio de identificar al autor de una app y establecer relaciones de confianza entre las apps. El certificado que uses para firmar no necesita estar firmado por una autoridad certificadora , el sistema Android te permite firmar tus apps con certificados auto-firmados. Par aprender más sobre requisitos de certificados ver Obtain a suitable private key.

Importante: Tu app debe estar firmada con una clave criptográfica cuyo periodo de validez finaliza el 22 de Octubre de 2033

Podrías además tener que conseguir otras release keys en el caso de que tu app acceda a un servicio o utilice una third-party library las cuales requiere que utilices un key basada en tu provate key. Por ejemplo , si tu app utiliza la clase MapView , la cual es parte de la Google Maps external library, necesitas registrsr tu app con el servicio de Google Maps y obtener una Maps API key. Para más info sobre esto: Obtaining a Maps API key.

Icono de aplicación

Asegurate que tienes un icono de app y que este cumple con las recomendaciones de icon guidelines.El icono de tu app ayuda a los usuarios a identificar tu app en su pantalla de Home y en la Launcher window. También aparecerá en Manage Applications, My Downloads, y en más sitios.Además , publicar en servicios tales como Google Play muestra  tu icono a los usuarios.

Nota: Si estas publicando tu app en Google Paly, necesitarás crear una versión de alta resolución de tu icono. Ver Graphic Assets for your Application para más info.

Licencia de Usuario final (End-user License Agreement)

Considera redactar una End User License Agreement (EULA) para tu app. Una EULA puede ayudarte a proteger tu persona , organización , y propiedad intelectual , y recomendamos que tengas una para tu app.

Otros materiales

Podrías también preparar material de marketing y promocional para publicitar tu app. Por ejemplo , si estás publicnado tu app en Google Play necesitrás preparar algún texto promocional y necesitarás crear pantallazos de tu app. Para más info: Graphic Assets for your Application

Configurar tu app para subir una release

Después de recopilar todo el material de apoyo , puedes empezar a configurar tu app para subir una release. Esta sección te proporciona un resumen de los cambios de configuración que recomendamos que hagas a tu código fuente, ficheros de recursos, y al archivo manifest antes de subir una release de tu app. Aunque la mayoría de los cambios de configuración listados en esta sección son opcionales, consideralos buenas práticas de programación y animamos a que las implementes. En algunos casos, puede que hayas aplicado estos cambios de configuración como parte de tu proceso de desarrollo.

Elegir un buen nombre de paquete

Asegurate que elijes un nombre de paquete que se ajuste a lo que va a ser la vida de tu app. No puedes cambiar el nombre del paquete despuñes de distribuir tu app a los usuarios. Puedes configurar este valor en el manifest de tu app. Para más info ver package attribute documentation.

Desactiva logging and debugging

Asegurate que desactivas las opciones de logging y debugging antes de compilar tu app para release. Puedes desactivar el logging eliminando las llamadas a los métodos de Log en tu código fuente. Puedes desabilitar el debugging borrando el atributo  android:debuggable del <application> tag en el fichero manifest. Además, elimina cualquier fichero de log o ficheros estáticos de pruebas que hayas creado dentro de tu proyecto.

Además , debrías eliminar todas las Debug tracing calls que has añadido a tu código, tales como startMethodTracing() and stopMethodTracing() method calls.

Limpia los directorios de tu proyecto

Limpia tu proyecto y asegurate que está conforme con la estructura de directorio descrita en  Android Projects (es la que te crea el Eclipse cuando haces New Android Project). Dejar ficheros huérfanos en tu proyecto puede hacer que no compile tu app y se provoquen comportamientos inesperados. Como mínimo debes hacer las siguientes tareas de limpieza:

  • Revisa los contenidos de tus carpetas jni/lib/, and src/ directories. The jni/ directory should contain only source files associated with the Android NDK, such as .c.cpp.h, and.mk files. The lib/ directory should contain only third-party library files or private library files, including prebuilt shared and static libraries (for example, .so files). The src/directory should contain only the source files for your application (.java and .aidl files). The src/ directory should not contain any .jar files.
  • Comprueba que no tengas ficheros privados o ficheros propietarios que tu aplicación no utilice y eliminalos. For example, look in your project’s res/ directory for old drawable files, layout files, and values files that you are no longer using and delete them.
  • Check your lib/ directory for test libraries and remove them if they are no longer being used by your application.
  • Review the contents of your assets/ directory and your res/raw/ directory for raw asset files and static files that you need to update or remove prior to release.

Revisión y actualización de la configuración de tu Manifest

Verifica que los siguientes elementos del manifest están correctamente configurados:

  • <uses-permission> element . You should specify only those permissions that are relevant and required for your application.
  • android:icon and android:label attributes You must specify values for these attributes, which are located in the <application> element.
  • android:versionCode and android:versionName attributes.We recommend that you specify values for these attributes, which are located in the <manifest> element. For more information see Versioning your Application.

There are several additional manifest elements that you can set if you are releasing your application on Google Play. For example, the android:minSdkVersion andandroid:targetSdkVersion attributes, which are located in the <uses-sdk> element. For more information about these and other Google Play settings, see Filters on Google Play.

Ten en cuenta cuestiones de compatibilidad

Android provides several tools and techniques to make your application compatible with a wide range of devices. To make your application available to the largest number of users, consider doing the following:

  • Add support for multiple screen configurations.Make sure you meet the best practices for supporting multiple screens. By supporting multiple screen configurations you can create an application that functions properly and looks good on any of the screen sizes supported by Android.
  • Optimize your application for Android 3.0 devices.If your application is designed for devices older than Android 3.0, make it compatible with Android 3.0 devices by following the guidelines and best practices described in Optimizing Apps for Android 3.0 .
  • Consider using the Support Library.If your application is designed for devices running Android 3.x, make your application compatible with older versions of Android by adding the Support Library to your application project. The Support Library provides static support libraries that you can add to your Android application, which enables you to use APIs that are either not available on older platform versions or use utility APIs that are not part of the framework APIs.

Actualiaza URLs de servidores y servicios

If your application accesses remote servers or services, make sure you are using the production URL or path for the server or service and not a test URL or path.

Licencia de Implementación (si estás publicando en Google Play)

Si estas publicando una aplicación pagada a trvés de Google Play, considera añadir soporte para Google Play Licensing. Con esta licencia puedes controlar el acceso a tu app basandose en si el usuario actual la hax comprado. Utilizar Google Play Licensing es opcional incluso si estás publicando a través de Google Play.For more information about Google Play Licensing Service and how to use it in your application, see Application Licensing.

Compilar tu app para release

After you finish configuring your application you can build it into a release-ready .apk fle that is signed and optimized. The JDK includes the tools for signing the .apk file (Keytool and Jarsigner); the Android SDK includes the tools for compiling and optimizing the .apk file. If you are using Eclipse with the ADT plugin or you are using the Ant build script from the command line, you can automate the entire build process.

Building with Eclipse

You can use the Eclipse Export Wizard to build a release-ready .apk file that is signed with your private key and optimized. To learn how to run the Export Wizard, see Compile and sign with Eclipse ADT. The Export Wizard compiles your application for release, signs your application with your private key, and optimizes your application with the zipalign tool. The Export Wizard should run successfully if you have run or debugged your application from Eclipse and you have no errors in your application (see Building and Running from Eclipse with ADT for more information.

The Export Wizard assumes that you have a certificate and private key suitable for signing your application. If you do not have a suitable certificate and private key, the Export Wizard will help you generate one (see Signing Your Applications for more information about the signing process and signing guidelines.

Building with Ant

You can use the Ant build script (included in the Android SDK) to build a release-ready .apk file that is signed with your private key and optimized. To learn how to do this, see Building in Release Mode. This build method assumes you have a certificate and private key suitable for signing your application. If you do not have a suitable certificate and private key, the Export Wizard will help you generate one (see Signing Your Applications for more information about the signing process and signing guidelines.

Preparing External Servers and Resources

If your application relies on a remote server, make sure the server is secure and that it is configured for production use. This is particularly important if you are implementing in-app billing in your application and you are performing the signature verification step on a remote server.

Also, if your application fetches content from a remote server or a real-time service (such as a content feed), be sure the content you are providing is up to date and production-ready.

Testing Your Application for Release

Testing the release version of your application helps ensure that your application runs properly under realistic device and network conditions. Ideally, you should test your application on at least one handset-sized device and one tablet-sized device to verify that your user interface elements are sized correctly and that your application’s performance and battery efficiency are acceptable.

As a starting point for testing, see What to Test. This article provides a summary of common Android situations that you should consider when you are testing. When you are done testing and you are satisfied that the release version of your application behaves correctly, you can release your application to users. For more information, see Releasing Your Application to Users. If you are publishing your application on Google Play, see Publishing on Google Play.

Publicando en Google Play (antiguo market)

Uno de las formas más efectivas de llevar tu aplicación a los dispositivos de los usuarios es publicarla en el mercado de aplicaciones que supone Google Play. Publicar en Google Play es un proceso simple que puedes hacer en unos pocos pasos – registro, configuración, upload y publicación. El registro dura solo unos minutos y necesita ser hecho sólo una vez. Los pasos de configuración y publicación pueden ser hechos a través de la Google Play Android Developer Console después de registrarte como un Google Play Developer.

Para empezar a publicar en Google Play, lo primer es leer este tuto y entonces ir a Google Play Android Developer Console y registrarte como un desarrollador de Google Play.

Sobre Google Play

Google Play es una plataforma segura de publicación que te ayuda publicitar, vender, y distribuir tus aplicaciones Android a usuarios en todo el planeta. Cuando metes una versión de tu aplicación a través de Google Play, tienes acceso a una suite de herramientas de programador que te permiten analizar tus ventas, identificar las tendencias del mercado, y controlar a quien han sido distribuidas tus apps. También tienes acceso a varias características de “recuperación de la inversión” tales como in-app billingapplication licensing.

Antes de que puedas publicar en Google Play, necesitas registrarte como Google Play developer.Durante el proceso de registro necesitarás crear un perfil de desarrollador, pagar una cuota, y estar de acuerdo con las Google Play Developer Distribution Agreement.Después de registrarte puedas acceder a la Developer Console, donde puedes subir tus aplicaciones, configurar las opciones de publicación y monitorizar los datos de publicación.Si quieres vender tus aplicaciones o utilizar la función de in-app billing , necesitarás configurar una cuenta de Google Checkout merchant . Para más info sobre el proceso de registro:Developer Registration.

Proceso de Registro de Desarrollador

Debes registrarte para distribuir tus productos a través de Google Play. Hay un tarifa de $25. Cobramos esto para animar a que los productos sean de alta calidad en Google Play (es decir para eliminar el spam).

Los siguientes articulos te ayudan a resolver cualquier problema que  tengas en el proceso de registro:

Vendiendo apps
Si estas interesado en vender tus apps con un precio, ncesitas estar registrado en el Google Checkout Merchant también. Para hacer esto desde el Google Play site:

  1. Log into your Google Play Android Developer Console at https://play.google.com/apps/publish/
  2. Click on the “Edit profile” link.
  3. Select “Setup a Merchant Account at Google Checkout.”

This will take you to the Google Checkout site to sign up as a Merchant; you’ll need to have information about your business handy to complete this step. Learn more about the requirements to be a Google Checkout Merchant.

Publicar Apps en Google Play

Publicar tu aplicación en Google Play es un proceso simple que incluye tres tareas básicas (ver figura 1):

  • Crear varios recursos gráficos que acompañen tu app en Google Play.
  • Utilizar la Google Play Developer Console para configurar opciones de publicación, especificar detalles de listado, y hacer el upload de tu app e de los recursos gráficos a Google Play.
  • Revisar los settings de publicación y cambiar el estado de release de tu app de Unpublished a Published.

Shows the three steps that are required to publish on Google Play

Figure 1. Para publicar en Google Play primero debes preparar tu app para release (ver  prepare your app for release ) y entonces realizar las tres simples tareas de la imagen.

Importante: Cuando preparas tu aplicación para release debes configurarla para release y build en modo release. Al compilar en modo release se firma el apk de tu aplicación con tu private release key. No puedes publicar una aplicación en Google Play a menos que esté firmada con tu propia release key.

Preparar el material promocional

Para aprovechar las capacidades de marketing y publicitarias de Google Play, necesitas crear varios imágenes que acompañen tu app en Google Play, tales como capturas de pantallas, videos, gráficos promocionales , y texto promocional. Cómo mínimo se deben proporcionar dos capturas de tu aplicación y un icono de aplicación de alta resolución. Las capturas son mostradas en la página de detalle de tu aplicación en Google Play, y el icono de alta resolución es mostrado en varios sitios a través de Google Play. El icono de alta resolución no reemplaza el icono de launcher de tu aplicación, mas que eso, sirve como un icono de suplemento y debe parecer parecido al icono launcher. El video promocional, los gráficos, y el texto son opcionales, aunque son altamente recomendables. Para más información sobre los recursos de imágenes que acompañan tu app, ver  Graphic Assets for your Application.

Configurando opciones y subiendo recursos

Google Play te permite dirigir tu aplicación a un ampli grupo de usuarios y dispositivos.Para llegar a estos usuarios puedes utilizar la Developer Console para configurar varias opciones de publicación y detalles de listado para tu app. Por ejemplo, puedes elegir los paises a los que te quieres dirigir, los idiomas que quieren que lo usen, y el precio que quieres poner para cada país. Puedes también configurar detalles de listado tales como el tipo de aplicación, la categoría y el content rating. Además, si quieres vender productos dentro de tu app utilizando la característica de app-billing, puedes utilizar la Developer Console para crear una lista de productos y controlar que productos están disponibles para comprar en tu app.

Cuando se acaba de configurar las opciones de publicación y detalles de listado, puedes subir tus recursos y tu aplicación a Google Play. Puedes subir tu aplicación en un modo de borrador (sin publicar), que te permite hacer el testeo final antes de publicar la versión definitiva.

Para saber más sobre las opciones de publicación de Google Play, se pueden ver los siguientes recursos:

Publicando tu aplicación

Cuando estás de acuerdo con las opciones de publicación y la aplicación subida esta lista para ser publicada, puedes simplemente clickar ‘Publish’ en el Developer Console para terminar de hacer tu app disponible alrededor de todo el mundo. Ten en cuenta, que puede llevar varias horas para que tu app aparezca en Google Play desde que pulsas Publish en la Developer Console.

Controlando la distribución hacia los dispositivos

Si tu app se dirige a diferentes configuraciones de dispositivos, puedes controlar que dispositivos Android tienen acceso a tu app en Google Play utilizando filtros Google Play. El filtrado compara configuraciones de dispositivos que tu declaras en el manifest de tu app con la configuración definida en cada dispositivo. Por ejemplo, su declaras el filtro de camara en tu manifest, solo aquellos dispositivos que tengan una cámara verán tu app en Google Play. Los filtros deben estar configurados en el manifest de tu app cuando prepares tu app para release –> preparing your app for release (es decir, antes de hacer upload de tu app en Google Play). Para más info, ver  Filters on Google Play.

También puedes utilizar las múltiples características APK para distribuir diferentes ficheros .apk bajo la misma aplicación y el mismo nombre de paquete; sin embargo, deberías utilizar este opción somo como último recurso. Las aplicaciones de Android se ejecutan casi siempre con un solo APK, by supplying alternative resources for different configurations (for example, different layouts for different screen sizes) and the Android system selects the appropriate resources for the device at runtime. In a few cases, however, a single APK is unable to support all device configurations, because alternative resources make the APK file too big (greater than 50MB) or other technical challenges prevent a single APK from working on all devices. Although we encourage you to develop and publish a single APK that supports as many device configurations as possible, doing so is sometimes not possible. To help you publish your application for as many devices as possible, Google Play allows you to publish multiple APKs under the same application listing. Google Play then supplies each APK to the appropriate devices based on configuration support you’ve declared in the manifest file of each APK. To use this feature, you need to build your separate .apk files when you are preparing your app for release (that is, before you upload your app to Google Play). For more information, see Multiple APK Support.

Publicando actualizaciones en Google Play

En cualquier momento después de publicar una aplicación en Google Play, se puede hacer upload y publicación de una actualización de la misma aplicación.Cuando publicas una actualización, los usuarios que ya tienen instalada tu app podrían recibir una notificación de que una actualización está disponible.

Before uploading the updated application, be sure that you have incremented the android:versionCode and android:versionName attributes in the <manifest> element of the manifest file. Also, the package name must be the same as the existing version and the .apk file must be signed with the same private key. If the package name and signing certificate do not match those of the existing version, Google Play will consider it a new application, publish it as such, and will not offer it to existing users as an update.

If you plan to publish your application on Google Play, you must make sure that it meets the requirements listed below, which are enforced by Google Play when you upload the application.

Utilizar el servicio de Licencias de Google Play

Google Play ofrece un servicio de licencia que te permite reforzar las políticas de licencia para aplicaciones de pago que tu publicas a través de Google Play. Con Google Play Licensing, tus aplicaciones pueden consultar Google Play en tiempo de ejecución para obtener el estado de licencia de tu usuarios actual, entonces permitir o denegar el uso de la aplicación como propietario. Utilizar este servicio, puedes aplicar una política de licencia flexible sobre una base de aplicación por aplicación- es decir cada aplicación puede configurar su estado de licencia en la forma que considere más apropiada.

Cualquier aplicación que tu publiques a través de Goolgle Play puedes usar el Google Play Licensing Service. El servicio no utiliza APIs dedicados, asi que puedes utilizar este servicio con un API de nivel mínimo (3 o superior).

Para más info  Application Licensing.

Utilizar el Google Play In-app Billing

Google Play In-app Billing es un servicio de Google Play que te permite vender contenido digital en tus apps. Puedes utilizar el servicio para vender una amplia variedad de contenido, incluyendo contenido escargable como musica o fotos, y contenido virtual como niveles de un juego o pócimas.

is a Google Play service that lets you sell digital content in your applications. You can use the service to sell a wide range of content, including downloadable content such as media files or photos, and virtual content such as game levels or potions.

When you use Google Play’s in-app billing service to sell an item, Google Play handles all billing details so your application never has to directly process any financial transactions. Google Play uses the same checkout service that is used for application purchases, so your users experience a consistent and familiar purchase flow (see figure 1). Also, the transaction fee for in-app purchases is the same as the transaction fee for application purchases (30%).

Any application that you publish through Google Play can implement in-app billing. No special account or registration is required other than a Google Play publisher account and a Google Checkout Merchant account. Also, because the service uses no dedicated framework APIs, you can add in-app billing to any application that uses a minimum API level of 4 or higher.

To help you integrate in-app billing into your application, the Android SDK provides a sample application that demonstrates a simple implementation of in-app billing. The sample application contains examples of billing-related classes you can use to implement in-app billing in your application. It also contains examples of the database, user interface, and business logic you might use to implement in-app billing. For more information about the in-app billing feature, see the In-app Billing documentation.

Linking to Your Apps on Google Play

To help users discover your published applications, you can use two special Google Play URIs that direct users to your application’s details page or perform a search for all of your published applications on Google Play. You can use these URIs to create a button in your application or a link on a web page that:

  • Opens your application’s details page in the Google Play application or web site.
  • Searches for all your published applications in the Google Play application or web site.

You can launch the Google Play application or web site in the following ways:

  • Initiate an Intent from your application that launches the Google Play application on the user’s device.
  • Provide a link on a web page that opens the Google Play web site (but will also open the Google Play application if clicked from a device).

In both cases, whether you want to initiate the action from your application or from a web page, the URIs are quite similar. The only difference is the URI prefix.

To open the Google Play application from your application, the prefix for the intent’s data URI is:

market://

To open Google Play store from your web site, the prefix for the link URI is:

http://play.google.com/store/

The following sections describe how to create a complete URI for each action.

Note: If you create a link to open Google Play from your web site and the user selects it from an Android-powered device, the device’s Google Play application will resolve the link so the user can use the Google Play application on the device instead of opening the web site. As such, you should always usehttp://play.google.com/store/apps/... URIs when creating a link on a web page. When pointing to your apps from within your Android app, use the market:// URIs in an intent, so that the Google Play application always opens.

Opening an app’s details page

As described above, you can open the details page for a specific application either on the Google Play application or the Google Play web site. The details page allows the user to see the application description, screenshots, reviews and more, and choose to install it.

The format for the URI that opens the details page is:

<URI_prefix>apps/details?id=<package_name>

The <package_name> is a placeholder for the target application’s fully-qualified package name, as declared in the package attribute of the <manifest> element.

For example: http://play.google.com/store/apps/details?id=com.example.myapp

Opening the app details page from your Android app

To open the Google Play details page from your application, create an intent with the ACTION_VIEW action and include a data URI in this format:

market://details?id=<package_name>

For example, here’s how you can create an intent and open an application’s details page in Google Play:

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("market://details?id=com.example.android"));
startActivity(intent);

This will open the Google Play application on the device to view the com.example.android application.

Opening the app details page from a web site

To open the details page from your web site, create a link with a URI in this format:

http://play.google.com/store/apps/details?id=<package_name>

For example, here’s a link that opens an application’s details page on Google Play:

<a href="http://play.google.com/store/apps/details?id=com.example.android">App Link</a>

When clicked from a desktop web browser, this opens the Google Play web site to view the com.example.android application. When clicked from an Android-powered device, users are given the option to use either their web browser or the Google Play application to view the application.

Performing a search

To initiate a search on Google Play, the format for the URI is:

<URI_prefix>search?q=<query>

The <query> is a placeholder for the search query to execute in Google Play. The query can be a raw text string or you can include a parameter that performs a search based on the publisher name:

  • To perform a raw text search, append the query string:<URI_prefix>search?q=<search_query>
  • To search based on the publisher name, use the pub: parameter in the query, followed by the publisher name:<URI_prefix>search?q=pub:<publisher_name>You can use this type of search to show all of your published applications.

Searching from your Android app

To initiate a search on Google Play from your application, create an intent with the ACTION_VIEW action and include a data URI in this format:

market://search?q=<query>

The query may include the pub: parameter described above.

For example, here’s how you can initiate a search in the Google Play application, based on the publisher name:

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("market://search?q=pub:Your Publisher Name"));
startActivity(intent);

This opens the Google Play application to perform the search. The search result shows all applications published by the publisher that are compatible with the current device.

Searching from a web site

To initiate a search on Google Play from your web site, create a link with a URI in this format:

http://play.google.com/store/search?q=<query>

The query may include the pub: parameter described above.

For example, here’s a link that initiates a search on Google Play, based on the publisher name:

<a href="http://play.google.com/store/search?q=pub:Your Publisher Name">Search Link</a>

When clicked from a desktop web browser, this opens the Google Play web site and performs the search. When clicked from an Android-powered device, users are given the option to use either their web browser or the Google Play application to perform the search.

Build a Google Play button

Use the following form to create a button for your web site that takes users to your application on Google Play. Input either your application’s package name or your publisher name and the button will take users to Google Play to either view your application’s information or view a list of your published apps. If users click the button while on an Android-powered device, the Google Play application will respond to show users your application(s).

This form offers two styles of the official brand badge each at recommended sizes. You can pick between either “Get it on Google Play” or “Android app on Google Play.” You should not modify the badge images in any way. For more usage guidelines, see the Android Brand Guidelines.

 

or 

 

 

Summary of URI formats

The table below provides a summary of the URIs currently supported by the Google Play (both on the web and in the Android application), as discussed in the previous sections.

For this result Use this URI in a web page link Or this URI in an ACTION_VIEW intent
Display the details screen for a specific application http://play.google.com/store/apps/details?id=<package_name> market://details?id=<package_name>
Search for applications using a general string query. http://play.google.com/store/search?q=<query> market://search?q=<query>
Search for applications by publisher name http://play.google.com/store/search?q=pub:<publisher_name> market://search?q=pub:<publisher_name>

Android Progress Bar

[Fuente: http://developer.android.com/reference/android/widget/ProgressBar.html]

java.lang.Object
android.view.View
android.widget.ProgressBar
Known Direct Subclasses

Known Indirect Subclasses

Introducción

Esta clase muestra un indicador visual de progreso de alguna operación pesada en tiempo. Muestra una barra al usuario representando cuanto lleva la realización de la operación: la aplicación puede cambiar la cantidad de progreso (modificando la longitud de la barra) según el avance de la acción. Hay también un elemento visual que se puede mostrar en la barra de progreso que es útil para mostrar un progreso indeterminada, como por ejemplo el nivel de buffer cuando se esta reproduciendo un streaming.

La barra de progreso puede ser también indeterminada. En modo intdeterminado, la barra de progreso muestra una animación cíclica sin indicación de progreso. Este modo se utiliza en las aplicaciones donde no se sabe la duración de la tarea. La barra de progreso indeterminada puede ser una spinning wheel o una barra horizontal.

El siguiente código de ejemplo muestra como se puede utilizar una barra de progreso para actualizar el interfaz de usuario  y para notificar al usuario del progreso:

 public class MyActivity extends Activity {

     private static final int PROGRESS = 0x1;

     private ProgressBar mProgress;
     private int mProgressStatus = 0;

     private Handler mHandler = new Handler();

     protected void onCreate(Bundle icicle) {
         super.onCreate(icicle);

         setContentView(R.layout.progressbar_activity);

         mProgress = (ProgressBar) findViewById(R.id.progress_bar);

         // Start lengthy operation in a background thread
         new Thread(new Runnable() {
             public void run() {
                 while (mProgressStatus < 100) {
                     mProgressStatus = doWork();

                     // Update the progress bar
                     mHandler.post(new Runnable() {
                         public void run() {
                             mProgress.setProgress(mProgressStatus);
                         }
                     });
                 }
             }
         }).start();
     }
 }

Para añadir una barra de progreso a un fichero de layout, utilizamos el elemento  <ProgressBar> . Por defecto , la barra de progreso es una spinning wheel (un indicador indeterminado). Para cambiar a una barra horizontal, aplica el estilo Widget.ProgressBar.Horizontal como en el siguiente ejemplo:

 <ProgressBar
     style="@android:style/Widget.ProgressBar.Horizontal"
     ... />

Si utilizas la barra de progreso para mostrar un progreso medido, entonces es mejor utilizar la barra horizontal. Puedes incrementar el progreso conincrementProgressBy() o con setProgress().Por defecto, la barra de progreso esta completa cuando llega a 100. Si necesario, puedes ajustar el valor máximo (el valor de cuando esta completa) utilizando el atributo android:max .

Otro estilo común para aplicar a la barra de progreso es  Widget.ProgressBar.Small, que muestra una versión pequeña de la spinning wheel – util cuando se está esperando que cargue cierto contenido. Por ejemplo, puedes insertar esta clase de barra de progreso en el layout por defecto para una vista que será poblado por cierto contenido cuando sea recuperado de internet – la spinning wheel aparece inmediatamente y cuando tu aplicación recibe el contenido, reemplaza la progress bar por el contendio descargado. Por ejemplo:

 <LinearLayout
     android:orientation="horizontal"
     ... >
     <ProgressBar
         android:layout_width="wrap_content"
         android:layout_height="wrap_content"
         style="@android:style/Widget.ProgressBar.Small"
         android:layout_marginRight="5dp" />
     <TextView
         android:layout_width="wrap_content"
         android:layout_height="wrap_content"
         android:text="@string/loading" />
 </LinearLayout>

Other progress bar styles provided by the system include:

10 Consejos para diseñar una app de Android

[Fuente: http://phandroid.com/2011/05/11/10-tips-for-android-ui-design/]

En estos dias muchos programadores están saltando a programar para el mundo de los dispositivos móviles en busca de la fama y la fortuna – y están en lo cierto – no hay mercado que esté creciendo más rápidamente que éste.

Tarde o temprano llega un momento en el ciclo de desarrollo donde la app esta casi hecha. Ahora que? Y oimos las dos palabras mágicas “User Experience”. Bien , pues el mundo móvil tiene sus propios patrones y reglas de las cuales tenemos que estar atentos. aqui presentamos 10 consejos que mejorarán tu aplicación móvil para conseguir una buena aceptación y muchas descargas de la comunidad de usuarios de apps de moviles.

1. La experiencia de las acciones iniciales (First launch experience)

Las buenas web y apps de mobile tiene bastantes similitudes. Ambas necesitan enganchar al usuario o al visitante instantaneamente. Si fallan, se van a la competencia con un par de clicks. La mayoria de los usuarios nopierden tiempo averiguando como utilizar tu app o leer un manual complicado.

En la primera pantalla, todo el mundo tiene las mismas tres preguntas en la cabeza:

  1. Donde estoy?
  2. Qué puedo hacer?
  3. Que más puedo hacer?

Intenta que estas respuestas se contesten instantaneamente (en los primeros dos segundos). Si lo consigues entonces profundizarán en tu app.

Gowalla tiene un primera pantalla atractiva. Un pasaporte que se abre lentamente, dando acceso instantaneo a tu información personal, sugerencias instantaneas y  más acciones y notificaciones.


2. Cada entrada es valiosa

Piensa por un momento sobre cómo realmente utilizas tu dispositivo móvil: el teléfono de un programador esta seguro sentado en su dock en la mesa, conectado a un PC con un gran teclado. Ahora piensa sobre como el resto del mundo está utilizando el smartphone: caminando con él por una calle llena de gente con un café en una mano y el móvil en la otra, intentando averiguar cuál es el resultado de su equipo, entre la ultima reunión y la siguiente.

La mayor parte del tiempo la gente sólo tiene el dedo gordo para navegar por tu app. Olvida el multitouch y métodos de entrada complejos similares – scroll , flip y touch son tus amigos. Deja que la gente navegue de pantalla a pantalla y de información a información rápidamente , sin necesidad de remangarse los brazos. Y permiteles hacerlo rápido. Cada entrada (input) cuenta.

Puedes añadir una nueva tarea a Taskos con solo un touch (y tecleando algo, obviamente). Justo después se pueden configurar muchos settings , pero es una opción.

3. Contraste

Mientras tu entorno de programación puede ser una pantalla bien grande en una habitación con suficiente sombre, el lugar donde tus usuarios utilizaran tu app puede no serlo. Necesitamos utilizar nuestros móviles muy frecuentemente en dias soleados. Esto tiene una gran influencia en cómo vemos la pantalla y cómo el interfaz debe ser diseñado. Los detalles se pierden , los colores no puedes ser distinguidos uno del otro. Algunos elementos completamente desaparecen debido a los reflejos.

Esto no significa que solo puedes hacer tu diseño en blanco y negro y olvidarte de hacer un interfaz bonito. Solo quiere decir que los elementos importantes deben tener suficiente contraste para ser reconocidos en condiciones de luminosidad alta. Si quieres colorear elementos de código, añade una opción de respaldo como etiquetas de texto simple. Y si quieres mejorar la apariencia de tu aplicación con pequeños detalles y bits de información, vas por el buen camino. Solo asegurate que el UI incluso funciona sin aquellos.

Da a tu interfaz un jerarquia clara mostrando las caracteristicas más útiles bien grandes y brillantes. Borra todo lo que no sea importante completamente de tu app.

Aunque hay muchas opciones presentes en la pantalla de SoundHound, la función principal se muestra claramente en la parte de arriba de la interfaz.

4. Que tusu usuarios no esperen

Nadie quiere esperar, especificamente en el mundo móvil. Llevamos nuestros dispositivos en el tren, responder un email rápido en el bus, o vemos el tiempo mientras caminamos por la calle. Hacemos estas pequeñas cosas según vamos a camino a otros sitios, para ganar un poco más de tiempo libre para las cosas que realmente nos gustan hacer. No permitas que la gente de tu app espere por hacer una determinada cosa. Mejora el rendimiento de tu app para conseguir resultados lo más rápido posible.

Ciertamente todo el mundo entenderá que hay acciones que requieren más rendimiento de tu app o que hace falta recuperar algunos datos pesados de la web. Pero nunca dejes que el usuario espere por nada a suceder. Hazle sentir que el trabajo se esta haciendo en el background. Añade estadso de “selected” y “pressed” a tus botones , añade spinners para tiempos de espera cortos y progress bars para los largos, Pero nunca, nunca, enfrentes al usuario a una pantalla negra.

La app de Google  Reader app muestra un pequeño spinner arriba ala derecha cada vez que se esta haciendo loading en el background, asi sabes que debes esperar unos segundos para obtener resultados.

5. No olvides el landscape

Sometimes you just forget that your mobile Android device has more than one basic phone orientation. While most people are comfortable with their apps working only in portrait mode, some really prefer to use their device in landscape mode, especially the ones with physical keyboards. This group of user will probably grow with the widespread adoption of Android tablets.

Don’t make the mistake of thinking of the landscape orientation as a wider view of your lists. Using the device in landscape mode is a totally different userexperience. Now you have two thumbs to interact with the screen. Typing is much easier and you mostly tend to read from left to right, not top to bottom. In fact, if your app is heavy on reading and writing you absolutely need to support a good landscape mode.

Landscape orientation can also feature a totally different experience to the users. You can use the wider layout to display information in a completely alternative way. For example buttons could be moved to a side that were previously sitting at the top of the screen. Maps, charts and graphs can display new pieces of information when shown on a wider scale.

Start to build and improve one screen orientation. Then create the second one. Be aware of the pros and cons of each layout and use them wisely.
The official YouToube app uses two different layouts for the two orientations, that both work perfectly at their respective ratios.

6. El ecosistema de Apps

While you can design the most unique and special app  that might serve a lot of different purposes, it will always be just one step in a chain of actions.

Think about what your smartphone can do out of the box: phone calls, contacts, texting, mails, browser, taking photos and videos, GPS and maps – the list goes on. Use this as an advantage. You don’t have to create all these building blocks on your own. Users are familiar with the standard toolset- don’t try to reinvent the wheel. At the same time this will also spare you a lot of coding work.

Here’s a very short but very common chain of action: Get a call that invites you to a certain location. Check the time. Check the weather. Head out, searching the place with Google Maps. Check in with Foursquare. So where does your app tie in the workflow here?

No user will ever use his mobile device just for your application alone. But if you manage to create a great piece of software, they will incorporate it into their mobile workflow on a daily basis. Give them easy access to further features like sharing or looking up interesting information on the web, and let them jump fluidly between your app and others.


Many apps can hook directly into the Android’s sharing mechanism. Use this to your advantage.

7. Haz tu app única

There are more than 200,000 apps on the Android Market. You might ask yourself how to stand out between all the quite similar offerings. If you set out to build the next boring Sudoku game in black and white or the next note-taking-app based on the official code example, you will have a hard time getting some decent download numbers.

Don’t assume that there’s no room for another great app that is already covered in one way or another. People always prefer different things. There is no Jack of all trades. Some prefer a note-taking-app that can do almost everything. Some need just a simple text editor with syncing capabilities. And there are others that just want a clean UI.

Either way you go, build an app with character. All basic features are already covered by the OS and the core apps. Stand out by creating something that users will prefer to use over the built-in solutions. Think of your app as a small robot living inside your smartphone. It communicates with you,  tells you interesting things and helps you with your daily tasks. Do you want your robot to be smart and professional, or cute and lovely, maybe even cheeky and funny?

Keep that in mind when building a great app from the ground up. People with character enjoy apps that fit their personality. Want to build a photosharing app? Add a paparazzi like theme to it, with badges to earn. Another location service? Strip it down to the most basic features and automate everything. Take a problem with an already well known solution. Now think about, how a slight change of perspective could change the whole application and how users work with it.

And don’t let me get started with good UI design …


Feedly is just another news reader with Google Reader integration, but it uses a magazine like presentation and very clean design to distinguish itself from other readers.

8. Ciñete a las recomendaciones de Google(guidelines) (as long as possible)

While you want to create an unique app, that stands out, you don’t want every piece of your app to be totally special. Google suggests a lot of guidelines for Android app design and development. Get familiar with the guidelines. People have a much harder time to dive into the complexity of a modern smartphone than you think. Don’t make it even harder for them by implementing custom interaction elements all over.

Learning to work with an Android device need a user to get comfortable with touching, typing, swiping, shaking and even pressing hardware buttons from time to time. They need to recognise patterns like input fields, select boxes, modal dialogs and long presses for contextual menus. Do you really want to throw more at them?

Go with simple, straight forward lists. Start your app with a dashboard consisting of big icons for the main functions. Add a header that provides access to the most common feature and let users go back to the start when they get lost. If you can’t improve these metaphors dramatically, don’t change them. People will value consistency within your app and the whole operating system.

Study Google’s interfaces and decisions carefully. Get familiar with the whole experience, and try to create your app with Android’s guidelines in mind. But don’t take this literally – If you can improve certain elements, and you are absolutely sure about that – then for God’s sake, do it!


Frequent actions in the title bar, big simple, icons on the body. Catch Notes works great by sticking to the basics.

9. Guerrilla testing

Let’s face it – all users are different. You can try as hard as you want to, you’ll never satisfy everybody. Even trying to get your app right for the majority of people is very hard.

Don’t get me wrong here. This is no excuse to ship your app without considering the different approaches of how people will use the app. You need different people to test-run your app and iron out at least the most annoying problems and bugs. Big companies spend thousands of dollars on usability experts, that test hundreds of different users in very expensive labs to get their software right.

While this is a great way to improve any app’s UI, it is hardly affordable for most independent and small developers. Don’t let this be an excuse, either. You can do some very cheap and swift guerrilla testing, to massively improve your app and make it more accessible to a larger userbase.

Grab your developer device with the app’s prototype, spend some money on small gifts like buttons or stickers, and head out. Start with colleagues and friends, and progress to strangers you never saw before. Most people will gladly spend a little time with something brand new, as long as you are polite and even provide a small reward for their time.

Let them use your app like you intended to, and watch carefully. Tell them what their goal is, but provide as little help as possible. But don’t let them get stuck either. You’ll figure out your apps pitfalls and bottlenecks in no time.

10. Publicando en el Market

Well, you did it. You’ve built your first app. Congratulations. It feels great, doesn’t it?

Now don’t make the mistakes many do. Sure, you want to get the app out to the masses and hear what they are saying about it. But taking a couple of last steps will give you a much better first launch.

You’re sure you did some proper testing? Different devices, hdpi, mdpi and ldpi? Alright. Let’s take care of the small things.

Google wants you to upload your app to the Market with 4 additional assets:

  • A description of your application’s features
  • The app’s icon in high resolution
  • A small promotional banner that will be displayed on the Android Market
  • And another larger “features” graphic that will go alongside your app on the web-version of the market.

Don’t make the mistake and underestimate one of these additional assets. A well written introduction to your great app coupled with some clean and well designed graphics can make the difference to all your other 500 contenders on the Market. Users will notice the extra mile you took, transcending over to the level of detail and care you put into your application.

If creating some nice and clean graphics or writing some lines of good copy isn’t really your cup of tea, ask a designer and/or writer. The extra money should be well worth your apps success, and it should take only a couple of hours.

If you even want to take your promotion a little further prior to launch, get a fitting Twitter account, create a beautiful landing page and start the buzz. You can’t start marketing too early. Let people get excited. They will spread the word for you long before your app is finally available.


The Android Market online uses the high-resolution version of your app’s icon and the large feature graphic.

About the author

Guenther Beyer is an interface and icon designer with Android-focused experience since 2008. His consulting company – Opoloo – helps Developers maximize their apps’ potential with fresh and polished UI design. They’ve recently launched AndroidIcons.com which allow all developers to instantly improve their apps and games with slick icons for use throughout their interface.”

Android: Google Map View

[Fuente: http://developer.android.com/resources/tutorials/views/hello-mapview.html]

Using the Google Maps library, you can create your own map-viewing Activity. In this tutorial, you’ll create a simple map application in two parts. In Part 1, you’ll create an app that shows a map the user can pan and zoom. In Part 2, you’ll add overlay items that mark points of interest.

This tutorial requires that you have the external Google Maps library installed in your SDK environment. The Maps library is included with the Google APIs add-on, which you can install using the Android SDK and AVD Manager. To learn how, see Adding SDK Components.

After installing the Google APIs add-on in your SDK, set your project properties to use the build target called “Google APIs by Google Inc.”. See the instructions for setting a build target in Creating and Managing Projects in Eclipse or Creating and Managing Projects on the Command Line, as appropriate for your environment.

You will also need to set up a new AVD that uses the same Google APIs deployment target. See Creating and Managing Virtual Devices for more information.

For reference material, see the Google Maps library documentation.

Part 1: Creating a Map Activity

  1. Start a new project named HelloGoogleMaps.
  2. Because the Maps library is not a part of the standard Android library, you must declare it in the Android Manifest. Open the AndroidManifest.xml file and add the following as a child of the <application> element:
    <uses-library android:name="com.google.android.maps" />
  3. You also need access to the Internet in order to retrieve map tiles, so you must also request the INTERNET permission. In the manifest file, add the following as a child of the<manifest> element:
    <uses-permission android:name="android.permission.INTERNET" />
  4. While you’re in the manifest, give the map some more space by getting rid of the title bar with the “NoTitleBar” theme:
    <activity android:name=".HelloGoogleMaps" android:label="@string/app_name"
         android:theme="@android:style/Theme.NoTitleBar">
  5. Open the res/layout/main.xml file and add a single com.google.android.maps.MapView as the root node:
    <?xml version="1.0" encoding="utf-8"?>
    <com.google.android.maps.MapView
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:id="@+id/mapview"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:clickable="true"
        android:apiKey="Your Maps API Key goes here"
    />

    The android:clickable attribute defines whether you want to allow user-interaction with the map. If this is “false” then touching the map does nothing.

    The android:apiKey attribute holds the Maps API Key for your application, which proves your application and signer certificate has been registered with the Maps service. This is required in order to receive the map data, even while you are developing. Registration to the service is free and it only takes a couple minutes to register your certificate and get a Maps API Key.

    Go now to get a key. For instructions, read Obtaining a Maps API Key. For the purpose of this tutorial, you should register with the SDK debug certificate, which will only be valid while your application is signed with the debug key (once you sign with your private key, you will need a new API key). When you get your key, insert it for the value ofandroid:apiKey.

  6. Now open the HelloGoogleMaps.java file. For this Activity, extend MapActivity (instead of android.app.Activity):
    public class HelloGoogleMaps extends MapActivity {

    This is a special sub-class of Activity, provided by the Maps library, which provides important map capabilities.

  7. Inside every MapActivity, the isRouteDisplayed() method is required, so override this method:
    @Override
    protected boolean isRouteDisplayed() {
        return false;
    }

    This method is required for some accounting from the Maps service to see if you’re currently displaying any route information. In this case, you’re not, so return false.

  8. Now add the standard onCreate() callback method to the class:
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }

    This loads the layout file created above. In fact, this is now a workable application that will display map tiles and allow the user to pan around the map. But there’s no ability to zoom. Fortunately, there’s a very simple zoom feature built into the MapView class, which you can summon with setBuiltInZoomControls(boolean). Do this at the end of the onCreate() method:

        MapView mapView = (MapView) findViewById(R.id.mapview);
        mapView.setBuiltInZoomControls(true);
  9. That’s all there is to it. Run the application. (Remember, you must have an AVD configured to use the Google APIs target, or be using a development device that includes the Maps library.)

Part 2: Adding Overlay Items

So, now you have a map, but in many cases you’ll also want to create your own map markers and lay-overs. That’s what you’ll do now. In order to do so, you must implement the ItemizedOverlay class, which can manage a whole set of Overlay (which are the individual items placed on the map).

  1. Create a new Java class named HelloItemizedOverlay that implements ItemizedOverlay.When using Eclipse, right-click the package name in the Eclipse Package Explorer, and select New > Class. Fill-in the Name field as HelloItemizedOverlay. For the Superclass, enter “com.google.android.maps.ItemizedOverlay”. Click the checkbox for Constructors from superclass. Click Finish.
  2. First, you need an OverlayItem ArrayList, in which you’ll put each of the OverlayItem objects you want on the map. Add this at the top of theHelloItemizedOverlay class:
    private ArrayList<OverlayItem> mOverlays = new ArrayList<OverlayItem>();
  3. Now define the HelloItemizedOverlay constructors. The constructor must define the default marker for each of the OverlayItems. In order for the Drawable to actually get drawn, it must have its bounds defined. Most commonly, you want the center-point at the bottom of the image to be the point at which it’s attached to the map coordinates. This is handled for you with the boundCenterBottom() method. Wrap this around our defaultMarker, so the super constructor call looks like this:
    public HelloItemizedOverlay(Drawable defaultMarker) {
      super(boundCenterBottom(defaultMarker));
    }
  4. In order to add new OverlayItems to the ArrayList, you need a new method:
    public void addOverlay(OverlayItem overlay) {
        mOverlays.add(overlay);
        populate();
    }

    Each time you add a new OverlayItem to the ArrayList, you must call populate() for the ItemizedOverlay, which will read each of the OverlayItems and prepare them to be drawn.

  5. When the populate() method executes, it will call createItem(int) in the ItemizedOverlay to retrieve each OverlayItem. You must override this method to properly read from the ArrayList and return the OverlayItem from the position specified by the given integer. Your override method should look like this:
    @Override
    protected OverlayItem createItem(int i) {
      return mOverlays.get(i);
    }
  6. You must also override the size() method to return the current number of items in the ArrayList:
    @Override
    public int size() {
      return mOverlays.size();
    }
  7. Now set up the ability to handle touch events on the overlay items. First, you’re going to need a reference to the application Context as a member of this class. So add Context mContext as a class member, then initialize it with a new class constructor:
    public HelloItemizedOverlay(Drawable defaultMarker, Context context) {
      super(boundCenterBottom(defaultMarker));
      mContext = context;
    }

    This passes the defaultMarker up to the default constructor to bound its coordinates and then initialize mContext with the given Context.

    Then override the onTap(int) callback method, which will handle the event when an item is tapped by the user:

    @Override
    protected boolean onTap(int index) {
      OverlayItem item = mOverlays.get(index);
      AlertDialog.Builder dialog = new AlertDialog.Builder(mContext);
      dialog.setTitle(item.getTitle());
      dialog.setMessage(item.getSnippet());
      dialog.show();
      return true;
    }

    This uses the member android.content.Context to create a new AlertDialog.Builder and uses the tapped OverlayItem‘s title and snippet for the dialog’s title and message text. (You’ll see the OverlayItem title and snippet defined when you create it below.)

You’re now done with the HelloItemizedOverlay class and can start using it to add items on the map.

Go back to the HelloGoogleMaps class. In the following procedure, you’ll create an OverlayItem and add it to an instance of the HelloItemizedOverlay class, then add the HelloItemizedOverlay to the MapView using a GeoPoint to define its coordinates on the map.

  1. First, you need the image for the map overlay. If you don’t have one handy, use the Android on the right. Drag this image (or your own) into the res/drawable/directory of your project.
  2. At the end of your existing onCreate() method, instantiate :
    List<Overlay> mapOverlays = mapView.getOverlays();
    Drawable drawable = this.getResources().getDrawable(R.drawable.androidmarker);
    HelloItemizedOverlay itemizedoverlay = new HelloItemizedOverlay(drawable, this);

    All overlay elements on a map are held by the MapView, so when you want to add some, you have to get a list from the getOverlays() method. Then instantiate theDrawable used for the map marker, which was saved in the res/drawable/ directory. The constructor for HelloItemizedOverlay (your custom ItemizedOverlay) takes the Drawable in order to set the default marker for all overlay items.

  3. Now create a GeoPoint that defines the map coordinates for the first overlay item, and pass it to a new OverlayItem:
    GeoPoint point = new GeoPoint(19240000,-99120000);
    OverlayItem overlayitem = new OverlayItem(point, "Hola, Mundo!", "I'm in Mexico City!");

    GeoPoint coordinates are specified in microdegrees (degrees * 1e6). The OverlayItem constructor accepts the GeoPoint location, a string for the item’s title, and a string for the item’s snippet text, respectively.

  4. All that’s left is to add this OverlayItem to your collection in the HelloItemizedOverlay instance, then add the HelloItemizedOverlay to the MapView:
    itemizedoverlay.addOverlay(overlayitem);
    mapOverlays.add(itemizedoverlay);
  5. Now run the application.

You should see the following:

When you tap the overlay item, you’ll see the dialog appear.

Because the ItemizedOverlay class uses an java.util.ArrayList for all of the OverlayItems, it’s easy to add more. Try adding another one. Before theaddOverlay() method is called, add these lines:

GeoPoint point2 = new GeoPoint(35410000, 139460000);
OverlayItem overlayitem2 = new OverlayItem(point2, "Sekai, konichiwa!", "I'm in Japan!");

Run the application again. (You probably need to move the map to find the new overlay item.)

↑ Go to top

← Back to Hello, Views

Android: entendiendo los Themes y los Styles

[Fuente: http://brainflush.wordpress.com/2009/03/15/understanding-android-themes-and-styles/]

Que son los Android styles?

Un style en Android es una colección de pares atributo/valor aplicados a una View, a un Activity o a la aplicación entera (es decir, todas las Activities de tu aplicación). Los styles para las Activities se les llama themes, pero no nos confundamos: son sintacticamente equivalentes a los styles (porque de hecho son styles), simplemente tienen otro ambito. En este punto queremos dejar claro algo antes de seguir: sean Themes o Styles en Android no tienen nada que ver con estilos de usuario de aplicaciones como por ejemplo de Firefox. Los usuarios de Android no pueden cambiar el look de las aplicaciones de Android bajandose themes desde el Market o creando los suyos propios (todavia). Los themes de Android solo son de interes para los programadores, es una forma de hacer tus apps un poco más originales.

Cómo definimos custom styles?

Veamos una definición de theme simple  (en un fichero res/values/styles.xml):

<?xml version="1.0" encoding="utf-8"?>
<resources>
 <style name="MyTheme" parent="android:Theme.Light">
	 <item name="android:windowNoTitle">true</item>
	 <item name="android:windowBackground">@color/translucent_blue</item>
	 <item name="android:listViewStyle">@style/MyListView</item>
 </style>

 <style name="MyListView" parent="@android:style/Widget.ListView">
	 <item name="android:listSelector">@drawable/list_selector</item>
 </style>
</resources>

Primero, declaramos un nuevo theme llamado MyTheme, el cual hereda de otro llamado Theme.Light del android namespace (especificado en el atributo parent). Esto significa que todos los estilos que nosotros no especifiquemos explicitamente en nuestro custom theme vendrán heredado del android:Theme.Light.

Además en nuestra definición, también configuramos algunos styles personalizados utilizando el elemento ‘item’. Configuramos el atributo windowNoTitle a true, de forma que todas las activities que utilizan nuestro theme no tendrán un barra de títulos.También configuramos el color de fondo de la ventana a un color personalizado llamado ‘translucent_blue’; esta es una referencia de recurso (indicado por el simbolo @) a una definición de color en values/colors.xml. También podriamos poner una referencia a un recurso drawable, o poner directamente el codigo hexadecimal de un color.Finalmente, configuramos el estilo por defecto para los widgets de tipo ListView a un estilo personalizado llamado MyListView. La definición de este estilo sigue la misma estructura que la definición de MyTheme, solo que esta vez no es un Theme , sino simplemente un estilo que solo puede ser aplicados a objetos ListView.Hereda los estilos por defecto de ListView pero reemplaza la imagen por defecto del selector por un custom drawable.

Hay dos cosas importantes a entender aqui. Primero, las dos definiciones de estilo son completamente independientes la una de la otra (otra cosa distinta es que referenciamos MyListView en MyTheme). Esto significa , que si borramos la referencia a MyListView desde MyTheme, puedo aún utilizar ese estilo aplicandolo manualmente a una declaración de ListView en un fichero de layout. Piensa en los estilos como en un conjunto de atributos  y valores que simplifican la definición de tus pantallas, asi en vez de escribir

<ListView android:listSelector="@drawable/list_selector" />

escribimos

<ListView style="@style/MyListView" />

o mejor todavia, permitimos que este estilo sea aplicado automaticamente a todos los widgets de tipo ListView configurandolo en una definición de theme (como lo hemos hecho arriba). Observese que no ponemos ‘android:’ , el espacio de nombres de android, aqui, esto es asi , el atributo ‘style’ no está definido en el espacio de nombres de ‘android’. Ta dará error si intentas poner un estilo con  ‘android:style’, there is no such attribute.

De esa forma nucna tenemos que tocar la definición de ListView nunca más, podemos cambiar los estilos de estos widgets desde un archivo, la hoja de estilos. Esto ayuda a dejar limpio el código de la definición de la estructura de los layouts, mientras la definición del look de los objetos esta toda incluida en la hoja de estilos. Y además , lo más importante, las definiciones de tus estilos pueden ser reutilizados, lo que es particularmente útil si los estilos son compartidos entre varias vistas.

La otra cosa importante a entender es que los estilos no tienen ningun tipo de semántica. Cuando creamos un estilo llamado ‘MyListView’ que hereda de Widget.ListView, entonces lo que la intuición nos dice es que estamos creando un estilo que solo se aplica a objetos ListView. Esto no es del todo cierto. No hay mecanismo que chequee si de hecho estamos aplicando ese estilo a ListView o incluso prevenirlo de aplicarselo a un objeto de un tipo completamente distinto. Es decir lo que sucede es que Widget.ListView define algunos atributos de estilo que sólo tienen sentido cuando son aplicados a objetos ListView (como por ejemplo un listDivider), esto no nos impide , sin embargo, crear un estilo que localmente tiene sentido para cualquier tipo de widget (de atributos que están definidos a nivel de la clase View por ejemplo). En resumen, el programador cuando define un estilo debe saber si los atributos que cambia tienen sentido al aplicarselo a los objetos que quiere cambiar de look. Android no chequea estas cosas. Lo más probable es que el no haga nada si el atributo definido no tiene sentido en el objeto aplicado.

Qué puedo personalizar de estilos , y desde donde puedo heredar?

Para continuar sabiendo de estilos, es importante conocer dos cosas:

  1. en qué objetos van a ser aplicados
  2. qué estilos vienen ya de herencia

La respuesta fácil es: Todo lo definido en  android.R.styleable puede ser utilizado en una hoja de estilos para heredar de ellos. Asi , volviendo a nuestro ejemplo de estilo de ListView, el elemento de estilo android:listSelector puede ser encontrado en android.R.styleable, mientras android:style/Widget.ListView está definido en android.R.style.Estos dos ficheros son por lo tanto donde debes consultar cuando empiezas a definir estilo , son como los libros de referencia de estilos. Generalmente podemos heredar todos los estilos por defecto primero, y entonces sobreescribir los que quieres personalizar.

Truquillos útiles

Text Appearance

Te has encontrado con la situación de estar definiendo el tamaño del texto y su color una y otra vez en tus layouts? No lo hagas asi, utilizar text appearances. Los Text appearances son estilos. Android ya define algunos por defecto que puedes personalizar (estos están definidos por supuesto en el R.style). Esto ayuda mucho para no repetir código, y te ayuda a organizarte  en alguna estructura que organize tus distintos tipos de letra por medio a agrupaciones de estilos que puedes referenciar y reutilizar. Si, por ejemplo, quieres cambiar la text appearance por defecto de tu app, simplemente define un custom text appearance en tu hoja de estilos y configurala y ponla como la hoja de estilos por defecto en tu theme:

<?xml version="1.0" encoding="utf-8"?>
<resources>
 <style name="MyTheme" parent="android:Theme.Light">
     <item name="android:textAppearance">@style/MyDefaultTextAppearance</item>
 </style>

 <style name="MyDefaultTextAppearance" parent="@android:style/TextAppearance">
     <item name="android:textSize">12sp</item>
     <item name="android:textColor">#333</item>
     <item name="android:textStyle">bold</item>
 </style>
</resources>

Es bueno que te conozcas todas las text appearances que Android ya tiene definidos, y los puedas personalizar para tu app como necesites.

Colores

Evita configurar valores de colores directamente en los layouts o los estilos. Definelos en un fichero de recursos de color , y sólo utiliza referencialos desde los layouts y estilos. Esto ayuda a separarlos del resto del código de vista y hace fácil cambiarlos a posteriori. Por ejemplo , para los colores que no son dependientes del estaod , puedes definir un fichero colors.xml en res/values:

<?xml version="1.0" encoding="UTF-8"?>
	<resources>
	 <color name="default_text_color">#FFEAEAEA</color>
	 ...
	</resources>

A menudo, sin embargo, los colores son más complejos. Si. por ejemplo, utilizamos una imagen que personalice el list selector, puede pasar que el texto de la lista sea legible cuando no está seleccionado, pero se convierte dificil o imposible de leer cuando el custom selector está dibijado (por ejemplo,  porque el color es muy similar). En ese caso, necesitas un ColorStateList, que puedes utilizar automaticamente para cambiar automáticamente colores para la vista que esta siendo aplicada, basandose en el estado de la vista. Empieza creando un nuevo fichero, por ejemplo ‘stateful_text_color.xml’ en la carpeta res/colors. El recurso raíz es ‘selector’, el cual es el que siempre utilizas cuando creas recursos que cambian con el estado de la vista:

<selector xmlns:android="http://schemas.android.com/apk/res/android">
	 <item android:state_enabled="false" android:color="#333" />
	 <item android:state_window_focused="false" android:color="#CCC" />
	 <item android:state_pressed="true" android:color="#FFF" />
	 <item android:state_selected="true" android:color="#FFF" />
	 <item android:color="@color/default_text_color" /> <!-- not selected -->
</selector>

Esa es la idea. Puedes configurar este recurso de color dependientes de estado como cualquier otro, es solo que es definido de otra forma.

Ten en cuenta siempre que ya hay colores definidos que vienen con Android. El más útil de ello es probablemente el android:color/transparent, que corresponde al color  #00000000. Los primeros dos digitos hexadecimales, representan el canal alpha que es utilizado para definir la opacidad. Un valor de cero significa que no hay opacidad o lo que es lo mismo 100% de transparencia; el resto son los bits de colory no tiene relevancia, porque son invisible en este caso. Puedes entonces poner el fondo de tus vistas transparente haciendo lo siguiente:

	<style name="MyListView" parent="@android:style/Widget.ListView">
	 <item name="android:background">@android:color/transparent</item>
	</style>

Esto es todo por ahora amigos.

 

Android: Preference Activity

public abstract class

PreferenceActivity

extends ListActivity
implements PreferenceFragment.OnPreferenceStartFragmentCallback

Esta es la clase base para una activity que quiere mostrar una jerarquia de preferencias al usuario. Antes de la versión HoneyComb esta clase solo permitia mostrar un solo conjunto de preferencias; esta funcionalidad debe ser ahora encontrada en la nueva clase PreferenceFragment class. Si estas utilizando la PreferenceActivity al estilo antiguo esa documentación se aplicara a métodos deprecados aqui.

Esta activity muestra una o más cabeceras de preferencias, cada una de las cuales esta asociada con un PreferenceFragment a mostrar las preferencias de ese header. El layout actual y el display de estas asociaciones puede variar sin embargo; actualmente hay dos aproximaciones principales a esto:

  • En una pantalla pequeña se puede mostrar las cabeceras como una sola lista cuando se arranca la activity por primera vez. Seleccionando una de las cabeceras relanzará el activity y solo mostrará el PreferenceFragment de esa cabecera.
  • En una pantalla grande puede mostrar ambas cabeceras y el PreferenceFragment actual juntos en paneles. Seleccionar una cabecera hará un switch para mostrar el PreferenceFragment que sea para esa cabecera.

Las subclases de PreferenceActivity deben implementar onBuildHeaders(List) para rellenar la header list con los campos deseados. Haciendo esto implicitamente cambias a la clase al modo “headers + fragments”  (el modo por defecto al viejo estilo es mostrar una sola lista de preferencias).

Código de ejemplo

El siguiente código de ejemplo muestra una sola preference activity que tiene dos conjuntos diferentes de preferencias. La implementación, se compone de la activity en si mismo asi como de sus dos preference fragments:

public class PreferenceWithHeaders extends PreferenceActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // Add a button to the header list.
        if (hasHeaders()) {
            Button button = new Button(this);
            button.setText("Some action");
            setListFooter(button);
        }
    }

    /**
     * Populate the activity with the top-level headers.
     */
    @Override
    public void onBuildHeaders(List<Header> target) {
        loadHeadersFromResource(R.xml.preference_headers, target);
    }

    /**
     * This fragment shows the preferences for the first header.
     */
    public static class Prefs1Fragment extends PreferenceFragment {
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);

            // Make sure default values are applied.  In a real app, you would
            // want this in a shared function that is used to retrieve the
            // SharedPreferences wherever they are needed.
            PreferenceManager.setDefaultValues(getActivity(),
                    R.xml.advanced_preferences, false);

            // Load the preferences from an XML resource
            addPreferencesFromResource(R.xml.fragmented_preferences);
        }
    }

    /**
     * This fragment contains a second-level set of preference that you
     * can get to by tapping an item in the first preferences fragment.
     */
    public static class Prefs1FragmentInner extends PreferenceFragment {
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);

            // Can retrieve arguments from preference XML.
            Log.i("args", "Arguments: " + getArguments());

            // Load the preferences from an XML resource
            addPreferencesFromResource(R.xml.fragmented_preferences_inner);
        }
    }

    /**
     * This fragment shows the preferences for the second header.
     */
    public static class Prefs2Fragment extends PreferenceFragment {
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);

            // Can retrieve arguments from headers XML.
            Log.i("args", "Arguments: " + getArguments());

            // Load the preferences from an XML resource
            addPreferencesFromResource(R.xml.preference_dependencies);
        }
    }
}

The preference_headers resource describes the headers to be displayed and the fragments associated with them. It is:

<preference-headers
        xmlns:android="http://schemas.android.com/apk/res/android">

    <header android:fragment="com.example.android.apis.preference.PreferenceWithHeaders$Prefs1Fragment"
            android:icon="@drawable/ic_settings_applications"
            android:title="Prefs 1"
            android:summary="An example of some preferences." />

    <header android:fragment="com.example.android.apis.preference.PreferenceWithHeaders$Prefs2Fragment"
            android:icon="@drawable/ic_settings_display"
            android:title="Prefs 2"
            android:summary="Some other preferences you can see.">
        <!-- Arbitrary key/value pairs can be included with a header as
             arguments to its fragment. -->
        <extra android:name="someKey" android:value="someHeaderValue" />
    </header>

    <header android:icon="@drawable/ic_settings_display"
            android:title="Intent"
            android:summary="Launches an Intent.">
        <intent android:action="android.intent.action.VIEW"
                android:data="http://www.android.com" />
    </header>

</preference-headers>

The first header is shown by Prefs1Fragment, which populates itself from the following XML resource:

<PreferenceScreen
        xmlns:android="http://schemas.android.com/apk/res/android">

    <PreferenceCategory
            android:title="@string/inline_preferences">

        <CheckBoxPreference
                android:key="checkbox_preference"
                android:title="@string/title_checkbox_preference"
                android:summary="@string/summary_checkbox_preference" />

    </PreferenceCategory>

    <PreferenceCategory
            android:title="@string/dialog_based_preferences">

        <EditTextPreference
                android:key="edittext_preference"
                android:title="@string/title_edittext_preference"
                android:summary="@string/summary_edittext_preference"
                android:dialogTitle="@string/dialog_title_edittext_preference" />

        <ListPreference
                android:key="list_preference"
                android:title="@string/title_list_preference"
                android:summary="@string/summary_list_preference"
                android:entries="@array/entries_list_preference"
                android:entryValues="@array/entryvalues_list_preference"
                android:dialogTitle="@string/dialog_title_list_preference" />

    </PreferenceCategory>

    <PreferenceCategory
            android:title="@string/launch_preferences">

        <!-- This PreferenceScreen tag sends the user to a new fragment of
             preferences.  If running in a large screen, they can be embedded
             inside of the overall preferences UI. -->
        <PreferenceScreen
                android:fragment="com.example.android.apis.preference.PreferenceWithHeaders$Prefs1FragmentInner"
                android:title="@string/title_fragment_preference"
                android:summary="@string/summary_fragment_preference">
            <!-- Arbitrary key/value pairs can be included for fragment arguments -->
            <extra android:name="someKey" android:value="somePrefValue" />
        </PreferenceScreen>

        <!-- This PreferenceScreen tag sends the user to a completely different
             activity, switching out of the current preferences UI. -->
        <PreferenceScreen
                android:title="@string/title_intent_preference"
                android:summary="@string/summary_intent_preference">

            <intent android:action="android.intent.action.VIEW"
                    android:data="http://www.android.com" />

        </PreferenceScreen>

    </PreferenceCategory>

    <PreferenceCategory
            android:title="@string/preference_attributes">

        <CheckBoxPreference
                android:key="parent_checkbox_preference"
                android:title="@string/title_parent_preference"
                android:summary="@string/summary_parent_preference" />

        <!-- The visual style of a child is defined by this styled theme attribute. -->
        <CheckBoxPreference
                android:key="child_checkbox_preference"
                android:dependency="parent_checkbox_preference"
                android:layout="?android:attr/preferenceLayoutChild"
                android:title="@string/title_child_preference"
                android:summary="@string/summary_child_preference" />

    </PreferenceCategory>

</PreferenceScreen>

Note that this XML resource contains a preference screen holding another fragment, the Prefs1FragmentInner implemented here. This allows the user to traverse down a hierarchy of preferences; pressing back will pop each fragment off the stack to return to the previous preferences.

Android: Threading indoloro

[Fuente: http://developer.android.com/resources/articles/painless-threading.html]

Este articulo trata sobre el modelo de hilos utilizado por las aplicaciones Android y cómo las aplicaciones pueden asegurar un mejor rendimiento en sus interfaces gráficas utilizando threads para procesar las operaciones pesadas, más que hacerlo en el main thread. También se explica el API que tu aplicación puede utilizar para interactuar con los componentes del UI que se ejecutan en el main thread y que puedan ser modificados por los otros threads.

El hilo del UI

Cuando arrancamos una aplicación, el sistema crea el llamado thread “main” de la aplicación. El main thread, también llamado el UI thread, es muy importante porque se encarga de despachar los eventos a los widgets apropiados, incluyendo eventos de dibujo. Es también el thread donde tus aplicaciones interactuan con los componentes en ejecución del Android UI Toolkit.

Por ejemplo, si tocamos el botón de la “a” en la pantalla, el UI thread despacha el evento touch al widget, que pondrá su estado en “presionado” y encolará una invalidate request a la cola de eventos. Es el UI thread el que saca de la cola la request y notifica al widget para que se redibuje a si mismo.

Este modelo de single-thread puede llevar a un rendimiento malo a menos que tu aplicación sea implementada apropiadamente. Especificamente, si todo esta sucediendo en un solo thread, realizar operaciones pesadas tales como acceso a la red o queries de bases de datos en el UI thread puede bloquear por completo el interfaz del usuario. Tendremos que ningun evento puede ser despachado, incluyendo eventos de dibujo, mientras se este ejecutando una operación pesada. Desde la perspectiva del usuario, la aplicación aparece colgada. Incluso peor , si el UI thread se bloquea por más de unos pocos segundos (sobre 5 segundos actualmente) al usuario se le aparece el dialogo de “application not responding”.

Si quiere ver cómo de feo esto puede ser, escribe una simple aplicación con un botón que invoque Thread.sleep(2000) in its OnClickListener. El botón permanecerá en su estado presionado por unos 2 segundos antes de volver a su estado normal. Cuando esto sucede, es muy fácil para el usuario precibir que esa aplicación es muy lenta.

Para resumir, es vital para la responsividad del UI de tu aplicación mantener el UI thread desbloqueado. Si tienes operaciones pesadas que realizar , debemos estar seguros de hacerlas en otros thread (que llamaremos background or worker threads).

Veamos un ejemplo de un click listener descargando una imagen de la red y mostrandola en un ImageView:

public void onClick(View v) {
  new Thread(new Runnable() {
    public void run() {
      Bitmap b = loadImageFromNetwork();
      mImageView.setImageBitmap(b);
    }
  }).start();
}

A primera vista, este código parece ser una buena solución a tu problema , no se bloquea el UI thread. Desafortunadamente, viola al modelo single-threaded para el UI: el Android UI toolkit no es thread safe y debe siempre ser manipulado en el UI thread. En la pieza de código anterior, el ImageView es manipulado en el worker thread, lo cual puede causar problemas bastantes complejos.Encontrar estos errores puede ser dificil y llevar bastante tiempo.

Android ofrece varias formas de acceder al UI thread desde otros thread. Esta la lista de ellos:

Puedes utilizar cualquier de estas clases y métodos para corregir el ejemplo del código previo:

public void onClick(View v) {

  new Thread(new Runnable() {
    public void run() {
      final Bitmap b = loadImageFromNetwork();
      mImageView.post(new Runnable() {
        public void run() {
          mImageView.setImageBitmap(b);
        }
      });
    }
  }).start();
}

Desafortunadamente, estas clases y métodos pueden tender a hacer tu código más cimplicado y más dificil de leer. Se convierte incluso peor cuando implementas operaciones complejas que requieren actualizaciones del UI frecuentemente.

Para remediar este problema, Android 1.5 u plataformas posteriores ofrecen una clase de utilidad llamada AsyncTask, que simplifica la creación de tareas long-running que necesitan comunicar con el interface de usuario.Hay un equivalente para AsyncTask en Android 1.0 y 1.1 , es la clase UserTask. ofrece el mismo API.

El objetivo de AsyncTask es gestionar el hilo por ti. Nuestro ejemplo previo quedaria de la sigueinte forma:

public void onClick(View v) {
  new DownloadImageTask().execute("http://example.com/image.png");
}

private class DownloadImageTask extends AsyncTask<String, Void, Bitmap> {
     protected Bitmap doInBackground(String... urls) {
         return loadImageFromNetwork(urls[0]);
     }

     protected void onPostExecute(Bitmap result) {
         mImageView.setImageBitmap(result);
     }
 }

Como vemos m AsynTask hay que utilizarlo haciendo una subclase. Es también muy importante recordar que una instancia de AsyncTask debe ser creada en el UI thread y puede ser ejecutada solo una vez. Para más info AsyncTask documentation si quieres un entendimiento completo de su uso, pero mostraremos un vista rápida aqui:

Además de la documentación oficial, puedes leer varios ejemplos complejos en el código fuente del Shelves (ShelvesActivity.java and AddBookActivity.java) and Photostream (LoginActivity.javaPhotostreamActivity.java andViewPhotoActivity.java). Recomendamos encarecidamente leer el código fuente del Shelves para ver como hacer persistir las tareas entre cambios en la configuración y cómo cancelarlas apropiadamente cuando la activity se destruye.

Independientemente de si utilizas o no AsyncTask , siempre recuerda estas dos reglas sobre el single thread model:

  1. No bloquees el UI thread
  2. Asegurate que tu accedes al Android UI Toolkit solo desde el UI thread

Con AsyncTask es mucho más fácil hacer ambas cosas.