Andrés ha escrito el Loogic un artículo sobre redes sociales y geolocalización: “Redes sociales y Geoweb“.

Un extracto:

En un futuro estaremos siempre conectados a Internet, en casa, en el trabajo y andando por la calle, y los servicios de Internet que utilizamos nos mandaran la información que necesitemos según el sitio en el que estemos. O nos pondrán en contacto con la gente a la que podemos ver en ese lugar. A medida que los servicios sean mas inteligentes reaccionaran mejor a nuestras necesidades, y para eso es muy importante que sepan donde estamos. Esto también va a cambiar los usos sociales y va a crear nuevos. Se van a crear cada vez más puntos de contacto entre el mundo real y el ciberespacio.

La clase NotesList
La actividad principal de la aplicación NotePad es NotesList, como se puede ver en el manifest. La clase NotesList se define en el archivo NotesList.java, y es la responsable de la pantalla principal de la aplicación, mostrando una lista de las notas disponibles. Para ello hacemos que esta clase herede de ListActivity, un tipo de actividad especial diseñada para enlazarse a un cursor y mostrar los elementos del cursor en una lista.

Al iniciar la aplicación se invoca esta clase a través de su método onCreate:

   1: @Override

   2: protected void onCreate(Bundle icicle) {

   3:     super.onCreate(icicle);

   4:

   5:     setDefaultKeyMode(SHORTCUT_DEFAULT_KEYS);

   6:

   7:     Intent intent = getIntent();

   8:     if (intent.getData() == null)

   9:         intent.setData(NotePad.Notes.CONTENT_URI);

  10:

  11:     setupListStripes();

  12:

  13:     Uri uri = intent.getData();

  14:     mCursor = managedQuery(uri, PROJECTION, null, null);

  15:

  16:     ListAdapter adapter = new SimpleCursorAdapter(this,

  17:             R.layout.noteslist_item, mCursor,

  18:             new String[] {NotePad.Notes.TITLE},

  19:             new int[] {android.R.id.text1});

  20:     setListAdapter(adapter);

  21: }

En la línea 5 simplemente habilitamos los atajos de teclado. Las líneas 7-9 establecen el esquema de datos sobre el que vamos a operar, que se define en la clase NotePad. Lo veremos más adelante.

Las líneas 13 y 14 acceden a los datos. Las referencias a los orígenes de datos son objetos de tipo Uri, y en nuestro caso tienen esta forma:

   1: public static final Uri CONTENT_URI =

   2:     Uri.parse("content://com.google.provider.NotePad/notes");

El enlace entre este Uri y la base de datos se realiza en la clase NotePadProvider, que veremos en otra entrada. Basta decir por ahora que la línea 14 accede a la base de datos para abrir un cursor con las columnas especificadas por PROJECTION, que se define al comienzo de la clase NotesList:

   1: private static final String[] PROJECTION = new String[] {

   2:     NotePad.Notes._ID, NotePad.Notes.TITLE };

   3: private Cursor mCursor;

Como decíamos al principio, la actividad NotesList hereda de ListActivity, lo que le permite mostrar datos en una lista. Para ello creamos un adaptador ListAdapter, como se muestra en las líneas 16-19. La clase SimpleCursorAdaptor es un creador genérico de adaptadores, al que indicamos el layout que vamos a usar (en nuestro caso R.layout.noteslist_item), el cursor que hemos definido, los nombres de las columnas a mostrar (en este caso sólo el título), y los ids de los controles (tienen que ser del tipo TextView) que van a mostrar cada columna. ´

Finalmente el método setListAdapter asigna el ListAdapter a nuestra actividad para mostrar los datos.

Nos queda por ver el método setupListStripes:

   1: private void setupListStripes() {

   2:     Drawable[] lineBackgrounds = new Drawable[2];

   3:

   4:     lineBackgrounds[0] =

   5:         getResources().getDrawable(R.drawable.even_stripe);

   6:     lineBackgrounds[1] =

   7:         getResources().getDrawable(R.drawable.odd_stripe);

   8:

   9:     View view = getViewInflate().inflate(

  10:             android.R.layout.simple_list_item_1, null, null);

  11:     TextView v = (TextView)view.findViewById(android.R.id.text1);

  12:     v.setText("X");

  13:     v.measure(

  14:         View.MeasureSpec.makeMeasureSpec(View.MeasureSpec.EXACTLY, 100),

  15:         View.MeasureSpec.makeMeasureSpec(View.MeasureSpec.UNSPECIFIED, 0)

  16:         );

  17:     int height = v.getMeasuredHeight();

  18:     getListView().setStripes(lineBackgrounds, height);

  19: }

