miércoles, 17 de diciembre de 2008

Declaración - Disclaimer

Declaración
Google, The Open Handset Alliance y Sun Microsystems, Inc. no endosan este blog ni autorizan el desarrollo de mis proyectos personales. De hecho, este blog es el resultado de mis intereses personales y no ha sido endosado ni autorizado por ninguna entidad comercial.

Disclaimer
Neither Google,The Open Handset Alliance nor Sun Microsystems, Inc. have endorsed this page or authorized the development of my personal projects. In fact, this blog is the result of my personal interests and it has not been endorsed or authorized by any commercial entity.

En este Blog voy a publicar mi experiencia desarrollando software para Android® platform utilizando Java®. Además, publicaré mis notas personales sobre algunos documentos de la documentación de Android®.

In this Blog I'm going to publish my experience developing software for Android® platform using Java®. Also, I'll publish my personal notes about some documents of Android's documentation.

martes, 16 de diciembre de 2008

Sobre mis notas personales

Algunas cosas sobre mis notas personales:

  • Continuar con la traduccion cuando tengamos en el mercado telefonos con Android instalado.

jueves, 6 de marzo de 2008

TIP: Sensor Simulator

En la siguiente página encontrarás un simulador excelente para generar datos de ubicación geográfica y de movimiento para tu emulador.

http://code.google.com/p/openintents/

martes, 15 de enero de 2008

Desarrollando aplicaciones - Almacenamiento, recuperación y exposición de datos

Documento original: Storing, Retrieving and Exposing Data

Almacenamiento, recuperación y exposición de datos

[Título original: Storing, Retrieving and Exposing Data]

Un típico sistema operativo de escritorio provee un sistema de archivos común que cualquier aplicación puede usar para almacenar y leer archivos que pueden ser leídos por otras aplicaciones (quizá definiendo algunos controles de acceso). Android usa un sistema diferente: en Android, todas los datos de aplicaciones (incluyendo archivos) son privados a esa aplicación. Sin embargo, Android también provee una forma standard para que una aplicación exponga sus datos privados a otra aplicación. Esta sección describe todas las formas en las que una aplicación puede almacenar y recuperar datos, exponer sus datos a otras aplicaciones y también la forma en la cual tú puedes solicitar datos desde otras aplicaciones que exponen sus datos.