Entradas anteriores:

Programando en Android - NotePad (I)
Programando en Android - Conceptos iniciales (II)
Programando en Android - Conceptos iniciales (I)
Programando en Android - Prólogo

Me encuentro ocasionalmente con ideas reveladoras. Las leo y noto como si un grupo de neuronas aletargadas se activasen de repente, haciéndome pensar en algo en lo que no había pensado antes.

La última la he leído en el artículo de Jeff Atwood “Strong Opinions, Weakly Held“, algo así como “Opiniones firmes, mantenidas débilmente”. El artículo es una defensa frente a otro artículo, “Blogging Horror“, que acusa a Jeff Atwood de haber perdido credibilidad emitiendo opiniones desinformadas sobre diversos temas relacionados con la programación. Esta discusión tiene una ramificación española, a través de una entrada en VELOCIDAD DE ESCAPE, que apareció en la portada de menéame y fue contestada por Ricardo Galli, entre otros.

El título del artículo de Atwood se refiere a una idea expresada en otro artículo del mismo nombre, cuya idea central se resume en este párrafo:

A couple years ago, I was talking the Institute’s Bob Johansen about wisdom, and he explained that — to deal with an uncertain future and still move forward – they advise people to have “strong opinions, which are weakly held.” They’ve been giving this advice for years, and I understand that it was first developed by Institute Director Paul Saffo. Bob explained that weak opinions are problematic because people aren’t inspired to develop the best arguments possible for them, or to put forth the energy required to test them. Bob explained that it was just as important, however, to not be too attached to what you believe because, otherwise, it undermines your ability to “see” and “hear” evidence that clashes with your opinions. This is what psychologists sometimes call the problem of “confirmation bias.”

que traducido por mí dice:

Hace un par de años, le estaba hablando a Bob Johansen [del Instituto de para el Futuro de Palo Alto] sobre la sabiduría, y él me explicó que - para tratar con la incertidumbre del futuro y aún así seguir avanzando - recomendaban a la gente que tuviese “opiniones firmes, que se mantuviesen de forma débil.” Llevaban dando este consejo durante años, y por lo que entiendo había sido inicialmente desarrollado por el director del Instituto Paul Saffo. Bob me explicó que las opiniones débiles eran problemáticas porque no inspiran a la gente a desarrollar las mejores ideas posibles para ellas. Bob me explicó que era igualmente importante, sin embargo, no sentirse demasiado ligado a tus ideas porque, de otra forma, socava tu habilidad para “ver” y “oír” las evidencias que choquen con tus opiniones. Es lo que los psicólogos llaman a veces el problema del “sesgo de confirmación.”

Cuando expreso una opinión en un ambiente formal (en el trabajo, en una discusión seria…), siempre intento hacerlo dejando claro que esa opinión se aplica a un ámbito concreto, que es posible que sea errónea en casos que no he contemplado y que por lo tanto admite matices y condicionantes, y que se basa en el conocimiento necesariamente limitado que tengo sobre el asunto en cuestión. Nunca se me había ocurrido que esa forma de actuar puede estar, a veces, equivocada.

No sé si cambiaré mi forma de opinar, pero me lo pensaré dos veces antes de llamar dogmático a quien exprese sus ideas con demasiada firmeza.

Aún no me he mirado el documento (que es un zip de 58 megas), pero por lo que veo en Mi N70 y yo contiene datos de dispositivos móviles recogidos por BlueTooth. Por ejemplo, esta gráfica que colgó el propio fernand0 en su cuenta de Picassa (y que me ha servido para darme cuenta de que el autor de Mi N70 y yo es el mismo de Reflexiones e irreflexiones, otro blog al que estoy subscrito), mostrando el número de dispositivos Nokia detectados por modelo:

Lógicamente, como toda muestra estadística, esta gráfica está condicionada por la forma en la que se recogieron los datos, así que la principal conclusión que podemos sacar (sin haber leído el documento) es que los usuarios del 6021 se dejan con mucha frecuencia el BlueTooth activado.

La mayoría de los mortales olvidamos cualquier conocimiento abstracto en la décima parte del tiempo que nos costó adquirir dicho conocimiento (dato completamente inventado, pero en mi caso muy próximo a la realidad). Así que lo que vamos a hacer en concretar este conocimiento, y ponernos a programar.

El programa NotePad es un ejemplo que se incluye en la documentación de Google y en la SDK. Es un programa muy simple: permite crear notas, editarlas, borrarlas y modificar el título. Vamos a ver cómo funciona.

El ejemplo NotePad. El archivo Manifest.

Comencemos por el Manifest, que es donde se definen los componentes de la aplicación. El manifest.xml es, como su extensión indica, un archivo xml, que desde hace unos años se convertido en un formato habitual para contener configuraciones. El elemento raíz se llama manifest y contiene el namespace de la aplicación. Dentro se define el elemento aplicación:

<application android:icon="@drawable/app_notes" android:label="@string/app_name">

Aquí asociamos un nombre y un icono a la aplicación. La ‘@’ nos indica una referencia a un recurso. En general tiene este formato: @[package:]type/name, donde el paquete es opcional y sólo se indica cuando no pertenece a nuestra aplicación, el tipo corresponde a uno de los definidos en la carpeta res, y el nombre indica el identificador del recurso.  En nuestro caso, el icono se encuentra bajo la carpeta drawable, y la app_name se define en el archivo strings.xml de la carpeta values.

Dentro del elemento application lo primero que aparece es un provider, que nos dará acceso a la base de datos y que veremos más adelante. Tras él podemos ver definidas tres Activities: NotesList, NoteEditor y TitleEditor. Corresponderán a cada una de las ventanas: la que muestra las notas, la que las edita y la que modifica el título. Por ejemplo, este el elemento TitleEditor:

<activity android:name="TitleEditor" android:label="@string/title_edit_title" android:theme="@android:style/Theme.Dialog">

Además de indicar el nombre de la actividad, y la etiqueta que aparecerá en la ventana asociada, también especificamos que vamos a utilizar un tema concreto para esta actividad. Los temas nos permiten cambiar el look&feel de las aplicaciones con temas predefinidos o creados por nosotros. En este caso podemos ver como el recurso correspondiente al tema se referencia a través del paquete android, ya que está definido en el sistema, no en nuestra aplicación.

Dentro de cada activity hay definidos intent-filters, que permiten concretar el ámbito en el que se van a ejecutar, como ya vimos anteriormente. Por ejemplo, en NotesList encontramos:

<intent-filter>
<action android:name=”android.intent.action.MAIN” />
<category android:name=”android.intent.category.LAUNCHER” />
</intent-filter>;

que indica que esta es la actividad principal de la aplicación, y que aparecerá en el menú de aplicaciones del sistema. El filtro

<intent-filter>
<action android:name=”android.intent.action.VIEW” />
<action android:name=”android.intent.action.EDIT” />
<action android:name=”android.intent.action.PICK” />
<category android:name=”android.intent.category.DEFAULT” />
<data android:mimeType=”vnd.android.cursor.dir/vnd.google.note” />
</intent-filter>

nos indica que la actividad está disponible para ver, editar o seleccionar elementos del tipo vnd.android.cursor.dir/vnd.google.note, que es el tipo que definiremos más adelante para las notas. Finalmente, el filtro

<intent-filter>
<action android:name=”android.intent.action.GET_CONTENT” />
<category android:name=”android.intent.category.DEFAULT” />
<data android:mimeType=”vnd.android.cursor.item/vnd.google.note” />
</intent-filter>

permite al usuario seleccionar el tipo de dato vnd.android.cursor.dir/vnd.google.note. A diferencia de la acción android.intent.action.PICK, donde se selecciona un elemento de un conjunto de datos, aquí se selecciona un tipo de dato para que el usuario haga algo con él.

Todo esto se verá más claro al examinar el código de las actividades.

Entradas anteriores:
Programando en Android - Conceptos iniciales (II)
Programando en Android - Conceptos iniciales (I)
Programando en Android - Prólogo

Opera ha publicado estos días un pequeño informe llamado “Estado de la web móvil” (en inglés aquí), que analiza tendencias en la navegación por Internet a través de dispositivos móviles usando datos anónimos enviados por su navegador Opera Mini durante los tres primeros meses del 2008.