Android provee los siguiente mecanismos para almacenar y recuperar datos:

  • Preferencias : Es un mecanismo liviano que permite almacenar y recuperar datos primitivos en la forma de pares clave/valor. Este mecanismo es típicamente usado para almacenar las preferencias de la aplicación.

  • Archivos : Tú puedes almacenar tus archivos en el dispositivo o en un medio de almacenamiento removible. Por omisión, las otras aplicaciones no tienen acceso a estos archivos.

  • Base de datos : Las APIs de Android contienen soporte para SQLite. Tu aplicación puede crear y usar base de datos SQLite privadas. Cada base de datos es privada al paquete que la crea.

  • Proveedores de contenidos : Un proveedor de contenidos es un componente opcional de una aplicación y expone el acceso de lectura/escritura a los datos privados de la aplicación, sujeto a las restricciones que tú quieras imponer. Los proveedores de contenidos implementan una sintaxis estándard para solicitar datos y un mecanismo de acceso estándard para devolver los datos. Android provee algunos proveedores de contenidos para tipos de datos estándard, tales como contactos personales.

  • Redes : No te olvides que también puedes usar la red para almacenar y recuperar datos.

  • domingo, 30 de diciembre de 2007

    Desarrollando aplicaciones - Bloques de construcción de Android

    Documento original: Android Building Blocks

    Bloques de construcción de Android

    [Título original: Android Building Blocks]

    Puedes ver una aplicación Android como una colección de componentes de varios tipos. Estos componentes en su mayoría tienen un bajo nivel de acloplamiento entre ellos, a tal grado que te permiten describirlos de manera muy precisa como una federación de componentes más que un aplicación como un todo.

    Por lo general, todos estos componentes corren en el mismo proceso del sistema. Es posible (y muy común) crear múltiples "thread"s dentro de tal proceso, y además es posible crear procesos hijos completamente separados del proceso padre, si es que tú lo llegaras a necesitar. Estos últimos casos son poco comunes ya que Android trata en lo posible de hacer los procesos lo más transparente en tu código.

    Estas son las partes más importantes de las APIs de Android:

  • AndroidManifest.xml : El archivo "AndroidManifest.xml" es el archivo de control que le dice al sistema qué es lo que debe hacer con los componentes de más alto nivel que tú haz creado (específicamente "Actividad", "Servicio", "Receptor de Intentos" y "Proveedor de Contenidos" descritos a continuación). Debido a esto, este archivo es considerado el "pegamento" que indica qué "Intent" serán recibidos por tus "Activity.

  • Actividad : Una "Activity" es, fundamentalmente, un objeto que tiene un ciclo de vida. Una "Activity" es un trozo de código que hace algún trabajo. Si fuera necesario, este trabajo puede incluir el despliegue de una UI al usuario. Sin embargo, lo anterior no es necesario y algunas "Activity" nunca despliegan una UI. Típicamente, tú designarás una de las "Activity" de tu aplicación como el punto de inicio de tu aplicación.

  • Vista : Una "View" es un objeto que sabe cómo dibujarse asimismo en la pantalla. Las interfaces de usuario de Android están conforman un árbol de "View". Si tú quieres realizar algún tipo de técnica gráfica especial entonces deberás crear una "View" (este es el caso en el cual tú quisieras crear un juego o construir un nuevo tipo de interface de usuario)

  • Intento : Un "Intent" es un simple mensaje que representa "la intención" de hacer algo. Por ejemplo, si tu aplicación quiere abrir una página web, debe expresar su "Intento" para ver la URI a través de la creación de una instancia de "Intent" y luego entregársela al sistema. Posteriormente, el sistema ubicará una pieza de código que sepa cómo manipular aquel "Intento" y la ejecuta (en este caso un browser). Los "Intent" también pueden ser usados para difundir eventos interesantes a través de todo el sistema (tales como notificaciones).

  • Servicio : Un "Service" es un cuerpo de código que se ejecuta en segundo plano. Se ejecuta dentro de su propio proceso o en el contexto del proceso de otra aplicación, dependiendo de sus necesidades. Otros componentes se "atan" a un "Servicio" e invocan sus métodos a través de "llamados remotos de procedimientos (RPC)". Un ejemplo de un "Service" es un reproductos de música. En este caso, el usuario podría usar una UI para seleccionar la música y posteriormente cerrar la UI, pero la música deberá continuar sonando. Esto se logra usando un "Servicio" que continuará la reproducción de la música.

  • Notificación : Una notificación es un pequeño ícono que aparece en la barra de estado. Los usuarios pueden interactuar con este ícono para recibir información. Las notificaciones más conocidas son los mensajes SMS, correo de voz; pero las aplicaciones pueden crear sus propias notificaciones. Las notificaciones son el mecanismo preferido para alertar al usuario que algo requiere de su atención.

  • Proveedor de Contenidos : Un "ContentProvider" es un almacen de datos que provee acceso a datos en el dispositivo. Un ejemplo clásico es el "ContentProvider" que es usado para tomar datos desde la lista de contactos. Tu aplicación puede utilizar datos que otras aplicaciones han expuesto vía un "ContentProvider". Tú también puede definir tus propios "ContentProvider" para así exponer tus propios datos.

  • viernes, 21 de diciembre de 2007

    Desarrollando aplicaciones - Escuchando notificaciones de la UI

    Documento original: Listening for UI Notifications

    Escuchando notificaciones de la UI

    [Título original: Listening for UI Notifications]

    Algunas notificaciones de la UI son automáticamente expuestas y llamadas por Android. Por ejemplo, una "Activity" sobreescribe los métodos "onKeyDown" y "onKeyUp" y "TextView" expone "onFocusChanged(boolean, int)". Sin embargo, algunos métodos "callbacks", tales como clic de botones no son expuestos de manera nativa y deben ser registrados manualmente como se muestra a continuación.

    public class SendResult extends Activity
    {
    /**
    * Initialization of the Screen after it is first created. Must at least
    * call setContentView() to
    * describe what is to be displayed in the screen.
    */
    protected void onCreate(Bundle savedValues)
    {
    ...

    // Listen for button clicks.
    Button button = (Button)findViewById(R.id.corky);
    button.setOnClickListener(mCorkyListener);
    }

    // Create an anonymous class to act as a button click listener.
    private OnClickListener mCorkyListener = new OnClickListener()
    {
    public void onClick(View v)
    {
    // To send a result, simply call setResult() before your
    // activity is finished.
    setResult(RESULT_OK, "Corky!");
    finish();
    }
    };

    Desarrollando aplicaciones - Enganchando un elemento de la pantalla

    Documento original: Hooking into a Screen Element

    Enganchando un elemento de la pantalla

    [Título original: Hooking into a Screen Element]

    Tú puedes obtener una referencia a un elemento de la pantalla llamando al método "Activity.findViewById()". Posteriormente, puedes usar esta referencia para modificar o recuperar valores expuestos por ese elemento.

    TextView msgTextView = (TextView)findViewById(R.id.msg);
    msgTextView.setText(R.string.push_me);