Este tipo de informes contienen sesgos imprevisibles que nos obligan a sacar conclusiones con mucho cuidado. El sesgo más evidente es que nos habla de usuarios de Opera Mini, lo que excluye a dueños de móviles iPhone, y minimiza el impacto de las BlackBerry, entre otros dispositivos (aunque existe Opera Mini para BlackBerry, creo que aún no es compatible con la tarifa plana del servicio BIS).

Dicho esto, algunas ideas que me sugiere el informe:

• La lista de los diez países que más navegan es llamativa: encabezada por Rusia, con Indonesia en segundo lugar, e incluyendo a Sudáfrica y Polonia junto a Estados Unidos o Gran Bretaña. Esta mezcla de países ricos y pobres reafirma una tendencia conocida: en los países menos desarrollados la falta de infraestructuras para acceder a Internet por cable o ADSL incentiva el acceso a Internet a través del móvil.
• Si observamos las gráficas que muestran, desde Enero del 2006, la evolución en número de usuarios, número de páginas y megas transferidos por mes, observamos un crecimiento aparentemente exponencial. Esta información está distorsionada por el hecho de que Opera Mini apareció en el mercado precisamente a principios del 2006, pero parece deducirse un incremento drástico en el acceso móvil a Internet en los últimos meses.

• Si comparamos los diez sitios más visitados en Estados Unidos y Reino Unido con el top Alexa para estos países, vemos que coinciden en gran medida. Dos cosas me llaman un poco la atención: el sitio www.mocospace.com, que está en el top móvil de ambos países pero no aparece en los 100 primeros del ranking Alexa para ninguno de ellos; y la ausencia de youtube en la lista completa de países que ofrece Opera, aunque esto último puede que sea debido a que la página no funcione bien en Opera Mini.

El informe contiene una conclusión un tanto capciosa: el triunfo de la “web completa” sobre la web wap o específica para móviles, basandose en que esta última sólo supone una cuarta parte de los datos obtenidos. Pero son datos obtenidos a través de un navegador que soporta razonablemente bien las páginas más habituales. ¿A qué tipo de páginas navegan los que no usan Opera Mini? Y sobre todo, ¿a cuántas páginas dejan de navegar, por ser difíciles o imposibles de usar, los usuarios de la web móvil? Puede que la conclusión del informe sea correcta, pero es pronto para afirmarlo.

Vía: Estado de la web móvil de Opera

Intents

Si las Activities son básicamente pantallas, las “intenciones” o Intents son la manera de invocar estas Activities. La definición breve de la documentación es: “Un intent es la descripción abstracta de una operación que se va a llevar a cabo”. O dicho de otro modo, un Intent es una clase que permite especificar una Activity a ejecutar, llamando a uno de los métodos de la clase Activity con ese Intent de parámetro. Parece fácil, pero he de confesar que en la documentación de Android el asunto me pareció un poco confuso, sobre todo por la cantidad de información que puede ir asociada a estas clases.

Dos formas de llamar a una Activity

Explicitamente o implicitamente. La forma explícita es simple de entender: creamos un Intent indicando el nombre de la clase correspondiente a la actividad y el paquete, llamamos a startActivity (o startSubActivity si queremos que nos notifiquen cuándo finaliza dicha actividad) y listo. El sistema busca la clase y crea la instancia, pasándo los datos que podamos haber añadido al Intent en el objeto Bundle del método onCreate de la nueva instancia.

// ClaseActividad1 es la clase de la actividad
//que queremos iniciar. El parámetro this indica
//el Context actual, para saber en qué
// package buscar esta clase
Intent i = new Intent(this, ClaseActividad1.class);
// Esta información se recuperará en el objeto Bundle de onCreate
i.putExtra(”NombreParametro”, valorParametro);
startActivity(i);

La invocación implícita de una actividad se realiza también a través de la clase Intent. Es implícita porque no se indica el nombre de la clase correspondiente a la actividad a invocar, sino que se establecen una serie de criterios, y se deja que el sistema elija una actividad que cumpla esos criterios.

Intenciones y criterios

A un Intent podemos asociarle una acción, unos datos y una categoría. Y aquí está el verdadero quid de esta clase.  Las actividades pueden declarar el tipo de acciones que pueden llevar a cabo y los tipos de datos que pueden gestionar. Las acciones son cadenas de texto estándar que describen lo que que la actividad puede hacer. Por ejemplo, android.intent.action.VIEW es una acción que indica que la actividad puede mostrar datos al usuario. Esta acción viene predefinida en la clase Intent, pero es posible definir nuevas acciones para nuestras actividades. La misma actividad puede declarar que el tipo de datos del que se ocupa es, por ejemplo, “vnd.android.cursor.dir/person”. También puede declarar una categoría, que básicamente indica si la actividad va a ser lanzada desde el lanzador de aplicaciones, desde el menú de otra aplicación o directamente desde otra actividad. En el AndroidManifest.xml quedaría algo así:

<intent-filter>
<action android:name=”android.intent.action.VIEW” />
<category android:name=”android.intent.category.DEFAULT” />
<data android:mimeType=”vnd.android.cursor.dir/person” />
</intent-filter>

Así, para llamar implícitamente a una actividad a través de un intent, en vez de asignar el nombre de la clase le asignamos una de las acciones que esta puede llevar a cabo, con el tipo de datos adecuado. Las reglas exactas se indican en la documentación de la clase IntentFilter.

Conclusiones

Activities e Intents son los dos ejes sobre los que gira la arquitectura de las aplicaciones Android. Existen muchos más conceptos importantes, por supuesto, pero a partir de aquí lo mejor es verlo funcionando todo en una aplicación ejemplo. Pero eso será en la próxima entrada.

Entradas anteriores:
Programando en Android - Conceptos iniciales (I)
Programando en Android - Prólogo

La fundación LiMo fue fundada a principios del 2007 por Motorola, NEC, NTT DoCoMo, Orange, Panasonic, Samsung y Vodafone con el propósito de crear un sistema operativo abierto basado en Linux y disponible para cualquier hardware. Desde entonces han sacado varias notas de prensa anunciando la incorporación de nuevas en presas a la fundación así como sus previsiones de lanzamiento de los primeros dispositivos LiMo.

El último anuncio que han hecho ha sido la incorporación del operador norteamericano Verizon al consorcio. Como quiera que Android ya lleva unos meses en el mercado, las comparaciones entre ambos sistemas basados en Linux no se han hecho esperar.

Como no había prestado mucha atención a LiMo hasta ahora, he aprovechado esta noticia para averiguar un poco más sobre esta plataforma, empezando por los móviles LiMo actualmente en el mercado. La página de la fundación tiene un listado de los dispositivos que están actualmente en el mercado, sobre todo Motorola y NTT DoCoMo. Me sorprendió encontrar en la lista algún dispositivo conocido, como el Motorola Z6w. ¿El Z6w es un móvil LiMo? Pues en realidad no, al menos no del todo. El sistema del Z6w, según la hoja de especificaciones, se denomina “MOTOMAGX™ –Motorola’s Linux™-Java operating system”. ¿Por qué entonces aparece en la lista de dispositivos LiMo?

Por lo que he podido entender de lo que he leído la situación de la plataforma LiMo es la siguiente: los miembros de la fundación están desarrollando un sistema operativo basado en una arquitectura como la que se muestra en este esquema, sacado de ars technica:

Cada uno de estos componentes está siendo probado, desarrollado o estudiado por los miembros de la fundación. Por ejemplo, los marcados en gris forman parte de una release inicial llamada R1, liberada este marzo. La siguiente fase del sistema, marcada como R2, se encuentra en desarrollo, y quedan varios componentes pendientes para futuras fases.

En teoría, la R2 será liberada este año, y también en teoría este año estará disponible una SDK para los desarrolladores. Mientras tanto, se han publicado las interfaces de las APIs de la release 1 aquí, que incluye GTK+ para la interfaz de usuario. Todo ello en C y C++.

Los primeros dispositivos LiMo están anunciados para finales de este año. Así que, ¿qué hay de los móviles que aparecen en la página de la fundación LiMo, como el Motorola Z6w? Pues son dispositivos que incorporan algunos de los componentes que aparecen en el gráfico: están basados en Linux, y sirven de banco de pruebas para la futura especificación de la plataforma.

Así que todavía es pronto para cualquier tipo de comparaciones. LiMo sólo tiene en el mercado varios dispositivos con parte de los componentes del sistema, mientras que Android tiene el sistema completo pero sin dispositivos físicos. Dentro de unos meses volveremos a hablar del asunto.

Alberto no se va a volver de vacío de la Where2.0 gracias a Frank Taylor, de Google Earth Blog. Este blogger especialista en GPS, gráficos 3D, y simuladores espaciales (trabajó en la NASA, tope cool…) sorteó un ratón 3D entre la gente que le había dado su tarjeta, y Alberto resultó el ganador.

Más allá de la anéctoda, es interesante comprobar las diferencias, digamos formales, que existen en este tipo de eventos entre España y Estados Unidos. La actitud abierta e informal que en este tipo de congresos muestran los asistentes, incluso aquellos que ostentan la condición de gurús o tienen altos cargos directivos, contrasta con el estereotipo de ponente de congresos español, que enfundado en su traje acude a dar su charla, disfrutar de la comida con los organizadores y los cargos políticos del sector, y si acaso conseguir un par de entradas para que los técnicos aplaudan en su intervención y paseen por los stands.

Es una descripción un tanto caricaturesca, y por tanto exagerada, pero este tipo de eventos son una oportunidad fantástica para conocer a gente que tiene los mismos intereses que tú e intercambiar ideas y experiencias, y en España es demasiado habitual que la principal motivación para organizar congresos sea dejarse ver y aparecer en la prensa.

En fin. Tras este desahogo después de un duro día de trabajo (creo que empiezo a comprender por qué a alguna gente le gusta tanto bloguear), les deseo suerte a Alberto y Diego en su conquista de las américas.

El primer paso para relacionar conceptos es conocer los conceptos. Y en Android existen una serie de conceptos que suponen la piedra y el mortero de cualquier aplicación.

El archivo AndroidManifest.xml

Este archivo está presente en todas las aplicaciones Android. Su contenido especifica los componentes de la aplicación, así como la configuración global de la misma. Su descripción se muestra en esta página de la documentación.

En una aplicación habitual, dentro de este archivo habrá un elemento <application>, dentro del cuál habrá uno o varios elementos <activity>. Cada uno de estos elementos supone una interacción con el usuario (generalmente una ventana), y se corresponde con una clase que hereda de la clase Activity.

La clase Activity

Según la documentación de Google, una Activity es una cosa única con un objetivo determinado que el usuario puede hacer. Esta es una definición abstracta. Podemos concretar más la definición diciendo que una Activity (es decir, una clase de nuestra aplicación que hereda de la clase Activity) se presenta al usuario como una ventana. Esta clase crea una ventana que muestra una interfaz de usuario, la cual está definida a su vez en una instancia de otra clase, la clase View.

Cuando se ejecuta una aplicación Android lo primero que se muestra al usuario es la ventana definida por la actividad que esté marcada en el AndroidManifest.xml como principal. Las actividades se gestionan como una pila, así que desde una actividad se puede llamar a otra, y cuando esta finaliza se retorna a la actividad inicial.

Una actividad puede estar ejecutándose, en pausa o detenida. Simplificando, está en ejecución cuando es visible e interacciona con el usuario, está en pausa cuando es visible pero otra ventana, transparente o que no ocupe toda la pantalla, tiene el foco, y está detenida cuando no es visible. En todos estos casos la clase mantiene su información.

En la documentación encontramos un gráfico que ilustra el ciclo de vida de una actividad:

Aunque no es necesario entender de momento todos los detalles de este gráfico, en él se ven los estados por los que puede pasar una actividad (los óvalos coloreados) y los eventos que se disparan en dichos estados (los rectángulos grises):

• Cuando se crea una actividad, se invoca el evento onCreate(). Este evento sólo se invoca la primera vez que se llama a una actividad, o bien cuando se llama después de que el sistema haya tenido que eliminarla por falta de recursos (más sobre esto en próximos artículos).
• onStart() es el evento invocado cuando cada vez que la actividad se muestra al usuario. Es decir, la primera vez que se muestra, y las veces que en las que vuelve a aparecer tras haber estado oculta. En este último caso, se invoca onStop() al desaparecer y onRestart() inmediatamente antes de reaparecer.
• onFreeze() y onPause() son llamadas secuencialmente cuando otra actividad va a pasar en encargarse de la interacción con el usuario. Tras onPause() la actividad permanece en un estado de espera en el que puede ocurrir que la aplicación sea destruida, por lo que estos eventos se usan para consolidar la información que no queremos que se pierda. Si la actividad no se destruye volverá al primer plano con el evento onResume().

La idea importante con la que quedarse es que una actividad que esté pausada o detenida (tras onPause() u onStop()) puede ser destruida por el sistema si previo aviso, por lo que deberemos encargarnos de guardar antes la información necesaria (durante onFreeze() y onPause()). Los detalles lo veremos en una próxima entrada.