Programación en Android: Gestión de Datos

Caso práctico

Juan y María trabajando frente al ordenador, y con un bocadillo que indica que están pensando en los Datos.

Ministerio de Educación. (Uso educativo no comercial.)

María y Juan ya tienen claro como diseñar las interfaces de usuario de una aplicación Android. Es hora de aprender a manejar la información que la aplicación puede generar o solicitar de otras aplicaciones.

¿Se pueden guardar ficheros en un dispositivo móvil?
¿Dónde y cómo se almacenarían?
¿La lista de contactos de nuestro dispositivo puede ser accesible desde nuestra aplicación?

En definitiva: ¿cómo se gestionan los datos en una aplicación Android?
Éstas y muchas otras preguntas que ahora se plantean se irán dando respuesta conforme avancen en los contenidos.

Creado con eXeLearning (Ventana nueva)

1.- Preferencias

Caso práctico

Ocultar

Reunión Equipo de varias personas alrededor de una mesa, sobre la que hay un proyector que una persona está usando para una presentación.

Ministerio de Educación. (Uso educativo no comercial.)

Ada ha reunido a su equipo de desarrolladores Android para proponerles una tarea inicial. Tienen que consultar y utilizar varias aplicaciones Android ya existentes en el mercado y deben anotar todo aquello que haga referencia al tratamiento de los datos:

¿Qué tipo de información se solicita al usuario?
¿Debe el usuario introducir siempre la misma información en una aplicación o ésta recuerda el último estado de la misma?
¿Existen similitudes en la interfaz de usuario de aplicaciones distintas cuando el usuario configura sus preferencias?

Ocultar

Captura de pantalla de las preferencias de un dispositivo real, en concreto la pantalla de Ajustes Generales..

Captura del IDE Android Studio. Apache 2.0

Las pantallas de configuración en las aplicaciones Android son muy útiles y prácticamente todas las aplicaciones las incluyen. También se conocen como pantallas de preferencias, porque el usuario las utiliza para introducir la información que desea a la hora de utilizar cada una de las aplicaciones.

Cuando el usuario modifica una preferencia, este cambio se guarda en un fichero en forma de par clave-valor hasta que se modifique de nuevo, de forma que siempre se guardan las preferencias del usuario.

Si eres usuario de Android, habrás comprobado cómo este tipo de pantallas es muy común en casi todas las aplicaciones. Aunque esta norma no es reconocida oficialmente, la opción de preferencias o Settings en Android Studio forma parte del menú principal y nunca es visible (app:showAsAction="never") y normalmente es la última opción (android:orderInCategory=100).

En este apartado vamos a aprender a diseñar este tipo de interfaz gráfica para que posteriormente el usuario de la aplicación pueda configurar sus preferencias guardando y recuperando dicha información.

Para implementar las preferencias tendrás que comprobar en primer lugar qué librería de soporte estás utilizando. La forma que recomienda Google es utilizar la librería Preference de AndroidX. No obstante, se indicarán las diferencias con respecto a la librería anterior android.preference que en la versión Android 11 ha quedado obsoleta.

Citas Para Pensar

Ocultar

No nos hace falta valor para emprender ciertas cosas porque sean difíciles, sino que son difíciles porque nos falta valor para emprenderlas.
Séneca

Creado con eXeLearning (Ventana nueva)

1.1.- Diseño de la pantalla de preferencias I

Ocultar

Como veíamos en la unidad de Programación en Android: Interfaz de usuario, el diseño de pantalla de preferencias se basa en ficheros XML. Android dispone de un mecanismo que hace muy fácil la gestión de preferencias de una aplicación para el desarrollador.

Crear recurso XML de las preferencias

Para crear este nuevo fichero XML de preferencias donde poder definir la interfaz gráfica podemos seguir los siguientes pasos desde el IDE Android Studio:

En primer lugar, creamos una carpeta nueva llamada /xml/ dentro de la carpeta /res/. Para ello, pulsamos botón derecho sobre la carpeta /res/ y seleccionamos New - Android resource directory.
En la pantalla que se abre seleccionamos el tipo de recurso XML.
Sobre la carpeta que acabamos de crear pulsamos botón derecho y seleccionamos New - XML resource file.
En la siguiente ventana del asistente ponemos un nombre al fichero (Ej.: settings.xml) que automáticamente lo almacenará con el tipo XML.
Pulsamos en el botón Finish y ya podemos comenzar con el diseño de la pantalla. Podemos asegurarnos viendo el código XML de la plantilla creada que tiene como layout principal PreferenceScreen y en vista diseño podremos incorporar los elementos de esta pantalla que necesitemos.

Si nos sale el siguiente error "android.preference.PreferenceScreen is deprecated" es que tenemos que añadir al proyecto la librería específica AndroidX.

Para ello vamos a File -> Projects Structure. Se selecciona el módulo app, y se da al icono ->Library Dependency y en el campo de búsqueda se pone androidx.preference.

Captura del IDE Android Studio. Apache 2.0

Recordemos que para diseñar una interfaz de usuario debemos tener en cuenta el contenedor donde se organizan los objetos o controles. En el caso de la pantalla de preferencias, este contenedor está formado por las etiquetas:

<PreferenceScreen> ...... </PreferenceScreen>

Además, los objetos también pueden estar a su vez agrupados u organizados en categorías, de forma que se muestra el título de categoría y añade una línea divisoria al final de la categoría, separando visualmente los grupos de preferencias. En este caso se va a crear una categoría que muestre los "Datos del usuario" y dentro de ella agruparemos el resto de preferencias:

<PreferenceCategory android:title="@string/category_user_information">
...... 
</PreferenceCategory>

Tipos de preferencias

Para que el usuario de la aplicación pueda configurar sus preferencias utilizaremos una serie de controles u objetos, entre los que destacamos los siguientes por ser los más utilizados:

Preference: muestra un elemento de texto simple. Hay que definir al menos tres atributos:
- clave (key): esta clave se utiliza para hacer referencia al valor que el usuario introduce en el fichero de preferencias. Es la misma clave que se utiliza para recuperar el valor de nuestras preferencias.
- título (title): el título de la preferencia.
- resumen (summary): es una descripción que se muestra debajo del título con un tamaño de texto menor.
- icono (icon): se puede utilizar un icono que represente a la preferencia.

<Preference
    android:key="preference_key"
    android:title="@string/preference_user"
    android:summary="@string/preference_user_summary"
    android:icon="@drawable/ic_action_user" >

CheckBoxPreference: marca que el usuario puede activar o desactivar. El valor que devuelve esta preferencia es si está habilitado o deshabilitado. Esta opción suele estar en desuso, ya que se suele utilizar SwitchPreferenceCompat.
SwitchPreferenceCompat: guarda dos estados al igual que CheckBoxPreference pero se muestra como un pequeño interruptor.

<SwitchPreference
    android:defaultValue="true"
    android:key="preference_saveuser_key"
    android:title="@string/preference_saveuser" />

EditTextPreference: aparece un cuadro de diálogo donde el usuario puede introducir una cadena de texto sencilla. A veces es recomendable que el valor introducido por el usuario aparezca como valor resumen. Para habilitar este comportamiento se tiene que añadir el atributo app:useSimpleSummaryProvider="true" dentro de la preferencia en XML. En el caso de que no esté definido, aparece Not Set.

<EditTextPreference
    android:dialogTitle="@string/dialog_title_name_avatar"
    android:key="preference_name_avatar_key"
    android:title="@string/preference_name_avatar"
    app:useSimpleSummaryProvider="true"
    android:icon="@drawable/ic_action_name_avatar"/>

SeekBarPreference: esta preferencia muestra un SeekBar para introducir un valor entero. En este ejemplo se introduce 18 como valor inicial mediante android:defaultValue. Además, se puede establecer un valor máximo con el atributo android:max

  <SeekBarPreference
     android:key="preference_age_key"
     android:title="@string/preference_age"
     android:defaultValue="18"/>

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

1.2.- Diseño de la pantalla de preferencias II

Ocultar

En este segundo apartado vamos a implementar una segunda categoría llamada "Opciones del juego" donde veremos cómo implementar una preferencia que muestra una lista de opciones. Estas preferencias deben tener dos atributos android:entries que contiene el texto de los elementos de la lista y android:entryValues que define los valores asociados con cada elemento de la lista.

Los valores de ambos atributos se deben definir como <string-array>, y se crea un fichero XML llamado /res/values/arrays.xml para ello:

Captura pantalla de cómo crear dos arrays de tipo String. En el panel Android, aparece seleccionado el archivo arrays.xml, en la ruta app/res/values/arrays.xml y el archivo settings.xml en la ruta app/res/xml/settings.xml. Ambos archivos están abiertos en el área de trabajo, estando visible la pestaña correspondiente a arrays.xml

Captura del IDE Android Studio. Apache 2.0

Una vez definido los atributos, veamos qué tipos de preferencias se pueden crear:

DropDownPreference: muestra un despegable de opciones.
ListPreference: lista de opciones donde el usuario solo puede seleccionar una de ellas. Con esta preferencia si se puede usar app:useSimpleSummaryProvider para que en el resumen aparezca la opción que se ha seleccionado.

<ListPreference
    android:defaultValue="1"
    android:dialogTitle="@string/dialog_title_level"
    android:entries="@array/level_game_entries"
    android:entryValues="@array/level_game_entry_values"
    android:key="preference_level"
    android:title="@string/preference_level"
    app:useSimpleSummaryProvider="true" />

MultiSelectListPreference: lista de opciones donde el usuario puede seleccionar más de una. Con esta preferencia se guardará un array con todas las opciones. En este caso no se puede utilizar el atributo app:useSimpleSummaryProvider.

 <MultiSelectListPreference
     android:key="preference_options_key"
     android:title="@string/preference_options"
     android:summary="@string/preference_options_summary"
     android:entries="@array/options_entries"
     android:entryValues="@array/options_entry_values"
     android:dialogTitle="@string/dialog_title_options"/>

Autoevaluación

Ocultar

Retroalimentación

Falso

La preferencia MultiSelectListPreference no admite el atributo app:useSimpleSummaryProvider porque el usuario puede seleccionar más de un valor. Para actualizar el valor resumen se tendría que hacer mediante código.

Creado con eXeLearning (Ventana nueva)

1.3.- Mostrar la pantalla de preferencias

Ocultar

Captura pantalla de las preferencias del ejemplo a realizar

Captura del IDE Android Studio. Apache 2.0

¿Recuerdas cómo se muestra la pantalla de una actividad? En efecto, utilizando código Java .

Las nuevas versiones de Android van cambiando la implementación de algunas funcionalidades que se quedan obsoletas, y aunque siguen funcionando, es preferible utilizar las nuevas técnicas si queremos desarrollar aplicaciones para las versiones más utilizadas de forma que nuestra aplicación funcione en la mayor parte de los dispositivos móviles de forma correcta. En este caso, desde la API 11 se ha implementado una nueva forma de mostrar las preferencias y aunque sigue funcionando la anterior, la nueva técnica se desarrolla utilizando Fragments. No obstante vamos a explicar las dos formas de mostrar la interfaz gráfica.

Mediante la clase PreferenceActivity (para versiones anteriores a la API 11 aunque sigue funcionando en las versiones actuales). De la misma forma que para mostrar una pantalla o actividad necesitamos crear una clase Java que extiende de la clase Activity, para mostrar la interfaz gráfica de preferencias debemos crear una clase Java que en esta ocasión extenderá de la clase PreferenceActivity, la cual hereda de la superclase Activity. En esta clase se sobrescribe el método onCreate() de la misma forma que lo hacemos en una actividad, la única diferencia es que debemos llamar al método addPreferencesFromResource() para cargar el fichero XML que contiene el diseño de la pantalla de preferencias.
No olvides registrar la actividad que muestra las preferencias en el fichero de manifiesto.
Mediante la clase PreferenceFragment para versiones a partir de la API 11. Como ya se ha comentado, en esta ocasión se implementa utilizando fragmentos y por tanto debemos crear una nueva clase que extenderá de la clase PreferenceFragment. En esta clase es donde se sobrescribe el método onCreate() y se llama al método setPreferencesFromResource() para cargar el fichero XML que contiene el diseño de la pantalla de preferencias como veíamos en la técnica anterior. Tal y como se muestra en la siguiente imagen.

Captura del IDE Android Studio. Apache 2.0

Ahora tan sólo nos queda crear la clase Java para mostrar el fragmento que acabamos de implementar, para ello esta clase sólo extenderá de la clase Activity y debemos utilizar FragmentManager para reemplazar el contenido de la pantalla (R.id.fragmentcontainer) por el de nuestro fragmento. Como puedes ver en el código cuando el usuario pulsa sobre la opción settings del menú de la barra de acción se muestra las preferencias de la aplicación.

Recuerda que R.id.fragmentcontainer es un FrameLayout que ocupa toda la pantalla y es donde se visualizan los fragmentos.

JAVA
                    @Override
                    public boolean onOptionsItemSelected(@NonNull MenuItem item) {
                    switch (item.getItemId()) {
                    case R.id.action_settings:
                    showSettingsFragment();
                    return true;
                    default:
                    return super.onOptionsItemSelected(item);
                    }
                    }
                    public void showSettingsFragment() {
                    FragmentManager fm = getSupportFragmentManager();
                    Fragment settingsFragment = fm.findFragmentByTag(SettingsFragment.TAG);
                    if (settingsFragment == null) {
                    settingsFragment = new SettingsFragment();
                    }
                    FragmentTransaction ft = fm.beginTransaction();
                    ft.replace(R.id.fragmentcontainer, settingsFragment, SettingsFragment.TAG);
                    ft.addToBackStack(null);
                    ft.commit();
                    }

KOTLIN
                    override fun onOptionsItemSelected(item: MenuItem): Boolean {
                    return when (item.itemId) {
                    R.id.action_settings -> {
                    showSettingsFragment()
                    true
                    }
                    else -> super.onOptionsItemSelected(item)
                    }
                    }
                    fun showSettingsFragment() {
                    val fm = supportFragmentManager
                    var settingsFragment = fm.findFragmentByTag(SettingsFragment.TAG) as? SettingsFragment
                    if (settingsFragment == null) {
                    settingsFragment = SettingsFragment()
                    }
                    val ft = fm.beginTransaction()
                    ft.replace(R.id.fragmentcontainer, settingsFragment, SettingsFragment.TAG)
                    ft.addToBackStack(null)
                    ft.commit()
                    }

Reflexiona

Ocultar

Y ahora bien, ¿desde dónde puede acceder el usuario a esta pantalla en nuestra aplicación?

Autoevaluación

Ocultar

Retroalimentación

Verdadero

Es cierto porque toda actividad necesita registrarse previamente en el fichero de manifiesto de la aplicación.

Creado con eXeLearning (Ventana nueva)

1.4.- Recuperar las preferencias almacenadas

Ocultar

Ilustración que muestra un salvavidas y el icono de las preferencias: recuperar las preferencias

Megan_Rexazin (Licencia Pixabay)

Como acabamos de ver el usuario selecciona e introduce una serie de datos en la pantalla de preferencias que hemos diseñado y mostrado en el dispositivo móvil para configurar la aplicación. Pero, ¿dónde se almacenan los valores de estas opciones? ¿Cómo se pueden recuperar? ¿Se eliminan cuando salimos de la aplicación o apagamos nuestro dispositivo móvil?

De nada serviría una pantalla de preferencias donde el usuario ha elegido una configuración determinada si después no se almacena y no se pueden recuperar los datos. En realidad, este tipo de gestión de datos es transparente incluso para el programador. Android almacena internamente estas preferencias en forma de clave-valor, es decir, cada una de ellas está compuesta por una clave o identificador único y un valor asociado a ese identificador. Como desarrollador nos interesa conocer cómo manejar esas preferencias compartidas en la aplicación. Por tanto, debemos utilizar la clase androidx.preference.PreferenceManager y android.content.SharedPreferences.

Primero obtenemos una instancia de la clase SharedPreferences mediante la clase PreferenceManager:

JAVA

SharedPreferences sharedPreferences = 
    PreferenceManager.getDefaultSharedPreferences(activityContext);

KOTLIN

val sharedPreferences = 
    PreferenceManager.getDefaultSharedPreferences(activityContext)

Después recuperamos los valores de preferencias dependiendo del tipo de dato almacenado en cada una de ellas. Así podremos utilizar los siguientes métodos:

JAVA

String stringValue = sharedPreferences.getString("key_string", "default");
int intValue = sharedPreferences.getInt("key_int", 0);
float floatValue = sharedPreferences.getFloat("key_float", 0.0f);
boolean booleanValue = sharedPreferences.getBoolean("key_boolean", false);

KOTLIN

val stringValue: String? = sharedPreferences.getString("key_string", "default")
val intValue: Int = sharedPreferences.getInt("key_int", 0)
val floatValue: Float = sharedPreferences.getFloat("key_float", 0.0f)
val booleanValue: Boolean = sharedPreferences.getBoolean("key_boolean", false)

Si queremos recuperar el valor de SwitchPreference utilizaremos getBoolean(key,default_value) donde key es la clave de la preferencia especificada mediante el atributo android:key y el parámetro default_value es el valor por defecto en el caso de que el usuario no lo haya especificado.

JAVA

boolean saveUser = sharedPreferences.getBoolean("preference_saveuser_key", true);

KOTLIN

val saveUser: Boolean = sharedPreferences.getBoolean("preference_saveuser_key", true)

Evidentemente, Android hace todo esto por nosotros de forma automática y transparente, puesto que al salir de la pantalla de preferencias e incluso cerrar la aplicación posteriormente cuando volvemos a abrir esta pantalla tendremos los valores que se introdujeron por última vez.

Reflexiona

Ocultar

Entonces, ¿para qué puede servirnos recuperar estos datos si ya lo hace Android por nosotros?

Ejercicio Resuelto

Ocultar

Siguiendo el ejemplo de nuestra pantalla de preferencias en cualquiera de las versiones, debes crear una opción en el menú principal de la actividad llamado “Ver Preferencias” que nos muestre los datos almacenados en cada uno de los controles de preferencia.

Retroalimentación

Importa uno de los proyectos de ejemplo de preferencias del apartado “Mostrar la pantalla de preferencias”.
Crea el fichero XML activity_main.xml en el directorio /res/menu/ y añade las opciones del menú.

En el fichero MainActivity.java implementa el método onOptionsItemSelected(MenuItem item) y cuando se haya seleccionado la opción action_show_settings se ejecutará un método que muestra los valores almacenados:

  public boolean onOptionsItemSelected(MenuItem item) {

        switch (item.getItemId()) {

         .................................

            case R.id.action_show_settings:

                showPreferences();

                return true;

           case R.id.action_settings:

                showSettingsFragment();

                return true;

            default:

                return super.onOptionsItemSelected(item);

  private void showPreferences() {

     SharedPreferences sharedPreferences =

            PreferenceManager.getDefaultSharedPreferences(this);

     String user = sharedPreferences.getString("preference_user_key","No declarado");

     Boolean saveuser=sharedPreferences.getBoolean("preference_saveuser_key",true);

     String nameavatar =

            sharedPreferences.getString("preference_name_avatar_key","No declarado");

     int age = sharedPreferences.getInt("preference_age_key",18);

     String level = sharedPreferences.getString("preference_level","1");

     Set<String> n = new HashSet<>(); n.add("sonido");

     Set<String> options=

            sharedPreferences.getStringSet("preference_options_key",n);

     StringBuilder mensaje = new StringBuilder("Nombre de usuario: "+user +"\n");

     mensaje.append("Salvar usuario: "+saveuser+"\n");

     mensaje.append("Nombre avatar: "+nameavatar+"\n");

     mensaje.append("Edad: "+age+"\n");

     mensaje.append("Nivel: "+level+"\n");

     mensaje.append("Opciones: "+options.toString());

     Toast.makeText(this,mensaje,Toast.LENGTH_SHORT).show();

Sólo queda desplegar la aplicación en un emulador y ver los resultados al pulsar sobre la opción del menú que ya existía para abrir la pantalla de preferencias y por supuesto probar la opción que muestre los valores de preferencia almacenados.

Para saber más

Ocultar

En este apartado se ha explicado la utilidad de la clase SharedPreferences, unida a la clase Preferences que muestran los valores clave-valor mediante controles.

Esta clase también tiene otra utilidad que es guardar valores en un fichero de preferencias, aunque NO tenga interfaz gráfica de preferencias. Este es el supuesto de querer guardar cierta información de la aplicación que siempre esté accesible.

Cómo guardar datos de pares clave-valor

Creado con eXeLearning (Ventana nueva)

2.- Ficheros

Caso práctico

Ocultar

Programador trabajando delante de su ordenador.

Ministerio de Educación. (Uso educativo no comercial.)

Trabajando con las preferencias, Juan ha comprobado cómo se pueden almacenar ficheros XML de forma casi transparente para el desarrollador para después recuperar esa información. Ahora bien, ¿se puede guardar otro tipo de ficheros? ¿Dónde se pueden almacenar? ¿El proceso es tan sencillo como los ficheros de preferencias?

Juan recuerda que el núcleo de Android está basado en Linux y además se utiliza Java como lenguaje de programación, por tanto, intuye que no será muy diferente a lo que estudió en el módulo de Programación en el ciclo formativo DAM sobre la gestión de ficheros.

Ocultar

Clker-Free-Vector-Images (Licencia Pixabay)

La gestión de ficheros en Android se basa en el paquete java.io. Si se ha trabajado previamente con Java, resultará sencillo manipular ficheros en Android. En caso contrario, con algo de práctica se comprenderán los métodos necesarios para realizar operaciones de lectura y escritura.

Debido a las particularidades del almacenamiento en dispositivos móviles, es fundamental considerar el lugar donde se ubicarán los ficheros. Estos dispositivos cuentan con una capacidad limitada, por lo que se distinguen dos ubicaciones principales:

Memoria interna: almacenamiento privado para la aplicación, accesible únicamente por esta. Incluye tanto la carpeta de archivos internos (/data/data/tu.paquete/) como los recursos de solo lectura del paquete (assets/, res/raw/).
Memoria externa: almacenamiento compartido, como una tarjeta SD o una partición accesible por otras aplicaciones. En versiones anteriores de Android se permitía el acceso directo; sin embargo, a partir de Android 10 (API 29) cada aplicación dispone de una carpeta privada en /storage/emulated/0/Android/data/tu.paquete/. Para acceder a otras ubicaciones comunes, es necesario utilizar permisos y mecanismos como MediaStore o el Storage Access Framework.

Veamos cómo se gestionan los ficheros en función del lugar en el que se almacenan.

Creado con eXeLearning (Ventana nueva)

2.1.- Almacenamiento en memoria interna

Ocultar

CristianIS (Licencia Pixabay )

Cuando trabajamos con ficheros en la memoria interna del dispositivo debemos tener en cuenta que ésta es muy limitada y no debemos sobrecargarla. Cuando se instala una aplicación en el dispositivo móvil, el sistema reserva un espacio para que se almacenen los ficheros de datos necesarios. Este espacio no hay que confundirlo con la estructura de carpetas del proyecto de la aplicación. La ruta de la memoria interna de una aplicación es la siguiente:

/data/data/paquete.aplicación/files/

Algunos de los métodos que utilizaremos para manipular los ficheros son:

openFileOutput(): abrir un fichero en modo escritura.
openFileInput(): abrir un fichero en modo lectura.
getFilesDir(): recuperar la ruta absoluta del directorio donde se encuentran los ficheros internos.
getDir(): crear o abrir un directorio interno de la aplicación.
deleteFile(): eliminar un fichero.
fileList(): devuelve un array con todos los ficheros internos de la aplicación.
openRawResource(): leer los ficheros de recursos almacenados en la carpeta res/raw/.

Los ficheros que se almacenan en la memoria interna son de carácter privado, por eso siempre utilizamos MODE_PRIVATE. En la versión API 17 se ha declarado como obsoleto el uso de los otros dos métodos de acceso (MODE_WORLD_READABLE y MODE_WORLD_WRITABLE) debido al riesgo de que una aplicación pueda manipular ficheros internos de otra. Por tanto, lo más aconsejable es utilizar el modo privado. Veamos el código necesario para guardar una cadena de texto en un fichero de la memoria interna:

JAVA
                    try {
                    OutputStreamWriter fout = new OutputStreamWriter(
                    openFileOutput("fichero.txt", Context.MODE_PRIVATE)
                    );
                    fout.write("Esto es un texto de prueba");
                    fout.close();
                    } catch (IOException e) {
                    e.printStackTrace();
                    }

KOTLIN
                    try {
                    val fout = OutputStreamWriter(
                    openFileOutput("fichero.txt", Context.MODE_PRIVATE)
                    )
                    fout.write("Esto es un texto de prueba")
                    fout.close()
                    } catch (e: IOException) {
                    e.printStackTrace()
                    }

Y si queremos leer el fichero de texto anterior podríamos escribir algo así:

JAVA
                    try {
                    BufferedReader fin = new BufferedReader(
                    new InputStreamReader(openFileInput("fichero.txt"))
                    );
                    String texto = fin.readLine();
                    fin.close();
                    } catch (IOException e) {
                    e.printStackTrace();
                    }

KOTLIN
                    try {
                    val fin = BufferedReader(
                    InputStreamReader(openFileInput("fichero.txt"))
                    )
                    val texto: String? = fin.readLine()
                    fin.close()
                    } catch (e: IOException) {
                    e.printStackTrace()
                    }

¿Cómo podemos consultar la ubicación del fichero almacenado?

Android Studio incorpora un explorador de archivos que permite visualizar el sistema de ficheros del dispositivo. Puedes abrirlo desde View > Tool Windows > Device File Explorer. En la ventana que se abre podemos ver la pestaña Device File Explorer y navegar hasta la ruta /data/data/tu.paquete/files.

Para saber más

Ocultar

Si necesitas recordar los conceptos sobre la gestión de ficheros en Java puedes consultar el siguiente enlace donde se ven algunos ejemplos.

Lectura y escritura de ficheros en Java

Creado con eXeLearning (Ventana nueva)

2.1.1.- Almacenamiento en los recursos de la aplicación

Ocultar

Ilustración de varias carpetas clasificadoras de diferentes colores

OpenClipart-Vectors (Licencia de contenido de Pixabay)

Creamos en esta carpeta un fichero que deseamos consultar desde la propia aplicación y para leerlo podemos hacerlo así:

JAVA

try {
    // Abrimos el fichero de recursos de la carpeta raw en modo lectura.
    InputStream fraw = getResources().openRawResource(R.raw.fich_raw);
    // Leemos el fichero.
    BufferedReader brin = new BufferedReader(new InputStreamReader(fraw));
    // Guardamos el contenido en la variable texto.
    String texto = brin.readLine();
    // Cerramos el fichero.
    fraw.close();
} catch (IOException e) {
    e.printStackTrace();
}

KOTLIN

try {
    // Abrimos el fichero de recursos de la carpeta raw en modo lectura.
    val fraw = resources.openRawResource(R.raw.fich_raw)
    // Leemos el fichero.
    val brin = BufferedReader(InputStreamReader(fraw))
    // Guardamos el contenido en la variable texto.
    val texto: String? = brin.readLine()
    // Cerramos el fichero.
    fraw.close()
} catch (e: IOException) {
    e.printStackTrace()
}

En el ejemplo anterior vemos la utilización del método openRawResource() que abre el fichero de recurso cuyo identificador le pasamos como parámetro. El resto del código es similar a leer un fichero de texto. Obviamente en la carpeta de recursos /res/raw/ podremos tener almacenados cualquier tipo de fichero binario (imagen, vídeo, etc.) que también podremos leer tal y como se hace en Java.

Autoevaluación

Ocultar

Retroalimentación

Verdadero

La afirmación es verdadera, ese es el espacio que Android reserva para los datos internos de tu aplicación.

Retroalimentación

Falso

La afirmación es falsa porque en esta carpeta sólo tendremos acceso de lectura, no de escritura.

Creado con eXeLearning (Ventana nueva)

2.2.- Almacenamiento en memoria externa

Ocultar

kalhh (Licencia Pixabay)

El almacenamiento de ficheros en memoria externa suele hacerse en las tarjetas de memoria SD extraíbles. Estas tarjetas suelen tener mayores capacidades y los ficheros que almacenamos en ellas pueden corresponder a archivos privados de la aplicación que se instala en la tarjeta o bien ficheros públicos compartidos por varias aplicaciones. En cualquier caso, para trabajar con los ficheros almacenados en este tipo de memoria, debemos tener en cuenta varios aspectos:

Seguridad y permiso del usuario:

En las versiones actuales de Android, las aplicaciones acceden a la memoria externa principalmente dentro de su espacio privado usando getExternalFilesDir(), sin necesidad de permisos especiales. Para acceder a archivos públicos fuera de ese espacio, se debe usar el Storage Access Framework, que requiere la autorización explícita del usuario. Los permisos amplios como WRITE_EXTERNAL_STORAGE están muy limitados y, en muchos casos, obsoletos. Así, se protege la privacidad y seguridad del usuario evitando accesos no controlados a sus archivos. Por eso, lo habitual es trabajar con almacenamiento privado o con APIs que garantizan permisos temporales y específicos.

Para casos muy específicos donde se requiere acceso amplio a la memoria externa (por ejemplo, un explorador de archivos), la aplicación debe solicitar el permiso MANAGE_EXTERNAL_STORAGE, que tiene un proceso de revisión estricto en Google Play y debe justificarse adecuadamente.

Por tanto, en la mayoría de los casos, no es necesario incluir ni solicitar el permiso WRITE_EXTERNAL_STORAGE en el manifiesto ni en tiempo de ejecución.
Estado de la tarjeta de memoria: la tarjeta SD puede no estar presente en el dispositivo o aunque esté insertada no estar debidamente montada. Para ello será necesario, antes de comenzar a tratar los ficheros, recuperar su estado de la siguiente forma:

JAVA y KOTLIN

Environment.getExternalStorageState()

Android devolverá una constante dependiendo del estado en el que se encuentre la tarjeta SD. Aquí tienes algunos ejemplos:
- Environment.MEDIA_MOUNTED: la tarjeta está montada y disponible para lectura y escritura.
- Environment.MEDIA_MOUNTED_READ_ONLY: la tarjeta está montada en modo lectura.
- Environment.MEDIA_UNMOUNTED: la tarjeta está insertada, pero no se encuentra montada.
- Environment.MEDIA_REMOVED: la tarjeta no está insertada.

Acceso al directorio de la tarjeta de memoria: utilizamos uno de los siguientes métodos:

getExternalFilesDir() devuelve la ruta de una carpeta determinada de nuestra aplicación. Podemos pasar como parámetro null y nos recuperará la carpeta raíz de la aplicación en el directorio:
```
/mnt/sdcard/Android/data/paquete.aplicación/files/
```
getExternalStoragePublicDirectory() devuelve la ruta a una carpeta pública, pero está obsoleta desde Android 10; se recomienda usar el Storage Access Framework o APIs específicas para acceder a archivos compartidos.

En Android podemos indicar alguno de los subdirectorios definidos por alguna de las siguientes constantes para clasificar los contenidos, como por ejemplo se hace en la galería multimedia.

Subcarpetas multimedia
Constante	¿Qué almacena?	¿Dónde se almacena?
DIRECTORY_PICTURES	Ficheros de imágenes, fotos	Pictures/
DIRECTORY_MOVIES	Ficheros de películas.	Movies/
DIRECTORY_MUSIC	Ficheros de música.	Music/
DIRECTORY_RINGTONES	Ficheros de tonos.	Ringtones/

Configurar la memoria externa en el emulador: para probar el correcto funcionamiento del almacenamiento de ficheros en memoria externa debemos configurar en un emulador (AVD) la opción SD Card Size con un tamaño de memoria adecuado. Para visualizar los ficheros utilizaremos la misma opción que en los ficheros internos (File Explorer).

Para saber más

Ocultar

Para profundizar en el almacenamiento de datos en Android y entender mejor cómo gestionar ficheros de forma segura y eficiente, puedes consultar los siguientes recursos oficiales de la documentación de Android:

Almacenamiento de datos en Android, donde se explican los distintos tipos de almacenamiento disponibles, incluyendo memoria interna, externa, preferencias y bases de datos.

Almacenamiento de datos en Android

Scoped Storage (Android 10+), donde se detalla el nuevo modelo de acceso restringido al almacenamiento externo introducido en Android 10.

Scoped Storage (Android 10+)

Creado con eXeLearning (Ventana nueva)

2.2.1.- Escribiendo en memoria externa

Ocultar

Clker-Free-Vector-Images (Pixabay)

Para escribir un fichero en la memoria externa dentro del espacio reservado a nuestra aplicación en la tarjeta SD, podemos utilizar el siguiente código, después de comprobar que la memoria está montada. Este espacio privado garantiza que los ficheros creados sean accesibles únicamente por nuestra aplicación, lo que evita problemas de privacidad o conflictos con otras aplicaciones. Además, al escribir aquí no necesitamos solicitar permisos especiales, ya que Android administra automáticamente el acceso para preservar la seguridad y la integridad de los datos.

JAVA
                    public void escribirFichero(Context context) {
                    String estado = Environment.getExternalStorageState();
                    if (Environment.MEDIA_MOUNTED.equals(estado)) {
                    File file = new File(context.getExternalFilesDir(null), "fichero.txt");
                    try (OutputStreamWriter fout = new OutputStreamWriter(new FileOutputStream(file))) {
                    fout.write("Texto de prueba almacenado en tarjeta SD.");
                    } catch (IOException e) {
                    e.printStackTrace();
                    // Manejar el error (por ejemplo, notificar al usuario)
                    }
                    } else {
                    // La memoria externa no está disponible o no está montada
                    // Manejar este caso según convenga
                    }
                    }

KOTLIN
                    fun escribirFichero(context: Context) {
                    val estado = Environment.getExternalStorageState()
                    if (estado == Environment.MEDIA_MOUNTED) {
                    val file = File(context.getExternalFilesDir(null), "fichero.txt")
                    try {
                    OutputStreamWriter(FileOutputStream(file)).use { fout ->
                    fout.write("Texto de prueba almacenado en tarjeta SD.")
                    }
                    } catch (e: IOException) {
                    e.printStackTrace()
                    // Manejar el error (por ejemplo, mostrar mensaje)
                    }
                    } else {
                    // La memoria externa no está disponible o montada
                    // Manejar esta situación si es necesario
                    }
                    }

Este método garantiza que el fichero se escriba en un área privada de la memoria externa asignada a nuestra aplicación. No es necesario pedir permisos especiales para escribir aquí.

Para almacenar ficheros públicos, que puedan ser accesibles por otras aplicaciones o por el usuario, se recomienda usar el Storage Access Framework, que permite al usuario elegir la ubicación y concede permisos temporales seguros.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

2.2.2.- Leyendo de la memoria externa

Ocultar

TheUjulala (Pixabay)

Para leer un fichero almacenado en la memoria externa dentro del espacio privado reservado para nuestra aplicación, no es necesario solicitar permisos especiales, siempre que accedamos mediante la ruta obtenida con getExternalFilesDir().

Este método asegura que los datos sean accesibles únicamente desde nuestra aplicación, y es la forma recomendada de trabajar con almacenamiento externo en las versiones actuales de Android.

El siguiente código muestra cómo leer un fichero de texto previamente guardado en este directorio privado:

JAVA

public void leerFichero(Context context) {
    File file = new File(context.getExternalFilesDir(null), "fichero.txt");
    if (file.exists()) {
        try (BufferedReader br = new BufferedReader(
                new InputStreamReader(new FileInputStream(file)))) {
            String linea = br.readLine();
            // Procesar la línea leída
        } catch (IOException e) {
            e.printStackTrace();
            // Manejar el error (por ejemplo, mostrar un mensaje al usuario)
        }
    }
}

KOTLIN

fun leerFichero(context: Context) {
    val file = File(context.getExternalFilesDir(null), "fichero.txt")
    if (file.exists()) {
        try {
            BufferedReader(InputStreamReader(FileInputStream(file))).use { br ->
                val linea = br.readLine()
                // Procesar la línea leída
            }
        } catch (e: IOException) {
            e.printStackTrace()
            // Manejar el error (por ejemplo, mostrar mensaje)
        }
    }
}

En ambos casos, comprobamos si el fichero existe y lo leemos utilizando un BufferedReader. Este enfoque es seguro y está alineado con las políticas de acceso a almacenamiento en Android modernas.

Creado con eXeLearning (Ventana nueva)

3.- Base de Datos

Caso práctico

Ocultar

Ministerio de Educación. (Uso educativo no comercial.)

María es experta en base de datos, y desde que cursó el módulo “Base de Datos” en el ciclo de grado superior de DAM ha seguido estudiando todo tipo de sistemas gestores de datos. Cuando comenzaron su andadura en Android, estudiando la arquitectura de la plataforma se percató de que se utilizaba un motor de base de datos específico llamado SQLite, el cual desconocía. Ahora ha llegado el momento de aprender un poco más sobre Android: ¿cómo gestiona Android una base de datos? ¿Se utilizará también el lenguaje SQL?

Ocultar

Ilustración que representa el icono de base de datos (Un cilindro formado por varios discos)

OpenClipart-Vectors(Licencia Pixabay)

Las bases de datos ofrecen importantes ventajas en el manejo estructurado y eficiente de la información frente a los sistemas de ficheros tradicionales. Aunque pueda parecer que su uso está limitado en dispositivos móviles por sus restricciones de recursos, Android integra SQLite, un motor de base de datos ligero y adecuado para este entorno.

Tamaño reducido y bajo consumo de recursos.
Basado en el modelo relacional y en el lenguaje SQL.
Soporta transacciones que garantizan la integridad de los datos.
Es una solución de código abierto ampliamente utilizada.

Gracias a estas cualidades, SQLite es una opción fiable para almacenar y gestionar datos localmente en aplicaciones Android, adaptándose bien a las limitaciones típicas de los dispositivos móviles. En apartados posteriores se abordará Room, una librería moderna que simplifica y mejora el uso de bases de datos en Android.

Para saber más

Ocultar

Si deseas conocer un poco más SQLite te invitamos a que visites su página oficial.

Página oficial de SQLite.

Creado con eXeLearning (Ventana nueva)

3.1.- Estructura de SQLite

Ocultar

Logotipo de SQLite, formado por un recuadro azul, medio tapado por una pluma, y al lado el texto SQLite

Richard Hipp / Mike Toews (Dominio público)

¿Cómo se integra SQLite con Android?

Android incorpora el motor de base de datos SQLite como solución integrada para el almacenamiento estructurado local. Ofrece acceso directo a bases de datos relacionales a través de clases específicas en la API de Android. A continuación, se presentan las principales clases utilizadas para gestionar una base de datos de forma tradicional:

SQLiteOpenHelper: facilita la creación, apertura y actualización de bases de datos. Sus métodos más relevantes son:
- onCreate(): se ejecuta cuando se crea la base de datos por primera vez.
- onUpgrade(): se ejecuta cuando se requiere actualizar la estructura de la base de datos.
- getReadableDatabase(): abre la base de datos en modo solo lectura.
- getWritableDatabase(): abre la base en modo lectura y escritura.
- close(): cierra la conexión con la base de datos.
SQLiteDatabase: permite ejecutar sentencias SQL y manipular registros:
- insert(): añade un nuevo registro.
- update(): modifica registros existentes.
- delete(): elimina registros.
- execSQL(): ejecuta comandos SQL que no devuelven resultados.
- rawQuery(): ejecuta consultas completas en SQL y devuelve un cursor.
- query(): permite consultas mediante parámetros estructurados.
- isOpen(): comprueba si la base está actualmente abierta.
Cursor: gestiona el recorrido por los resultados obtenidos de una consulta:
- moveToFirst(): posiciona en el primer registro.
- moveToNext(): avanza al siguiente registro.
- getString(), getInt(), getFloat(), getLong(): obtienen valores de las columnas.
- getColumnCount(): devuelve el número de columnas presentes en la consulta.

Estas clases permiten implementar operaciones básicas y avanzadas sobre bases de datos locales de forma directa. Son especialmente útiles cuando se necesita un control detallado sobre las transacciones y el modelo de datos.

Para saber más

Ocultar

En la documentación oficial de Android puedes encontrar la API con todas las clases que incorpora SQLite y que se incluyen en el paquete android.database.sqlite.

SQLite en Android

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

3.2.- Creación de una base de datos

Ocultar

Ilustración de dos símbolos de Bases de datos, dos cilindros compuestos por varios discos apilados cada uno

OpenClipart-Vectors (Licencia de contenido Pixabay)

¿Cómo empezamos a trabajar con SQLite en Android?

Para gestionar bases de datos SQLite en Android, se suele utilizar una clase auxiliar que extienda de SQLiteOpenHelper. Esta clase se encarga de crear y actualizar la base de datos, así como de abrir conexiones de lectura y escritura cuando sea necesario.

Declaración de la clase

JAVA 

public class MiBaseDatosHelper extends SQLiteOpenHelper {
    
    public MiBaseDatosHelper(Context context) {
        super(context, "MiBaseDatos.db", null, 1);
    }

    @Override
    public void onCreate(SQLiteDatabase db) {
        db.execSQL("CREATE TABLE miTabla (campo1 INTEGER, campo2 TEXT)");
    }

    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
        db.execSQL("DROP TABLE IF EXISTS miTabla");
        db.execSQL("CREATE TABLE miTabla (campo1 INTEGER, campo2 TEXT)");
    }
}

KOTLIN 

class MiBaseDatosHelper(context: Context) :
    SQLiteOpenHelper(context, "MiBaseDatos.db", null, 1) {

    override fun onCreate(db: SQLiteDatabase) {
        db.execSQL("CREATE TABLE miTabla (campo1 INTEGER, campo2 TEXT)")
    }

    override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) {
        db.execSQL("DROP TABLE IF EXISTS miTabla")
        db.execSQL("CREATE TABLE miTabla (campo1 INTEGER, campo2 TEXT)")
    }
}

El constructor de SQLiteOpenHelper recibe el Context, el nombre de la base de datos, un CursorFactory (que habitualmente es null) y el número de versión de la base de datos.

El método onCreate() se ejecuta automáticamente la primera vez que se accede a la base de datos y su función es crear las tablas necesarias. Para ejecutar la sentencia SQL usamos el método execSQL() de la clase SQLiteDatabase.

Cuando cambiamos la estructura de la base de datos (por ejemplo, añadiendo nuevas columnas), es necesario actualizar el número de versión y definir cómo debe migrarse en el método onUpgrade(). En este ejemplo simplificado, se borra la tabla anterior y se crea una nueva. En una aplicación real, deberíamos conservar los datos realizando una migración controlada.

Con esta clase auxiliar ya podemos gestionar la creación, actualización y conexión a una base de datos SQLite dentro de una aplicación Android.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

3.3.- Operaciones sobre una base de datos

Ocultar

Ilustración de un destornillador y una llave fija, cruzados en forma de X.

Clker-Free-Vector-Images (Licencia Pixabay)

Y ahora, ¿cuándo y cómo utilizamos esta clase auxiliar en nuestra aplicación Android?

La utilizaremos cada vez que queramos lanzar una actividad donde se vaya a realizar alguna operación sobre la base de datos.

Estas operaciones se pueden clasificar en dos grupos dependiendo de si se recupera o no algún resultado tras su ejecución. Así pues, tendremos:

Inserción, actualización y eliminación de registros, que no devuelven ningún resultado: solo se modifican datos.
Selección de registros, que retorna un conjunto de datos dentro de un objeto Cursor.

Como ya hemos visto, las diferentes pantallas de Android se lanzan desde sus respectivas clases codificadas en Java o Kotlin. Aquellas actividades que realicen algún tipo de operación sobre la base de datos necesitan apoyarse en la clase auxiliar.

Dejando a un lado el diseño visual de las pantallas (definido en res/layout), nos centramos en la implementación de las clases de actividad. Los pasos básicos para trabajar con la base de datos serían:

Crear un objeto de la clase SQLiteOpenHelper para abrir la base de datos. Al constructor le pasamos el Context (la propia actividad), el nombre de la base de datos, un objeto CursorFactory (que normalmente será null) y el número de versión de la BD. Según el estado actual de la base de datos pueden suceder varios casos:
1. Si la base de datos existe y su versión coincide con la que indicamos, se establece la conexión normalmente.
2. Si existe, pero la versión es antigua, se ejecuta automáticamente el método onUpgrade() para actualizarla.
3. Si no existe, se ejecuta el método onCreate() y luego se abre la conexión.
Abrir la base de datos en modo lectura o escritura según la operación que se vaya a realizar.
Comprobar que la base de datos está abierta y ejecutar las operaciones necesarias utilizando los métodos disponibles.
Finalmente, cerrar siempre la base de datos usando close().

El código podría ser muy similar al que mostramos a continuación:

JAVA

//Creamos un objeto de la clase auxiliar.
MiBaseDatosHelper bdhelp = 
                 new MiBaseDatosHelper(this, "nombreBD", null, 1);

//Abrimos en modo lectura y escritura la base de datos 'MiBD' 
SQLiteDatabase bd = bdhelp.getWritableDatabase();

//Si la base de datos está abierta.
if(bd.isOpen())
{
     //Aquí hay que añadir el código necesario para realizar 
     //cualquier tipo de operación sobre la base de datos.
     //Veremos algunos métodos en los apartados siguientes.

     //Cerramos la base de datos
      bd.close();
}

KOTLIN

// Creamos un objeto de la clase auxiliar
val bdhelp = MiBaseDatosHelper(this, "nombreBD", null, 1)

// Abrimos en modo lectura y escritura la base de datos
val bd = bdhelp.writableDatabase

// Si la base de datos está abierta
if (bd.isOpen) {
    // Aquí se añadiría el código necesario para realizar 
    // cualquier tipo de operación sobre la base de datos.
    // Veremos algunos métodos en los apartados siguientes.

    // Cerramos la base de datos
    bd.close()
}

Creado con eXeLearning (Ventana nueva)

3.3.1.- Inserción, actualización y eliminación de registros

Ocultar

Icono de un cajón en el que se está introduciendo una carpeta con documentos

Everaldo Coelho and YellowIcon ( GNU Lesser GPL )

Revisando la clase SQLiteDatabase nos damos cuenta de que existen varios métodos para ejecutar sentencias SQL. Entonces, ¿cuáles son los más apropiados para cada tipo de operación? ¿Se pueden emplear indistintamente aunque la operación no devuelva ningún resultado?

Android nos proporciona una serie de métodos para que trabajemos sobre la base de datos dependiendo del tipo de operación que se realiza sobre la misma. En este apartado vamos a trabajar con los métodos necesarios para realizar operaciones de manipulación de datos, es decir, la inserción, la actualización y la eliminación de registros que recordamos no devuelven ningún registro.

Empezaremos viendo una forma muy sencilla: el método execSQL(), que recibe como parámetro una sentencia SQL completa y la ejecuta. Aquí tienes algunos ejemplos:

JAVA

bd.execSQL("INSERT INTO miTabla (campo1, campo2) VALUES (1, 'unTexto')");
bd.execSQL("UPDATE miTabla SET campo2 = 'otroTexto' WHERE campo1 = 1");
bd.execSQL("DELETE FROM miTabla WHERE campo1 = 1");

KOTLIN

bd.execSQL("INSERT INTO miTabla (campo1, campo2) VALUES (1, 'unTexto')")
bd.execSQL("UPDATE miTabla SET campo2 = 'otroTexto' WHERE campo1 = 1")
bd.execSQL("DELETE FROM miTabla WHERE campo1 = 1")

Otra opción que se incluye en Android es utilizar métodos en los que se separan las tablas, los valores y las condiciones en parámetros. Estos métodos son: insert(), update() y delete().

El método insert() recibe tres parámetros en el siguiente orden:

Nombre de la tabla.
Condiciones: normalmente en la operación de inserción este valor será null porque no se precisan.
Valores del registro: utilizaremos un objeto ContentValues para almacenarlos en forma de clave-valor.

Aquí tienes un ejemplo de inserción:

JAVA

// Creamos el objeto ContentValues con los valores del registro.
ContentValues miRegistro = new ContentValues();
miRegistro.put("campo1", 1);
miRegistro.put("campo2", "unTexto");

// Insertamos el registro.
bd.insert("miTabla", null, miRegistro);

KOTLIN

// Creamos el objeto ContentValues con los valores del registro.
val miRegistro = ContentValues().apply {
    put("campo1", 1)
    put("campo2", "unTexto")
}

// Insertamos el registro.
bd.insert("miTabla", null, miRegistro)

El método update() recibe cuatro parámetros en el siguiente orden:

Nombre de la tabla.
Valores: el objeto ContentValues como en el caso anterior.
Condición: la cláusula WHERE de la sentencia que podemos dejar a null si no la necesitamos.
Argumentos de la condición: que podemos dejar a null si no los necesitamos.

Aquí tienes un ejemplo de actualización:

JAVA

// Valores a actualizar.
ContentValues miRegistro = new ContentValues();
miRegistro.put("campo2", "otroTexto");

// Actualizar el registro.
bd.update("miTabla", miRegistro, "campo1=1", null);

KOTLIN

// Valores a actualizar.
val miRegistro = ContentValues().apply {
    put("campo2", "otroTexto")
}

// Actualizar el registro.
bd.update("miTabla", miRegistro, "campo1=1", null)

El método delete() recibe tres parámetros en el siguiente orden:

Nombre de la tabla.
Condición: la cláusula WHERE de la sentencia que podemos dejar a null si no la necesitamos.
Argumentos de la condición: que podemos dejar a null si no los necesitamos.

Aquí tienes un ejemplo de eliminación:

JAVA y KOTLIN

// Eliminamos el registro.
bd.delete("miTabla", "campo1=1", null);

En los métodos delete() y update() hemos visto el parámetro de argumentos de la condición. Este parámetro lo podemos utilizar para simplificar la cadena de texto que pasamos como condición. Para ello, utilizamos un array con los valores de cada argumento en el mismo orden que aparecerán en la cláusula WHERE y en la condición introducimos el carácter (?) por cada valor que deseamos reemplazar. Veamos un ejemplo:

JAVA

String[] argumentos = new String[]{"valor1", "valor2"};
bd.update("miTabla", miRegistro, "campo2=? OR campo2=?", argumentos);

KOTLIN

val argumentos = arrayOf("valor1", "valor2")
bd.update("miTabla", miRegistro, "campo2=? OR campo2=?", argumentos)

También se puede utilizar este parámetro en el método execSQL():

JAVA

String[] argumentos = new String[]{"valor1", "valor2"};
bd.execSQL("DELETE FROM miTabla WHERE campo2=? OR campo2=?", argumentos);

KOTLIN

val argumentos = arrayOf("valor1", "valor2")
bd.execSQL("DELETE FROM miTabla WHERE campo2=? OR campo2=?", argumentos)

Para saber más

Ocultar

Es recomendable que consultes cada uno de los métodos que se han visto en el apartado en la documentación oficial de Android.

Documentación oficial de la clase SQLiteDatabase

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

3.3.2.- Recuperación o consulta de registros

Ocultar

Icono de una mano sosteniendo la bola del mundo.

Everaldo Coelho and YellowIcon ( GNU Lesser GPL )

Ya conocemos las distintas formas de manipular los registros con SQLite; ahora vamos a aprender a recuperar los registros y mostrarlos.

Si nos fijamos en la clase SQLiteDatabase encontramos dos métodos que nos pueden servir: rawQuery() y query().

¿En qué situación utilizamos cada uno?

Al igual que pasa en las operaciones de manipulación de registros, vamos a tener dos formas de ejecutar una sentencia de consulta:

rawQuery(): ejecuta directamente la sentencia SQL de consulta que pasamos como parámetro.
query(): utiliza varios parámetros para construir la sentencia a ejecutar.

En cualquier caso, la ejecución de una sentencia de consulta nos devolverá un conjunto de registros en un objeto de tipo Cursor que hereda de la clase SQLiteCursor. Este cursor nos permite procesar de forma individual cada fila del resultado de la consulta. Inicialmente, este cursor apunta a la posición previa de la primera fila, con lo cual tenemos que mover el cursor al primer registro mediante el método booleano moveToNext(). A continuación, iremos iterando por cada fila hasta llegar al final del resultado, donde el método moveToNext() devolverá el valor false indicando que no hay más filas que procesar.

Veamos la primera opción de implementación, bastante sencilla, utilizando el método rawQuery(). Fíjate cómo también se podría pasar como segundo parámetro los argumentos de la condición tal y como vimos en el apartado anterior. En este ejemplo se pone a null porque no se necesita.

JAVA

Cursor cur = bd.rawQuery("SELECT campo1, campo2 FROM miTabla", null);

KOTLIN

val cur = bd.rawQuery("SELECT campo1, campo2 FROM miTabla", null)

Para utilizar el método query() debemos tener en cuenta los parámetros que se pasan:

Nombre de la tabla.
Array con los nombres de campos.
Condición: la cláusula WHERE de la sentencia.
Argumentos de la condición: que podemos dejar a null si no los necesitamos o bien pasarlos como parámetros en un array.
Cláusula GROUP BY que podemos dejar a null si no los necesitamos.
Cláusula HAVING que podemos dejar a null si no los necesitamos.
Cláusula ORDER BY que podemos dejar a null si no los necesitamos.

Aquí se muestra un ejemplo de recuperación de registros utilizando este método:

JAVA

String[] misCampos = new String[] {"codigo", "nombre"};
Cursor cur = bd.query("miTabla", misCampos, "campo1=1", null, null, null, null);

KOTLIN

val misCampos = arrayOf("codigo", "nombre")
val cur = bd.query("miTabla", misCampos, "campo1=1", null, null, null, null)

Una vez recuperados los registros en el objeto Cursor, utilizamos los métodos moveToFirst() y moveToNext() que devuelven true en caso de haber realizado correctamente el movimiento correspondiente, y los métodos get*(índice_columna) para obtener el valor de cada columna a través del índice y según su tipo de dato como muestra el siguiente ejemplo:

JAVA

if (cur.moveToFirst()) {
    do {
        int var1 = cur.getInt(0);
        String var2 = cur.getString(1);
    } while (cur.moveToNext());
}

KOTLIN

if (cur.moveToFirst()) {
    do {
        val var1 = cur.getInt(0)
        val var2 = cur.getString(1)
    } while (cur.moveToNext())
}

Con los valores de los campos guardados en las distintas variables, ya podremos mostrarlos por pantalla de la forma que más nos interese.

Para saber más

Ocultar

Además de los métodos utilizados para recorrer el cursor y obtener los valores de sus campos, puedes consultar otros métodos que te pueden ser útiles en la documentación oficial de Android.

Documentación oficial de la clase Cursor

Autoevaluación

Ocultar

Retroalimentación

Falso

La afirmación es falsa porque execSQL() se utiliza exclusivamente para sentencias de manipulación de registros (inserción, actualización y eliminación) que no devuelven ningún registro.

Creado con eXeLearning (Ventana nueva)

4.- Room

Caso práctico

Ocultar

María sentada, trabajando escribiendo con un ordenador, mirando a la pantalla y tecleando. Ada, una mujer con pelo corto y sonriente, mirando al frente. Sobre ellos, el texto Ada, María y Juan.

Ministerio de Educación. (Uso educativo no comercial.)

Ada ha hablado con del departamento de I+D+I y ven conveniente conocer la nueva librería que Google ha lanzado para trabajar con base de datos: Room.

Ada ha pensado en María y Juan que ya conocen la biblioteca androidx.*. Efectivamente Juan se da cuenta que Room es una nueva herramienta que pertenece a los componentes de la arquitectura de Jetpack, pero, ¿en qué consiste Jetpack?¿Cómo funciona Room? ¿Qué ventajas tiene usar Room en vez de SQLite?

Juan y María se dan cuenta que es hora de profundizar en esta nueva colección de bibliotecas que Google ha lanzado y están ilusionados, ya que están innovando y ¡se están adaptando a los cambios!

Ocultar

Android Developpers. Robot de Android de Google (CC BY)

Android Jetpack es un conjunto de bibliotecas, herramientas y guías diseñadas para facilitar el desarrollo de aplicaciones modernas, robustas y mantenibles en Android. Todas las bibliotecas de Jetpack están organizadas bajo el espacio de nombres androidx.* y se agrupan en cuatro grandes categorías:

Interfaz de usuario
Fundamentos
Arquitectura
Comportamiento

Aunque anteriormente ya existían componentes como fragmentos, notificaciones o gestión de permisos, Jetpack ha reorganizado y unificado todos estos elementos en una estructura coherente y modular, facilitando su comprensión y mantenimiento. También ha sustituido antiguas bibliotecas como v4, v7, v13, etc., por una única jerarquía bajo androidx.*.

Equivalencia entre Support Library 28.0.0 y las bibliotecas *AndroidX*
Support Library 28.0.0	AndroidX
android.support.constraint.ConstraintLayout	androidx.constraintlayout.widget.ConstraintLayout
android.app.Fragment	androidx.fragment.app.Fragment
android.support.v4.app.ActivityCompat	androidx.core.app.ActivityCompat

Además, Jetpack mejora clases ya existentes y proporciona componentes optimizados. Por ejemplo, en este módulo hemos trabajado con las preferencias de usuario, que forman parte de la categoría de Comportamiento. Puedes consultar la documentación oficial en el siguiente enlace: Documentación oficial de Jetpack.

A medida que avanzamos en el desarrollo en Android, observamos que una aplicación puede contar con múltiples puntos de entrada, como actividades, fragmentos, servicios, proveedores de contenido (content providers) y receptores de emisión (broadcast receivers). La arquitectura de una aplicación móvil puede ser compleja, por lo que se hace necesario utilizar herramientas que faciliten la comunicación y gestión de estos componentes.

La categoría Arquitectura de Jetpack aborda estos desafíos proporcionando clases que permiten desarrollar aplicaciones más robustas, testeables y fáciles de mantener, respetando el ciclo de vida de cada componente.

Un ejemplo destacado es Room, una biblioteca que facilita el acceso a bases de datos SQLite mediante una capa de abstracción. Convierte objetos de Java o Kotlin en registros de tabla y permite realizar operaciones CRUD de forma segura y sencilla.

Para comenzar a usar Room en un proyecto, primero es necesario incluir las dependencias en el archivo de configuración del proyecto. En este caso, utilizaremos el proyecto GamePreferences desarrollado anteriormente.

GROOVY

implementation "androidx.room:room-runtime:2.6.1"
annotationProcessor "androidx.room:room-compiler:2.6.1"

KOTLIN DSL

implementation("androidx.room:room-runtime:2.6.1")
kapt("androidx.room:room-compiler:2.6.1")

Creado con eXeLearning (Ventana nueva)

4.1.- Componentes de la librería

Ocultar

Diagrama de arquitectura de Room: muestra cómo la aplicación accede a través de los DAO a las entidades que interactúan con la base de datos Room.

Android Developpers (CC BY)

Los componentes de la biblioteca Room, como se representa en el esquema, se organizan de la siguiente forma:

Entidades: son clases de Java o Kotlin que representan tablas en una base de datos. Suelen ser clases POJO o POKO, compuestas por atributos y sus respectivos getters y setters. Por ejemplo, la clase Ranking representa una tabla.
Objetos de Acceso a Datos (DAO): son interfaces o clases abstractas que definen las operaciones para acceder a los datos, como insertar, actualizar o consultar.
Base de datos: se define como una clase abstracta que extiende de RoomDatabase. Contiene métodos para obtener instancias de los DAO.

Room trabaja con SQLite mediante anotaciones. Estas anotaciones permiten que la biblioteca genere automáticamente el código necesario para la interacción con la base de datos. Por ejemplo, para indicar que la clase Ranking es una entidad, se utiliza la anotación @Entity:

JAVA

@Entity
public class Ranking {
    @PrimaryKey(autoGenerate = true)
    private int id;
    private int position;
    private String avatar;
    // Getters y setters...
}

KOTLIN

@Entity
data class Ranking(
    @PrimaryKey(autoGenerate = true) val id: Int = 0,
    val position: Int,
    val avatar: String
)

Es recomendable estructurar el proyecto en paquetes (package) según su responsabilidad. A continuación, se propone una posible organización:

Captura de un proyecto organizado por paquetes: adapter, bd, dao, entity, iu, repository.

Captura del IDE Android Studio (Apache 2.0)

adapter: para los adaptadores de vistas como RecyclerView.
bd: para la clase que define la base de datos.
dao: para las interfaces DAO.
entity: para las clases que representan las entidades de la base de datos.
iu: para los componentes de la interfaz de usuario.
repository: para la capa que abstrae el acceso a datos y coordina fuentes locales/remotas.

Para crear esta estructura:

Haz clic derecho sobre el package raíz (por ejemplo, gamepreferences), selecciona Refactor → Rename para renombrarlo si es necesario.
Después, crea nuevos package desde File → New → Package.

Esta organización es orientativa y puede adaptarse según las necesidades del proyecto, siempre que se mantenga la coherencia entre los paquetes y sus contenidos.

Dependencias necesarias en Gradle

Asegúrate de añadir las siguientes dependencias en el archivo build.gradle del módulo app:

GROOVY

dependencies {
    implementation "androidx.room:room-runtime:2.6.1"
    annotationProcessor "androidx.room:room-compiler:2.6.1"
}

KOTLIN DSL

dependencies {
    implementation("androidx.room:room-runtime:2.6.1")
    kapt("androidx.room:room-compiler:2.6.1")
}

También es recomendable utilizar Room KTX y Coroutines para un acceso asincrónico y más moderno:

GROOVY

implementation "androidx.room:room-ktx:2.6.1"

KOTLIN DSL

implementation("androidx.room:room-ktx:2.6.1")

Y aplicar el plugin de Kotlin Annotation Processing Tool (kapt) si trabajas con Kotlin:

GROOVY

plugins {
    id 'kotlin-kapt'
}

KOTLIN DSL

plugins {
    id("kotlin-kapt")
}

Autoevaluación

Ocultar

Solución

Para saber más

Ocultar

Puedes consultar el taller que Google ofrece para conocer esta librería bien enJava o enKotlin.

Creado con eXeLearning (Ventana nueva)

4.2.- Crear Entidades

Ocultar

Ilustración que muestra las entidades de una base de datos.

Iconjam (Licencia de FlatIcon)

Una entidad es una tabla de base de datos y un objeto POJO representa una fila de esa tabla. ¿Cómo se consigue esta traducción?

De la siguiente forma:

La clase de entidad o POJO está marcada con la anotación @Entity. Por defecto, el nombre de la tabla coincide con la clase, pero puede modificarse usando la propiedad tableName en @Entity.
Cada atributo de la clase es una columna de la tabla. Por defecto, el nombre del atributo es el nombre de la columna, aunque se puede modificar mediante la anotación @ColumnInfo(name = "other_name").

En SQLite, los nombres de tabla no distinguen entre mayúsculas y minúsculas.

Además, se pueden utilizar las siguientes anotaciones:

@Ignore: con esta anotación se indica a Room que ignore un campo en particular.
@PrimaryKey(autoGenerate = true): con esta anotación indicamos a Room que una variable (normalmente ID) es un valor que se autogenera al crear un objeto de esta clase y que no podrá repetirse. Es un valor único y se puede utilizar para localizar un objeto concreto.
@NonNull: esta anotación indica que un campo no puede ser nulo.

Room tiene ciertas restricciones que, si no se cumplen, generan error al crear la tabla en la base de datos:

Debe existir un constructor sin parámetros o un constructor con todos los campos no marcados con @Ignore.
Si los atributos de la clase son private, deben definirse los correspondientes métodos setter y getter.

Finalmente, el código de nuestra clase Ranking quedaría así:

JAVA

@Entity(primaryKeys = {"date", "avatar"})
public class Ranking implements Parcelable {

    @NonNull
    private final String avatar;

    @NonNull
    private final String date;

    private final int points;

    public Ranking(@NonNull String avatar, @NonNull String date, int points) {
        this.avatar = avatar;
        this.date = date;
        this.points = points;
    }

    @NonNull
    public String getAvatar() {
        return avatar;
    }

    @NonNull
    public String getDate() {
        return date;
    }

    public int getPoints() {
        return points;
    }

    // Métodos Parcelable (implementación recomendada con Android Studio)
    protected Ranking(Parcel in) {
        avatar = in.readString();
        date = in.readString();
        points = in.readInt();
    }

    @Override
    public void writeToParcel(Parcel dest, int flags) {
        dest.writeString(avatar);
        dest.writeString(date);
        dest.writeInt(points);
    }

    @Override
    public int describeContents() {
        return 0;
    }

    public static final Creator<Ranking> CREATOR = new Creator<Ranking>() {
        @Override
        public Ranking createFromParcel(Parcel in) {
            return new Ranking(in);
        }

        @Override
        public Ranking[] newArray(int size) {
            return new Ranking[size];
        }
    };
}

KOTLIN

@Entity(primaryKeys = ["date", "avatar"])
@Parcelize
data class Ranking(
    @NonNull val avatar: String,
    @NonNull val date: String,
    val points: Int
) : Parcelable

Para compilar con Room y procesar anotaciones en Kotlin, se recomienda aplicar el plugin kotlin-kapt.

GROOVY

plugins {
    id 'kotlin-kapt'
}

KOTLIN

plugins {
    id("kotlin-kapt")
}

Para saber más

Ocultar

En el caso que necesites implementar índices o quieras saber cómo implementar otras opciones puedes consultar la documentación oficial en el siguiente enlace:

Cómo definir datos mediante entidades.

Creado con eXeLearning (Ventana nueva)

4.3.- Crear DAO

Ocultar

Un DAO en Room es una clase abstracta o una interfaz que define un conjunto de métodos que ofrecen acceso a la base de datos utilizando consultas en SQL. Estos métodos los implementa Room en tiempo de compilación y realiza ciertas comprobaciones. Por ejemplo, en los métodos @Query Room verifica si hay un problema con la consulta. Si fuera así, muestra un error de compilación en el panel Build, como muestra la siguiente imagen:

Muestra un error de la librería Room en la pestaña Build Output del panel Build

Captura del IDE Android Studio. Apache 2.0

En Room se pueden realizar las siguientes consultas:

@Query: se hacen consultas directamente a la base de datos. A veces se necesita filtrar una serie de datos basándonos en un parámetro que se pasa al método. En este caso, Room hace coincidir el parámetro de vinculación :avatar con el parámetro del método avatar. Cualquier error que hubiera se muestra en tiempo de compilación.

JAVA

@Query("SELECT * FROM ranking WHERE avatar = :avatar")
Ranking findByShortName(String avatar);

KOTLIN

@Query("SELECT * FROM ranking WHERE avatar = :avatar")
fun findByShortName(avatar: String): Ranking

@Insert: inserta todos los parámetros en la base de datos con una sola transacción.

JAVA

@Insert(onConflict = OnConflictStrategy.IGNORE)
long insert(Ranking ranking);

KOTLIN

@Insert(onConflict = OnConflictStrategy.IGNORE)
fun insert(ranking: Ranking): Long

Si solo se inserta un único objeto, este método puede devolver un valor long que muestra el ID de la fila o rowId insertada en la base de datos. Si el parámetro es un Array o una colección, debería ser long[] o List.

@Update: modifica un conjunto de entidades proporcionadas que se pasan por parámetros. Normalmente, suele ser un objeto que se actualiza en la base de datos teniendo en cuenta la clave primaria o PrimaryKey.

JAVA

@Update
int update(Ranking ranking);

KOTLIN

@Update
fun update(ranking: Ranking): Int

Este método puede devolver un valor int que indica la cantidad de filas actualizadas en la base de datos.

@Delete: elimina un conjunto de registros de la base de datos basándonos en los parámetros del método, de igual forma que el método @Update.

JAVA

@Delete
void delete(Ranking ranking);

KOTLIN

@Delete
fun delete(ranking: Ranking)

Para saber más

Ocultar

Puedes consultar la documentación oficial donde se muestran otras soluciones que se pueden dar en las operaciones a realizar con la base de datos:

Cómo acceder a datos mediante DAO

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

4.4.- Crear Base de Datos

Ocultar

Ilustración que muestra la imagen de una base de datos

IO-Images (Licencia Pixabay)

Para crear la base de datos partimos del código del apartado 7. Add a Room Database del taller sobre la arquitectura de componentes de Jetpack, pero que adaptaremos y modificaremos al ser publicada bajo la licencia de Apache 2.0. Para crear la base de datos realizaremos los siguientes pasos:

En primer lugar, es necesario crear una clase para la base de datos. Esta clase debe ser abstracta y heredar de RoomDatabase.
Encima de la declaración de la clase se debe añadir la anotación @Database y, mediante el parámetro entities, enumerar las tablas y especificar la versión correspondiente de la base de datos.

Dentro de la clase se debe definir, por cada DAO, un método abstracto sin parámetros que devuelva la clase anotada con @Dao.

JAVA

@Database(entities = {Ranking.class}, version = 1, exportSchema = false)
public abstract class GameDatabase extends RoomDatabase {
    public abstract RankingDao getRankingDao();
    private static volatile GameDatabase INSTANCE;
    private static final String DATABASE_NAME = "game";
    private static final int NUMBER_OF_THREADS = 4;
    public static final ExecutorService databaseWriteExecutor =
            Executors.newFixedThreadPool(NUMBER_OF_THREADS);
}

KOTLIN

@Database(entities = [Ranking::class], version = 1, exportSchema = false)
abstract class GameDatabase : RoomDatabase() {
    abstract fun getRankingDao(): RankingDao

    companion object {
        @Volatile
        private var INSTANCE: GameDatabase? = null
        private const val DATABASE_NAME = "game"
        private val databaseWriteExecutor = Executors.newFixedThreadPool(4)
    }
}

Se crea un objeto singleton de la base de datos llamado INSTANCE, el cual será utilizado por el resto de clases de la aplicación mediante un método estático.

Room impide el acceso a la base de datos desde el hilo principal. Para solucionarlo, Google recomienda el uso de la clase ExecutorService, que ejecuta operaciones de base de datos de forma asíncrona en hilos secundarios, evitando así la necesidad de utilizar AsyncTask.

JAVA

public static void createDatabase(final Context context) {
    if (INSTANCE == null) {
        synchronized (GameDatabase.class) {
            if (INSTANCE == null) {
                INSTANCE = Room.databaseBuilder(
                    context.getApplicationContext(),
                    GameDatabase.class,
                    DATABASE_NAME
                ).build();
            }
        }
    }
}

public static GameDatabase getDatabase() {
    return INSTANCE;
}

KOTLIN

fun createDatabase(context: Context) {
    if (INSTANCE == null) {
        synchronized(GameDatabase::class.java) {
            if (INSTANCE == null) {
                INSTANCE = Room.databaseBuilder(
                    context.applicationContext,
                    GameDatabase::class.java,
                    DATABASE_NAME
                ).build()
            }
        }
    }
}

fun getDatabase(): GameDatabase? = INSTANCE

Según la documentación oficial de Google, el método getDatabase() crea la base de datos si no existe y devuelve la instancia. Esto puede provocar la necesidad de disponer de un Context en todas las clases que accedan a ella.

Para evitarlo, se ha creado un método onCreateDatabase() adicional, invocado desde una clase personalizada que extiende de Application. En el método onCreate() se llama al inicializador de la base de datos.
JAVA public class GameApplication extends Application { public static final String CHANNEL_ID = "1"; @Override public void onCreate() { super.onCreate(); GameDatabase.createDatabase(this); } }
KOTLIN class GameApplication : Application() { override fun onCreate() { super.onCreate() GameDatabase.createDatabase(this) } }

Es imprescindible declarar en el fichero AndroidManifest.xml que esta clase corresponde al objeto Application mediante el atributo android:name dentro del nodo <application>:

<application
    android:name=".iu.GameApplication"
    ...
/>

Autoevaluación

Ocultar

Retroalimentación

Verdadero

Si no se declara el atributo android:name dentro del nodo <application> no se vinculará la clase creada con la clase Application que por defecto crea el sistema.

Creado con eXeLearning (Ventana nueva)

4.5.- Clase Repository: accediendo a Room desde la app

Ocultar

Ilustración que muestra varios eslabones de una cadena. En concreto uno es de color rojo que cierra la cadena

PIRO4D (Licencia Pixabay)

Ya tenemos todos los componentes de Room definidos, y nos queda acceder a la base de datos desde la aplicación y lo haremos mediante el patrón Repository.

¿De qué se encarga este patrón?

En primer lugar, se llama patrón a una solución que resuelve problemas comunes en el desarrollo de software y que después de comprobar su efectividad se convierte en una solución estándar. Un patrón ahorra tiempo a los programadores, ya que tienen la seguridad de que su solución es válida. El patrón Repository añade una capa dentro de nuestra aplicación cuya misión es mover la información entre los objetos de nuestra aplicación (clases POJO) y el sistema de almacenamiento que puede ser una base de datos SQLite, un sistema de archivos o bien estar en un servidor remoto, etc.

En nuestro ejemplo, esta clase será la responsable de interactuar con la base de datos de Room en nombre de la vista y deberá proporcionar métodos que utilicen el DAO para insertar, eliminar y consultar registros del ranking. Estas operaciones de base de datos deberán realizarse en subprocesos separados del hilo principal usando la clase ExecutorService.

JAVA

public void insert(final Ranking ranking) {
    GameDatabase.databaseWriteExecutor.execute(() -> {
        rankingDao.insert(ranking);
    });
}

KOTLIN

fun insert(ranking: Ranking) {
    GameDatabase.databaseWriteExecutor.execute {
        rankingDao.insert(ranking)
    }
}

¿Cómo accede toda la aplicación a esta clase repositorio?

Pues mediante una única instancia de la clase Repository de forma que el resto de la aplicación puede consultar la información del ranking solo a través de esta clase. Esto se consigue aplicando el patrón Singleton, que consiste en:

Declarar el constructor de la clase como privado, de forma que solo la propia clase puede crear una instancia de ella misma.
Declarar un método para obtener esta instancia comprobando si es la primera vez que se accede a ella, crear el objeto y devolverlo. Este método suele llamarse getInstance() como se muestra en el siguiente código:

JAVA

private RankingRepository() {
    rankingDao = GameDatabase.getDatabase().getRankingDao();
}

public static RankingRepository getInstance() {
    if (instance == null) {
        instance = new RankingRepository();
    }
    return instance;
}

KOTLIN

private constructor() {
    rankingDao = GameDatabase.getDatabase()?.getRankingDao()
}

companion object {
    @Volatile
    private var instance: RankingRepository? = null

    fun getInstance(): RankingRepository =
        instance ?: synchronized(this) {
            instance ?: RankingRepository().also { instance = it }
        }
}

Como hemos dicho, cualquier componente (normalmente actividades y fragmentos) puede llamar a cualquier método de la clase repositorio y estos métodos son asíncronos, es decir, que la ejecución de la aplicación sigue su curso. Entonces, nos planteamos la siguiente pregunta:

¿Cómo avisa el repositorio a las actividades o fragmentos que ya tiene los datos o que se ha eliminado un elemento?

Declarando una interfaz en la clase repositorio de forma que toda clase que quiera una respuesta del repositorio debe implementar la siguiente interfaz:

JAVA

public interface RankingRepositoryCallback {
    void onSuccess(List<Ranking> list);
    void onSuccess();
}

KOTLIN

interface RankingRepositoryCallback {
    fun onSuccess(list: List<Ranking>)
    fun onSuccess()
}

Veamos el ejemplo a la hora de eliminar un ranking. Este método recibe por parámetro la clase que implementa la interfaz RankingRepositoryCallback, de forma que cuando se elimina un ranking se llama al método onSuccess() que ejecutará las acciones pertinentes, en nuestro ejemplo actualizará el listado de ranking:

JAVA

public void delete(final Ranking ranking, final RankingRepositoryCallback callback) {
    if (ranking != null) {
        GameDatabase.databaseWriteExecutor.execute(() -> {
            rankingDao.delete(ranking);
            callback.onSuccess();
        });
    }
}

KOTLIN

fun delete(ranking: Ranking?, callback: RankingRepositoryCallback) {
    ranking?.let {
        GameDatabase.databaseWriteExecutor.execute {
            rankingDao.delete(it)
            callback.onSuccess()
        }
    }
}

Ejercicio Resuelto

Ocultar

En el siguiente enlace te puedes descargar el proyecto entero que hemos explicado en este apartado. Presta atención a cómo las clases ListRankingFragment y AddRankingFragment se comunican con la clase repositorio RankingRepository y viceversa.

Descarga el proyecto GameRoom (zip - 2.07 MB).

Creado con eXeLearning (Ventana nueva)

5.- Proveedores de Contenidos

Caso práctico

Ocultar

Ada Maria y Juan. Montaje con la foto de los tres personajes.

Ministerio de Educación. (Uso educativo no comercial.)

Ada ha comprobado cómo están gestionando los datos Juan y María y ahora les hace el siguiente planteamiento:

¿Podríamos crear alguna aplicación en Android que necesitara datos de otra aplicación ya existente? Por ejemplo, ¿podríamos acceder a la lista de contactos de nuestro dispositivo móvil desde nuestra aplicación?

Juan y María suponen que sí es posible y no están nada equivocados, de hecho, Ada les ha dado una pista para que investiguen sobre el tema: los proveedores de contenidos o ContentProvider.

Ocultar

Icono con una bola del mundo junto a una carpeta clasificadora.

Everaldo Coelho and YellowIcon (GNU Lesser GPL)

Ya hemos visto que los datos pueden almacenarse en un dispositivo móvil mediante ficheros o bases de datos. Sin embargo, ¿son estos datos accesibles únicamente desde la aplicación que los ha generado? Limitar el acceso a determinados datos impediría que otras aplicaciones los utilicen, lo que podría generar un uso innecesario de memoria, especialmente en dispositivos móviles donde el espacio es un recurso limitado.

Android ofrece un mecanismo para compartir datos entre varias aplicaciones llamado Content Provider (proveedor de contenidos). El acceso a estos contenidos se realiza mediante el uso de URI.

Ocultar

Una URI es una cadena de caracteres que identifica de forma única un recurso (ej: una llamada de teléfono, un SMS, un correo electrónico, etc.)

Ocultar

Una URI está formada por varias partes. La primera es el prefijo que indica el tipo de recurso al que se desea acceder. A continuación se presentan algunos ejemplos de las distintas URI que ofrece Android:

http:// para acceder a una página web.
smsto: para envío de mensajes.
mailto: para envío de correo electrónico.
content:// para acceder a los proveedores de contenido, que se explican con mayor detalle en este apartado.

En relación con los datos proporcionados por los proveedores de contenido, es posible realizar operaciones de inserción, actualización, eliminación y consulta. Gracias al uso del motor de bases de datos SQLite, la forma de trabajar es similar a la gestión habitual de bases de datos, utilizando sentencias SQL y cursores para recorrer los resultados obtenidos.

Es necesario solicitar los permisos adecuados en el archivo AndroidManifest.xml para realizar cualquier operación de lectura y/o escritura sobre los proveedores de contenido sensibles. Por ejemplo, para acceder a los contactos o al historial de llamadas, se deben declarar los siguientes permisos:

<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_CONTACTS" />
<uses-permission android:name="android.permission.READ_CALL_LOG" />
<uses-permission android:name="android.permission.WRITE_CALL_LOG" />

Además, a partir de Android 6.0 (API level 23), estos permisos pertenecen a la categoría de dangerous permissions y deben solicitarse explícitamente en tiempo de ejecución, ya que su acceso está restringido por razones de privacidad.

JAVA

if (ContextCompat.checkSelfPermission(
        context,
        Manifest.permission.READ_CONTACTS
    ) != PackageManager.PERMISSION_GRANTED) {
    
    ActivityCompat.requestPermissions(
        activity,
        new String[] { Manifest.permission.READ_CONTACTS },
        REQUEST_CODE
    );
}

KOTLIN

if (ContextCompat.checkSelfPermission(
        context,
        Manifest.permission.READ_CONTACTS
    ) != PackageManager.PERMISSION_GRANTED) {
    
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_CONTACTS),
        REQUEST_CODE
    )
}

En este apartado nos centraremos en la gestión de datos de otros proveedores de contenido, ya que resulta habitual en el desarrollo de aplicaciones acceder a datos de otras aplicaciones, tales como el registro de llamadas, la lista de contactos, páginas visitadas, etc.

También explicaremos cómo crear un proveedor de contenido propio para que otras aplicaciones puedan acceder a los datos generados por nuestra aplicación.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

5.1.- Utilizando proveedores de contenidos

Ocultar

Everaldo Coelho and YellowIcon (GNU Lesser GPL ))

¿Cómo accedemos a los datos que ya existen en otras aplicaciones?

Cada URI indica el recurso al que deseamos acceder. Además del prefijo que identifica el tipo de recurso (en nuestro caso content://) es necesario especificar el proveedor o aplicación y, finalmente, el recurso o tabla concreta a la que se desea hacer referencia.

Por ejemplo, para acceder a datos como la lista de contactos, se utiliza la URI proporcionada por el sistema, que suele estar definida como una constante en la API de Android, garantizando así compatibilidad y facilidad de uso.

El acceso a los datos de proveedores de contenido permite realizar operaciones de inserción, actualización, eliminación y consulta. Estas operaciones suelen gestionarse mediante el motor de bases de datos SQLite, utilizando sentencias SQL y cursores para recorrer los resultados obtenidos.

En las versiones recientes de Android, para acceder a datos sensibles proporcionados por los proveedores de contenido es obligatorio declarar los permisos necesarios en el archivo AndroidManifest.xml y solicitarlos explícitamente en tiempo de ejecución, para garantizar la privacidad y seguridad del usuario.

Debes conocer

Ocultar

¿Y qué tipos de proveedores existen? ¿Cómo están identificados?

En el siguiente enlace puedes encontrar toda la información referente a los Content Provider de Android.

Proveedores de contenido en Android.

Ocultar

En este ejemplo sencillo accederemos al historial de llamadas del dispositivo móvil utilizando el proveedor de contenido correspondiente. Para ello, es necesario declarar los permisos adecuados en el fichero AndroidManifest.xml y solicitar los permisos en tiempo de ejecución, ya que el acceso a datos sensibles requiere autorización explícita desde Android 6.0 (API level 23).

Primero añadimos los permisos en AndroidManifest.xml

<uses-permission android:name="android.permission.READ_CALL_LOG" />

Una vez concedemos los permisos, se puede acceder al historial de llamadas consultando el proveedor de contenido content://call_log/calls. A continuación, se muestra el código para realizar la consulta y procesar los datos.

JAVA

// Comprobamos si el permiso de lectura del historial de llamadas está concedido
if (ContextCompat.checkSelfPermission(
        context,
        Manifest.permission.READ_CALL_LOG
    ) != PackageManager.PERMISSION_GRANTED) {
    
    // Si no está concedido, solicitamos el permiso en tiempo de ejecución
    ActivityCompat.requestPermissions(
        activity,
        new String[] { Manifest.permission.READ_CALL_LOG },
        REQUEST_CODE
    );

} else {
    // URI del proveedor de contenido para acceder al historial de llamadas
    Uri llamadasUri = CallLog.Calls.CONTENT_URI;

    // Obtenemos el ContentResolver para realizar la consulta
    ContentResolver contentResolver = context.getContentResolver();

    // Columnas que queremos consultar en el historial de llamadas
    String[] columnas = {
        CallLog.Calls.NUMBER,
        CallLog.Calls.TYPE,
        CallLog.Calls.DATE,
        CallLog.Calls.DURATION
    };

    // Realizamos la consulta con orden descendente por fecha
    try (Cursor cursor = contentResolver.query(
            llamadasUri,
            columnas,
            null,
            null,
            CallLog.Calls.DATE + " DESC"
        )) {

        if (cursor != null) {
            // Obtenemos los índices de cada columna para acceder a sus datos
            int idxNumero = cursor.getColumnIndexOrThrow(CallLog.Calls.NUMBER);
            int idxTipo = cursor.getColumnIndexOrThrow(CallLog.Calls.TYPE);
            int idxFecha = cursor.getColumnIndexOrThrow(CallLog.Calls.DATE);
            int idxDuracion = cursor.getColumnIndexOrThrow(CallLog.Calls.DURATION);

            // Recorremos los registros del cursor para procesar los datos
            while (cursor.moveToNext()) {
                String numero = cursor.getString(idxNumero);
                int tipo = cursor.getInt(idxTipo);
                long fecha = cursor.getLong(idxFecha);
                int duracion = cursor.getInt(idxDuracion);
                // Aquí procesaríamos o mostramos los datos obtenidos
            }
        }
    }
}

KOTLIN

// Comprobamos si el permiso de lectura del historial de llamadas está concedido
if (ContextCompat.checkSelfPermission(
        context,
        Manifest.permission.READ_CALL_LOG
    ) != PackageManager.PERMISSION_GRANTED) {
    
    // Si no está concedido, solicitamos el permiso en tiempo de ejecución
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_CALL_LOG),
        REQUEST_CODE
    )

} else {
    // URI del proveedor de contenido para acceder al historial de llamadas
    val llamadasUri = CallLog.Calls.CONTENT_URI

    // Obtenemos el ContentResolver para realizar la consulta
    val contentResolver = context.contentResolver

    // Columnas que queremos consultar en el historial de llamadas
    val columnas = arrayOf(
        CallLog.Calls.NUMBER,
        CallLog.Calls.TYPE,
        CallLog.Calls.DATE,
        CallLog.Calls.DURATION
    )

    // Realizamos la consulta con orden descendente por fecha y usamos el cursor
    contentResolver.query(
        llamadasUri,
        columnas,
        null,
        null,
        "${CallLog.Calls.DATE} DESC"
    )?.use { cursor ->
        // Obtenemos los índices de cada columna para acceder a sus datos
        val idxNumero = cursor.getColumnIndexOrThrow(CallLog.Calls.NUMBER)
        val idxTipo = cursor.getColumnIndexOrThrow(CallLog.Calls.TYPE)
        val idxFecha = cursor.getColumnIndexOrThrow(CallLog.Calls.DATE)
        val idxDuracion = cursor.getColumnIndexOrThrow(CallLog.Calls.DURATION)

        // Recorremos los registros del cursor para procesar los datos
        while (cursor.moveToNext()) {
            val numero = cursor.getString(idxNumero)
            val tipo = cursor.getInt(idxTipo)
            val fecha = cursor.getLong(idxFecha)
            val duracion = cursor.getInt(idxDuracion)
            // Aquí procesaríamos o mostramos los datos obtenidos
        }
    }
}

Recuerda que es fundamental manejar correctamente la autorización de permisos para proteger la privacidad del usuario y cumplir con las políticas de Android.

Recomendación

Ocultar

En el siguiente enlace puedes descargar un proyecto de ejemplo donde se puede ver cómo se accede a los datos de la lista de favoritos del navegador desde una aplicación que creamos nosotros pulsando sobre un botón. Estudia su código y verás que no es muy complicado. Prueba a hacer tú lo mismo accediendo por ejemplo al listado de llamadas.

Aplicación de ejemplo sobre la utilización de un Proveedor de Contenidos (zip - 13.61 MB).

Creado con eXeLearning (Ventana nueva)

5.2.- Creando un proveedor de contenidos

Ocultar

Icono de una bola del mundo verde sobre una tablet.

Everaldo Coelho and YellowIcon ( GNU Lesser GPL )

La posibilidad de compartir datos entre las distintas aplicaciones de Android ofrece una gran ventaja para la interoperabilidad. Ya conocemos cómo acceder a datos almacenados por otras aplicaciones o recursos de Android, pero, ¿es posible compartir los datos de una aplicación propia con otras aplicaciones?

La respuesta es afirmativa. A continuación, se describen los pasos fundamentales para implementar esta funcionalidad.

Para que nuestra aplicación comparta sus propios datos con otras aplicaciones, los pasos a seguir son los siguientes:

Determinar el tipo de información que se va a compartir y si está almacenada en ficheros o bases de datos.
Crear una clase que extienda de ContentProvider, implementando los métodos esenciales onCreate(), query(), insert(), delete(), update() y getType(). Estos métodos permitirán a otras aplicaciones acceder y manipular nuestros datos, además de definir las correspondientes URI para su acceso.
Registrar el ContentProvider en el archivo AndroidManifest.xml, declarando los permisos y las URI que utilizará.

En la aplicación de ejemplo, crearemos un ContentProvider para la tabla Alumnos, que contiene los campos _ID, nombre y email. Es importante que los registros dispongan de un identificador único, generalmente mediante una clave primaria como el campo _ID, que se autoincrementa conforme se insertan nuevos registros.

Debes conocer

Ocultar

En el siguiente enlace puedes encontrar la información necesaria para la creación y posterior uso de un ContentProvider sobre una tabla de base de datos que podrías utilizar para tu aplicación Alumnos.

Creación y uso de un ContentProvider

Creado con eXeLearning (Ventana nueva)

6.- Bases de datos en la nube

Caso práctico

Ocultar

Ada, María y Juan conversando sobre bases de datos en la nube.

Ministerio de Educación. (Uso educativo no comercial.)

Ada está revisando con Juan y María cómo están almacenando los datos en sus aplicaciones móviles, y les lanza una nueva reflexión:

¿Qué pasaría si el usuario pierde el móvil, cambia de dispositivo o reinstala la aplicación móvil? ¿Cómo podrían recuperar sus datos sin haber hecho una copia de seguridad manual?

María menciona que sería ideal que la aplicación pudiera guardar la información en un lugar seguro y accesible desde cualquier dispositivo. Juan propone que quizás se podría usar algún servicio externo, como una base de datos en la nube.

Ante esto, Ada les da nombres de servicios que permiten almacenar datos en línea, sincronizarlos entre dispositivos y mantenerlos siempre accesibles, para que Juan y María puedan indagar.

Ocultar

Hoy en día, el desarrollo de aplicaciones móviles modernas implica, en muchos casos, la necesidad de almacenar y sincronizar datos a través de múltiples dispositivos y plataformas. Para lograrlo, se recurre al uso de cloud databases o bases de datos en la nube.

Una base de datos en la nube permite almacenar la información de una aplicación en servidores remotos a los que se accede a través de APIs. Esto posibilita que los datos estén siempre disponibles, incluso aunque el usuario cambie de dispositivo o reinstale la aplicación.

Representación visual de una base de datos en la nube

geralt (Licencia de contenidos PixaBay)

Las bases de datos en la nube eliminan la necesidad de gestionar almacenamiento local, facilitando el trabajo colaborativo y la persistencia de los datos a largo plazo.

En el ecosistema Android, existen múltiples opciones para trabajar con servicios en la nube. Algunas de las más utilizadas son:

Firebase Realtime Database y Cloud Firestore: soluciones proporcionadas por Google que permiten la sincronización en tiempo real de datos estructurados.
Amazon Web Services (AWS): con servicios como DynamoDB que ofrecen gran escalabilidad y flexibilidad.
Microsoft Azure: que permite integrar bases de datos como Cosmos DB en aplicaciones móviles.

El uso de estas tecnologías implica comprender aspectos clave como la gestión de autenticación, la seguridad en las conexiones, las estructuras de datos en formato JSON, y el diseño eficiente de la base de datos para mejorar el rendimiento y reducir costes.

En resumen, las bases de datos en la nube representan una evolución natural en el desarrollo móvil, proporcionando escalabilidad, sincronización y disponibilidad global de los datos.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

6.1.- Introducción a Firebase

Ocultar

Diagrama visual de los servicios que ofrece Firebase, incluyendo almacenamiento, autenticación, base de datos, etc.

Google (Dominio público)

Una vez comprendido el concepto de bases de datos en la nube, el siguiente paso es conocer una de las plataformas más utilizadas para el desarrollo de aplicaciones móviles conectadas: Firebase.

Firebase es una plataforma desarrollada por Google que proporciona un conjunto de herramientas y servicios diseñados para facilitar el desarrollo, la mejora y el escalado de aplicaciones móviles y web. Es especialmente popular entre desarrolladores de Android por su integración directa con el ecosistema de Google.

Firebase permite integrar funcionalidades avanzadas como almacenamiento, notificaciones, autenticación y bases de datos sin necesidad de crear infraestructura propia.

En términos generales, Firebase ofrece múltiples servicios distribuidos en distintas categorías:

Desarrollo de aplicaciones: bases de datos, almacenamiento, funciones en la nube, SDK para pruebas y depuración.
Calidad de la aplicación: monitoreo de rendimiento, informes de errores y pruebas automatizadas.
Engagement del usuario: notificaciones, segmentación, remote config y analítica.

En el contexto que nos ocupa, el servicio más relevante es el que permite trabajar con bases de datos en la nube. Firebase ofrece dos soluciones distintas:

Firebase Realtime Database: una base de datos NoSQL basada en datos estructurados como árbol en formato JSON. Su principal ventaja es la sincronización en tiempo real.
Cloud Firestore: una evolución más potente y flexible, también basada en NoSQL, con estructuras tipo colección-documento, escalado automático, consultas avanzadas y mayor integración con otros servicios de Google Cloud.

Ambas opciones permiten almacenar y sincronizar datos en tiempo real entre clientes y servidores, pero Realtime Database es ideal para apps simples con alta necesidad de inmediatez, mientras que Cloud Firestore es más adecuada para aplicaciones complejas que requieren escalabilidad y consultas avanzadas.

En los próximos apartados, profundizaremos en cómo integrar estas bases de datos en nuestros proyectos Android, incluyendo su configuración inicial, operaciones básicas de lectura y escritura, gestión de permisos y autenticación de usuarios.

Citas Para Pensar

Ocultar

Cloud computing is not only the future of computing, but the present and the entire past of computing is now being rewritten.
Steve Jobs

Según la cita de Steve Jobs, la computación en la nube no solo representa el futuro, sino que ya es una realidad en el presente. Además, afirma que incluso el pasado de la informática se está transformando, ya que muchas soluciones tradicionales están siendo adaptadas o sustituidas por modelos en la nube. En esencia, la nube está revolucionando por completo cómo almacenamos, accedemos y compartimos la información.

Creado con eXeLearning (Ventana nueva)

6.2.- Configuración de Firebase en un proyecto Android

Ocultar

Elaboración propia (Dominio público)

Una vez comprendido el concepto de base de datos en la nube y el uso general de Firebase, el siguiente paso es aprender a configurar esta herramienta en un entorno Android. Firebase proporciona dos soluciones principales para almacenamiento de datos: Realtime Database y Cloud Firestore. Aunque ambas comparten elementos comunes en su integración, presentan diferencias significativas en su estructura y configuración específica.

Configuración inicial

Crear un proyecto en la Firebase Console ( https://console.firebase.google.com).
Registrar la aplicación Android usando el package name de tu proyecto.
Descargar el archivo google-services.json y colocarlo en la carpeta app/ del proyecto Android.

Modificar el archivo build.gradle a nivel de proyecto para incluir los servicios de Firebase:

GROOVY

plugins {
    // ...
    // Add the dependency for the Google services Gradle plugin
    id 'com.google.gms.google-services' version '4.4.2' apply false
}

KOTLIN DSL

plugins {
    // ...
    // Add the dependency for the Google services Gradle plugin
    id("com.google.gms.google-services") version "4.4.2" apply false
}

Modificar el archivo build.gradle a nivel de módulo para incluir los servicios de Firebase:

GROOVY

plugins {
    id 'com.android.application'
    // Add the Google services Gradle plugin
    id 'com.google.gms.google-services'
    ...
}

dependencies {
    // Import the Firebase BoM
    implementation platform('com.google.firebase:firebase-bom:33.13.0')
    // TODO: Add the dependencies for Firebase products you want to use
    // When using the BoM, don't specify versions in Firebase dependencies
    implementation 'com.google.firebase:firebase-analytics'
    // Add the dependencies for any other desired Firebase products
    // https://firebase.google.com/docs/android/setup#available-libraries
}

KOTLIN DSL

plugins {
    id("com.android.application")
    // Add the Google services Gradle plugin
    id("com.google.gms.google-services")
    ...
}

dependencies {
    // Import the Firebase BoM
    implementation(platform("com.google.firebase:firebase-bom:33.13.0"))
    // TODO: Add the dependencies for Firebase products you want to use
    // When using the BoM, don't specify versions in Firebase dependencies
    implementation("com.google.firebase:firebase-analytics")
    // Add the dependencies for any other desired Firebase products
    // https://firebase.google.com/docs/android/setup#available-libraries
}

Configuración de Realtime Database

En la consola de Firebase, ir al apartado Realtime Database y hacer clic en “Crear una base de datos”.
Elegir la ubicación geográfica (preferiblemente cerca de tus usuarios).
Seleccionar el modo de inicio, inicialmente a modo de prueba para desarrollo.
Una vez creada, ya se podrá acceder desde el SDK de Android.

Agregar la dependencia en build.gradle (app):

GROOVY

implementation 'com.google.firebase:firebase-database:20.3.0'

KOTLIN DSL

implementation("com.google.firebase:firebase-database:20.3.0")

Esta configuración permite conectar tu aplicación con una base de datos en tiempo real, estructurada en formato JSON, ideal para sincronización inmediata de datos simples.

Configuración de Cloud Firestore

Desde la consola de Firebase, ir al apartado Cloud Firestore y pulsar “Crear base de datos”.
Configurar la región del servidor (debe coincidir con la del resto de servicios del proyecto).
Seleccionar el modo de seguridad de desarrollo, inicialmente en modo prueba (se cambiará más adelante).

Agregar la dependencia necesaria en build.gradle (app):

GROOVY

implementation 'com.google.firebase:firebase-database:20.3.0'

KOTLIN DSL

implementation("com.google.firebase:firebase-database:20.3.0")

Firestore permite estructuras más avanzadas mediante documentos y colecciones, y está mejor preparado para aplicaciones escalables con consultas complejas.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

6.3.- Operaciones básicas con Firebase

Ocultar

Elaboración propia. Realtime Database y Cloud Firestore (Dominio público)

Después de realizar la configuración inicial tanto de Cloud Firestore como de Realtime Database, aprenderemos las operaciones básicas para trabajar con cada una de estas bases de datos.

Operaciones básicas con Realtime Database

Realtime Database es una base de datos NoSQL que almacena datos en formato JSON y permite sincronización en tiempo real entre clientes y servidor. Las operaciones básicas que se pueden realizar incluyen lectura, escritura, actualización y eliminación de datos.

Lectura de datos: Se utiliza un listener para obtener datos y recibir actualizaciones en tiempo real.
Escritura de datos: Se escriben datos en una ruta específica, reemplazando o creando nodos.
Actualización: Se actualizan nodos o campos específicos sin afectar el resto de la estructura.
Eliminación: Se eliminan nodos estableciendo su valor a null.

A continuación se muestra su implementación:

JAVA

// Referencia a la base de datos
DatabaseReference ref = 
   FirebaseDatabase.getInstance().getReference("usuarios");

// Escritura de datos (crear o sobrescribir un usuario)
ref.child("usuario1").setValue(new Usuario("Juan", 30));

// Lectura de datos (obtener datos y escuchar cambios)
ref.child("usuario1").addValueEventListener(new ValueEventListener() {
    @Override
    public void onDataChange(DataSnapshot snapshot) {
        Usuario usuario = snapshot.getValue(Usuario.class);
        // manejar el usuario leído
    }

    @Override
    public void onCancelled(DatabaseError error) {
        // manejar error
    }
});

// Actualización de datos (modificar solo el campo "edad")
Map<String, Object> updates = new HashMap<>();
updates.put("edad", 31);
ref.child("usuario1").updateChildren(updates);

// Eliminación de datos (borrar el nodo usuario1)
ref.child("usuario1").removeValue();

KOTLIN

// Referencia a la base de datos
val ref = 
    FirebaseDatabase.getInstance().getReference("usuarios")

// Escritura de datos (crear o sobrescribir un usuario)
ref.child("usuario1").setValue(Usuario("Juan", 30))

// Lectura de datos (obtener datos y escuchar cambios)
ref.child("usuario1").addValueEventListener(object : ValueEventListener {
    override fun onDataChange(snapshot: DataSnapshot) {
        val usuario = snapshot.getValue(Usuario::class.java)
        // manejar el usuario leído
    }

    override fun onCancelled(error: DatabaseError) {
        // manejar error
    }
})

// Actualización de datos (modificar solo el campo "edad")
val updates = mapOf<String, Any>(
    "edad" to 31
)
ref.child("usuario1").updateChildren(updates)

// Eliminación de datos (borrar el nodo usuario1)
ref.child("usuario1").removeValue()

Operaciones básicas con Cloud Firestore

Cloud Firestore es una base de datos NoSQL moderna con estructura basada en colecciones y documentos, que permite consultas avanzadas, escalabilidad automática y sincronización offline. Las operaciones básicas son similares a Realtime Database, pero con mayor flexibilidad y potencia.

Agregar o modificar documentos: Se crean o actualizan documentos dentro de colecciones.
Lectura de documentos o colecciones: Permite obtener datos individuales o conjuntos con filtros y ordenación.
Actualización parcial: Se actualizan campos específicos de un documento sin sobrescribirlo entero.
Eliminación: Se eliminan documentos o campos específicos.

A continuación se muestra su implementación:

JAVA

// Referencia a Firestore
FirebaseFirestore db = FirebaseFirestore.getInstance();

// Escritura de datos (agregar o modificar un documento)
Map<String, Object> usuario = new HashMap<>();
usuario.put("nombre", "Ana");
usuario.put("edad", 25);

db.collection("usuarios")
  .document("usuario1")
  .set(usuario)
  .addOnSuccessListener(aVoid -> {
      // operación exitosa
  })
  .addOnFailureListener(e -> {
      // manejar error
  });

// Lectura de documento
db.collection("usuarios")
  .document("usuario1")
  .get()
  .addOnSuccessListener(documentSnapshot -> {
      if (documentSnapshot.exists()) {
          Usuario usuarioDoc = documentSnapshot.toObject(Usuario.class);
          // manejar usuarioDoc
      }
  })
  .addOnFailureListener(e -> {
      // manejar error de lectura
  });

// Actualización de datos (modificar solo el campo "edad")
Map<String, Object> updates = new HashMap<>();
updates.put("edad", 26);

db.collection("usuarios")
  .document("usuario1")
  .update(updates)
  .addOnSuccessListener(aVoid -> {
      // actualización exitosa
  })
  .addOnFailureListener(e -> {
      // manejar error en actualización
  });

// Eliminación de documento
db.collection("usuarios")
  .document("usuario1")
  .delete()
  .addOnSuccessListener(aVoid -> {
      // eliminación exitosa
  })
  .addOnFailureListener(e -> {
      // manejar error en eliminación
  });

KOTLIN

// Referencia a Firestore
val db = FirebaseFirestore.getInstance()

// Escritura de datos (agregar o modificar un documento)
val usuario = hashMapOf(
    "nombre" to "Ana",
    "edad" to 25
)

db.collection("usuarios")
  .document("usuario1")
  .set(usuario)
  .addOnSuccessListener {
      // operación exitosa
  }
  .addOnFailureListener { e ->
      // manejar error
  }

// Lectura de documento
db.collection("usuarios")
  .document("usuario1")
  .get()
  .addOnSuccessListener { documentSnapshot ->
      if (documentSnapshot.exists()) {
          val usuarioDoc = documentSnapshot
              .toObject(Usuario::class.java)
          // manejar usuarioDoc
      }
  }
  .addOnFailureListener { e ->
      // manejar error de lectura
  }

// Actualización de datos (modificar solo el campo "edad")
val updates = mapOf(
    "edad" to 26
)

db.collection("usuarios")
  .document("usuario1")
  .update(updates)
  .addOnSuccessListener {
      // actualización exitosa
  }
  .addOnFailureListener { e ->
      // manejar error en actualización
  }

// Eliminación de documento
db.collection("usuarios")
  .document("usuario1")
  .delete()
  .addOnSuccessListener {
      // eliminación exitosa
  }
  .addOnFailureListener { e ->
      // manejar error en eliminación
  }

Para saber más

Ocultar

Para profundizar en las operaciones básicas de Firebase Cloud Firestore y Realtime Database, es fundamental consultar la documentación oficial de Firebase. Allí encontrarás guías claras y detalladas sobre cómo realizar lecturas, escrituras, actualizaciones y eliminaciones de datos, además de ejemplos prácticos que facilitan la comprensión e implementación en tus proyectos Android. Esta documentación es una fuente confiable y constantemente actualizada que te ayudará a sacar el máximo provecho a las bases de datos en la nube de Firebase.

Firebase Cloud Firestore

Firebase Realtime Database

Creado con eXeLearning (Ventana nueva)

6.4.- Seguridad y reglas de Firebase

Ocultar

FlatIcon / Freepik (Licencia de Flaticon)

Una vez que ya sabemos realizar operaciones básicas en Firestore y Realtime Database, el siguiente paso esencial es establecer medidas de seguridad mediante el uso de reglas específicas.

Estas reglas se aplican a nivel de base de datos y permiten garantizar que los datos estén protegidos y solo accesibles según las condiciones que se definan. Aunque el propósito es el mismo en ambas bases de datos, la sintaxis y el modo de configuración son diferentes.

Reglas de Firestore

Firestore emplea una estructura declarativa para definir condiciones de acceso basadas en rutas de documentos y autenticación.

// Permitir acceso solo si el usuario está autenticado
service cloud.firestore {
  match /databases/{database}/documents {
    match /usuarios/{usuarioId} {
      allow read, write: if request.auth != null;
    }
  }
}

Las reglas pueden evaluar condiciones como la identidad del usuario, el contenido del documento o la hora de la solicitud, lo que aporta una gran flexibilidad.

A continuación, se indican los pasos para modificar las reglas directamente desde la consola de Firebase.

Accede a Firebase Console .
En tu proyecto, haz clic en Firestore Database desde el menú lateral izquierdo.
Ve a la pestaña Rules (Reglas).
Allí verás un editor donde puedes escribir o modificar las reglas de acceso personalizadas.
Haz clic en Publish para guardar los cambios.

Las reglas deben ser evaluadas cuidadosamente: una mala configuración puede dejar expuestos tus datos o bloquear el acceso legítimo de los usuarios.

Reglas en Realtime Database

Realtime Database utiliza reglas definidas en formato JSON, aplicadas a los nodos de datos. También se pueden establecer condiciones basadas en la autenticación.

{
  "rules": {
    "usuarios": {
      "$uid": {
        ".read":  "auth != null && auth.uid === $uid",
        ".write": "auth != null && auth.uid === $uid"
      }
    }
  }
}

Este ejemplo permite que cada usuario acceda únicamente a sus propios datos, siempre que esté autenticado correctamente.

Para modificar las reglas en Realtime Database:

Accede a Firebase Console .
En el panel izquierdo, selecciona Realtime Database dentro de tu proyecto.
Haz clic en la pestaña Rules (Reglas).
Se mostrará un editor donde puedes definir las condiciones de acceso y escritura a la base de datos.
Una vez hechas las modificaciones, haz clic en Publish para aplicar los cambios.

Al igual que en Firestore, una configuración correcta de las reglas en Realtime Database es clave para proteger los datos y garantizar un acceso controlado.

Firebase permite definir reglas de seguridad que controlan quién puede acceder o modificar los datos.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

6.5.- Autenticación y sincronización en tiempo real con Firebase

Ocultar

Representación gráfica e autenticación de usuario

FlatIcon / JunGSa (Licencia de Flaticon)

Firebase, además de proporcionar un sistema potente para la gestión de datos en la nube, nos ofrece un sistema de autenticación sencillo y seguro. Este sistema permite identificar y controlar el acceso de los usuarios a la aplicación mediante diversos métodos, facilitando la protección de los datos y la personalización de la experiencia.

Firebase Authentication permite autenticar usuarios mediante diferentes métodos:

Correo electrónico y contraseña.
Proveedores externos como Google, Facebook, Twitter, etc.
Teléfono (SMS).
Anonimato temporal.

Configurar Firebase Authentication

Accede a la Firebase Console.
En el menú izquierdo, haz clic en Authentication.
En la pestaña Sign-in method, selecciona el proveedor o proveedores que desees habilitar.
Actívalo y configura los datos necesarios (por ejemplo, dominio autorizado para Google).

Ejemplo de autenticación con UI precompilada

Primero, se añaden las dependencias

GROOVY

dependencies {
    // ...
    implementation 'com.firebaseui:firebase-ui-auth:9.0.0'

    // Requerido solo si se usa inicio de sesión con Facebook
    // Últimas versiones: https://goo.gl/Ce5L94
    implementation 'com.facebook.android:facebook-android-sdk:8.x'
}

KOTLIN DSL

dependencies {
    // ...
    implementation("com.firebaseui:firebase-ui-auth:9.0.0")

    // Requerido solo si se usa inicio de sesión con Facebook
    // Últimas versiones: https://goo.gl/Ce5L94
    implementation("com.facebook.android:facebook-android-sdk:8.x")
}

Crea un ActivityResultLauncher que registre una devolución de llamada para el contrato de resultados de Actividad de FirebaseUI:

JAVA

private val signInLauncher = registerForActivityResult(
    FirebaseAuthUIActivityResultContract(),
) { res ->
    this.onSignInResult(res)
}

KOTLIN

private val signInLauncher = registerForActivityResult(
    FirebaseAuthUIActivityResultContract(),
) { res ->
    this.onSignInResult(res)
}

Para iniciar el flujo de acceso de FirebaseUI, crea un intent de acceso con los métodos de acceso de tu preferencia:

JAVA

// Choose authentication providers
List<AuthUI.IdpConfig> providers = Arrays.asList(
        new AuthUI.IdpConfig.EmailBuilder().build(),
        new AuthUI.IdpConfig.PhoneBuilder().build(),
        new AuthUI.IdpConfig.GoogleBuilder().build(),
        new AuthUI.IdpConfig.FacebookBuilder().build(),
        new AuthUI.IdpConfig.TwitterBuilder().build());

// Create and launch sign-in intent
Intent signInIntent = AuthUI.getInstance()
        .createSignInIntentBuilder()
        .setAvailableProviders(providers)
        .build();
signInLauncher.launch(signInIntent);

KOTLIN 

// Choose authentication providers
val providers = arrayListOf(
    AuthUI.IdpConfig.EmailBuilder().build(),
    AuthUI.IdpConfig.PhoneBuilder().build(),
    AuthUI.IdpConfig.GoogleBuilder().build(),
    AuthUI.IdpConfig.FacebookBuilder().build(),
    AuthUI.IdpConfig.TwitterBuilder().build(),
)

// Create and launch sign-in intent
val signInIntent = AuthUI.getInstance()
    .createSignInIntentBuilder()
    .setAvailableProviders(providers)
    .build()
signInLauncher.launch(signInIntent)

Cuando se complete el flujo de acceso, recibirás el resultado en onSignInResult:

JAVA

private void onSignInResult(FirebaseAuthUIAuthenticationResult result) {
    IdpResponse response = result.getIdpResponse();
    if (result.getResultCode() == RESULT_OK) {
        // Successfully signed in
        FirebaseUser user = FirebaseAuth.getInstance().getCurrentUser();
        // ...
    } else {
        // Sign in failed. If response is null the user canceled the
        // sign-in flow using the back button. Otherwise check
        // response.getError().getErrorCode() and handle the error.
        // ...
    }
}

KOTLIN

private fun onSignInResult(result: FirebaseAuthUIAuthenticationResult) {
    val response = result.idpResponse
    if (result.resultCode == RESULT_OK) {
        // Successfully signed in
        val user = FirebaseAuth.getInstance().currentUser
        // ...
    } else {
        // Sign in failed. If response is null the user canceled the
        // sign-in flow using the back button. Otherwise check
        // response.getError().getErrorCode() and handle the error.
        // ...
    }
}

Ejemplo de autenticación con UI personalizada

Primero, se añaden las dependencias

GROOVY

dependencies {
    // Importa la BoM (Bill of Materials) para la plataforma Firebase
    implementation platform('com.google.firebase:firebase-bom:33.13.0')

    // Añade la dependencia para la biblioteca de autenticación de Firebase
    // Al usar la BoM, no se especifican versiones en las dependencias individuales de Firebase
    implementation 'com.google.firebase:firebase-auth'
}

KOTLIN DSL

dependencies {
    // Import the BoM for the Firebase platform
    implementation(platform("com.google.firebase:firebase-bom:33.13.0"))

    // Add the dependency for the Firebase Authentication library
    // When using the BoM, you don't specify versions in Firebase library dependencies
    implementation("com.google.firebase:firebase-auth")
}

Ahora creamos una nueva actividad de Inicio de sesión llamada LoginActivity, que pondremos como actividad de inicio de la aplicación. Entonces, cuando se lance nuestra aplicación, esta nueva actividad comprobará si la sesión de autenticación de Firebase está activa. Si la sesión ya está iniciada, se mostrará directamente la actividad principal, llamada MainActivity, evitando que el usuario tenga que volver a iniciar sesión. En caso contrario, se presentará la pantalla de inicio de sesión que hemos creado, donde el usuario podrá introducir sus credenciales para acceder a la aplicación.

JAVA

public class LoginActivity extends AppCompatActivity {

    private FirebaseAuth auth;
    private EditText emailField;
    private EditText passwordField;
    private Button loginButton;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);

        auth = FirebaseAuth.getInstance();

        emailField = findViewById(R.id.emailField);
        passwordField = findViewById(R.id.passwordField);
        loginButton = findViewById(R.id.loginButton);

        // Comprobar si usuario ya está autenticado
        if (auth.getCurrentUser() != null) {
            startActivity(new Intent(this, MainActivity.class));
            finish();
            return;
        }

        loginButton.setOnClickListener(v -> {
            String email = emailField.getText().toString().trim();
            String password = passwordField.getText().toString().trim();

            if (email.isEmpty() || password.isEmpty()) {
                Toast.makeText(
                    LoginActivity.this,
                    "Por favor completa todos los campos",
                    Toast.LENGTH_SHORT
                ).show();
            } else {
                loginUser(email, password);
            }
        });
    }

    private void loginUser(String email, String password) {
        auth.signInWithEmailAndPassword(email, password)
            .addOnCompleteListener(
                this,
                new OnCompleteListener<AuthResult>() {
                    @Override
                    public void onComplete(
                        @NonNull Task<AuthResult> task
                    ) {
                        if (task.isSuccessful()) {
                            Toast.makeText(
                                LoginActivity.this,
                                "Inicio de sesión correcto",
                                Toast.LENGTH_SHORT
                            ).show();
                            startActivity(
                                new Intent(
                                    LoginActivity.this,
                                    MainActivity.class
                                )
                            );
                            finish();
                        } else {
                            Toast.makeText(
                                LoginActivity.this,
                                "Error: " +
                                    task.getException()
                                        .getLocalizedMessage(),
                                Toast.LENGTH_LONG
                            ).show();
                        }
                    }
                }
            );
    }
}

KOTLIN

class LoginActivity : AppCompatActivity() {

    private lateinit var auth: FirebaseAuth
    private lateinit var binding: ActivityLoginBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        binding = ActivityLoginBinding.inflate(layoutInflater)
        setContentView(binding.root)

        auth = FirebaseAuth.getInstance()

        // Comprobar si usuario ya está autenticado
        if (auth.currentUser != null) {
            startActivity(
                Intent(this, MainActivity::class.java)
            )
            finish()
            return
        }

        binding.loginButton.setOnClickListener {
            val email = binding.emailField.text.toString().trim()
            val password = binding.passwordField.text.toString().trim()

            if (email.isEmpty() || password.isEmpty()) {
                Toast.makeText(
                    this,
                    "Por favor completa todos los campos",
                    Toast.LENGTH_SHORT
                ).show()
            } else {
                loginUser(email, password)
            }
        }
    }

    private fun loginUser(email: String, password: String) {
        auth.signInWithEmailAndPassword(email, password)
            .addOnCompleteListener(this) { task ->
                if (task.isSuccessful) {
                    Toast.makeText(
                        this,
                        "Inicio de sesión correcto",
                        Toast.LENGTH_SHORT
                    ).show()
                    startActivity(
                        Intent(this, MainActivity::class.java)
                    )
                    finish()
                } else {
                    Toast.makeText(
                        this,
                        "Error: ${task.exception?.localizedMessage}",
                        Toast.LENGTH_LONG
                    ).show()
                }
            }
    }
}

Firebase ofrece un sistema avanzado de sincronización de datos que permite mantener actualizada la información entre la aplicación y sus servicios en la nube, como Firestore y Realtime Database.

La sincronización puede ser síncrona o asíncrona, según el contexto y la conexión del dispositivo. En condiciones normales, cuando el dispositivo está conectado a Internet, las operaciones de lectura y escritura se realizan de forma asíncrona, asegurando que los datos se actualizan en tiempo real entre el cliente y el servidor.

En caso de que el dispositivo pierda la conexión, Firebase implementa un mecanismo de almacenamiento local (caché) que permite continuar trabajando con los datos sin interrupciones visibles para el usuario.

Cuando la conexión se restablece, Firebase sincroniza automáticamente los cambios pendientes con la base de datos en la nube, resolviendo conflictos y garantizando la consistencia de la información.

Este comportamiento mejora significativamente la experiencia de usuario, ofreciendo soporte offline robusto y sincronización eficiente en todos los servicios de Firebase.

En el caso de la autenticación utilizando Firebase, si el dispositivo no tiene conexión a Internet, el comportamiento varía según la situación. Si el usuario intenta iniciar sesión sin conexión, la autenticación no podrá completarse, ya que Firebase necesita comunicarse con sus servidores para verificar las credenciales. Por otro lado, si la sesión ya está iniciada y activa en el dispositivo, Firebase permite que el usuario continúe utilizando la aplicación con acceso limitado, gracias al almacenamiento local del estado de autenticación. Sin embargo, ciertas operaciones que requieran validación en tiempo real o acceso a datos actualizados en la nube estarán restringidas hasta que se recupere la conexión.

Citas Para Pensar

Ocultar

Firebase Authentication simplifies building secure authentication systems, while improving the sign-in and onboarding experience for end users.
Laurence Moroney, Developer Advocate at Google, en Firebase Summit 2020

Como explica la cita, Firebase Authentication facilita la creación de sistemas de inicio de sesión seguros mediante herramientas que simplifican su implementación. A su vez, mejora la experiencia del usuario durante el acceso y el registro, lo que resulta fundamental para garantizar una interacción fluida y satisfactoria con la aplicación.

Creado con eXeLearning (Ventana nueva)

7.- Peticiones HTTP

Caso práctico

Ocultar

Ada, María y Juan conversando sobre cómo conectarse a servicios web desde Android.

Ministerio de Educación. (Uso educativo no comercial.)

Ada está revisando con Juan y María cómo sus aplicaciones móviles obtienen información de fuentes externas, como el clima o noticias, y les plantea una nueva pregunta:

¿Cómo se conecta una aplicación móvil a un servidor para obtener o enviar datos automáticamente? ¿Se puede hacer de forma sencilla y segura?

María y Juan comentan que han oído hablar de algo llamado "API" y que se utilizan URLs para acceder a información, como si la aplicación navegara por Internet en segundo plano.

Entonces, Ada les habla de Retrofit, una biblioteca muy utilizada en Android que permite hacer peticiones HTTP de forma sencilla, convertir respuestas JSON en objetos de Kotlin o Java, y mantener un código limpio y organizado. Les anima a investigar cómo integrarla en sus proyectos para conectarse a APIs reales.

Ocultar

En el desarrollo de aplicaciones móviles con Android, el consumo de servicios web es una necesidad habitual para obtener o enviar información a un servidor. Este intercambio se realiza mediante el protocolo HTTP, un estándar ampliamente utilizado en comunicaciones cliente-servidor.

Una petición HTTP permite a la aplicación interactuar con recursos remotos, como APIs REST, de forma estructurada y segura.

Representación gráfica del protocola HTTP (Cliente-Servidor)

Elaboración propia (Dominio público)

La imagen muestra cómo dos clientes, un ordenador y un móvil, envían una petición HTTP a un servidor y reciben una respuesta, representado visualmente mediante flechas que indican el flujo de comunicación en ambos sentidos.

Las peticiones HTTP pueden ser de distintos tipos, dependiendo de la acción que se desee realizar sobre los datos remotos. Los métodos más comunes son:

GET (leer datos).
POST (enviar datos).
PUT (actualizar recursos).
DELETE (eliminar recursos).

Aunque existen múltiples bibliotecas para realizar este tipo de operaciones, en este curso trabajaremos con Retrofit, una librería eficiente, extensible y fácil de configurar que se ha convertido en un estándar en el ecosistema Android.

Además, es fundamental comprender cómo funcionan las capas de red y los mecanismos de serialización/deserialización de datos (por ejemplo, en formato JSON) para lograr una integración correcta con servicios web.

El uso correcto de peticiones HTTP no solo mejora el rendimiento de la aplicación, sino que también garantiza una mejor experiencia de usuario, especialmente en contextos de conectividad limitada.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

7.1.- Introducción a Retrofit

Ocultar

Android Developpers. Retrofit (CC BY)

Cuando desarrollamos aplicaciones móviles que consumen REST APIs, necesitamos una herramienta eficiente que nos permita realizar peticiones HTTP de forma segura y estructurada. En este contexto, Retrofit se posiciona como una de las bibliotecas más populares dentro del ecosistema Android.

Retrofit es una librerias desarrollada por Square que simplifica enormemente el proceso de integración con servicios web. Permite definir las operaciones sobre una API remota mediante interfaces Java o Kotlin, y se encarga automáticamente de generar el código necesario para realizar las peticiones y recibir las respuestas.

Retrofit convierte una interfaz Java o Kotlin en un cliente HTTP funcional.

El uso de Retrofit aporta numerosas ventajas:

Abstracción de los detalles del protocolo HTTP.
Soporte integrado para conversores de datos como Gson, Moshi o Jackson.
Integración con corrutinas (coroutines) y LiveData o RxJava para programación reactiva.
Manejo automático de hilos, errores y conversiones de tipos.

En resumen, Retrofit mejora notablemente la productividad del desarrollador Android al ofrecer una interfaz clara, segura y modular para trabajar con servicios web externos. A partir del siguiente apartado aprenderemos a configurarlo e integrarlo en nuestros proyectos.

Para saber más

Ocultar

Para profundizar más en Retrofit, puedes mirar este Codelab:

Cómo obtener datos de Internet mediante Retrofit y Android

Creado con eXeLearning (Ventana nueva)

7.2.- Configuración de Retrofit en un proyecto Android

Ocultar

FlatIcon / Freepik (Licencia de Flaticon)

Para integrar Retrofit en un proyecto Android, es imprescindible configurar correctamente sus dependencias y definir los componentes básicos que permitirán establecer la comunicación con un servidor remoto mediante HTTP.

El proceso de configuración consiste en añadir las librerías necesarias en el sistema de compilación de Android (Gradle) y preparar los convertidores que se encargarán de transformar los datos entre formatos como JSON y objetos Java/Kotlin.

La correcta inclusión de las dependencias es el primer paso para garantizar una integración funcional y estable de Retrofit.

Entre las dependencias básicas que se deben incluir destacan:

La propia biblioteca Retrofit para realizar las peticiones HTTP.
Un convertidor para gestionar la serialización y deserialización de datos, siendo Gson uno de los más utilizados.
Opcionalmente, librerías para integración con otras tecnologías como RxJava o corrutinas de Kotlin.

En el siguiente apartado se presentarán ejemplos prácticos de configuración, tanto en Java como en Kotlin, para que pueda aplicarse en cualquier proyecto Android de forma sencilla y escalable.

GROOVY

dependencies {
    // Retrofit principal
    implementation 'com.squareup.retrofit2:retrofit:2.9.0'
    // Convertidor Gson para JSON
    implementation 'com.squareup.retrofit2:converter-gson:2.9.0'
}

KOTLIN DSL

dependencies {
    // Retrofit principal
    implementation("com.squareup.retrofit2:retrofit:2.9.0")
    // Convertidor Gson para JSON
    implementation("com.squareup.retrofit2:converter-gson:2.9.0")
}

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

7.3.- Definición de interfaces de API

Ocultar

FlatIcon / Freepik (Licencia de Flaticon)

Una vez que las dependencias de Retrofit están integradas en el proyecto Android, el siguiente paso es definir las interfaces que representarán las API a consumir.

Estas interfaces describen los métodos que se corresponden con las distintas peticiones HTTP que la aplicación realizará para interactuar con el servidor. Cada método se anota con información sobre el tipo de petición (GET, POST, etc.) y la ruta relativa del recurso.

Definir correctamente las interfaces es crucial para asegurar una comunicación eficaz y tipada entre la aplicación y los servicios remotos.

Para crear una interfaz de API, es habitual:

Declarar métodos abstractos anotados con el método HTTP correspondiente.
Especificar las rutas relativas a los recursos del servidor.
Definir los parámetros necesarios para la petición, incluyendo cabeceras, cuerpos o parámetros de consulta.
Establecer el tipo de retorno, normalmente un objeto de tipo Call<T> donde T es el modelo de datos esperado.

Sintaxis API

La interfaz API en Retrofit define las diferentes peticiones HTTP que la aplicación realizará al servidor. Cada método representa una llamada concreta y está anotado para indicar el tipo de petición HTTP que ejecuta, así como la URL relativa del recurso al que accede.

Anotaciones HTTP (@GET, @POST, @PUT, @DELETE): Estas indican el tipo de petición que se realizará. Por ejemplo, @GET("users/{id}") señala que se hará una petición GET a la ruta users/{id}, donde {id} es un parámetro dinámico.
Parámetros en la URL (@Path): El valor dentro de las llaves {} en la ruta se reemplaza con el valor pasado al método mediante la anotación @Path. Esto permite construir URLs específicas para cada recurso.
Cuerpo de la petición (@Body): Para métodos que envían datos al servidor, como POST o PUT, se utiliza @Body para indicar que el objeto pasado debe serializarse y enviarse en el cuerpo de la solicitud.
Tipo de retorno (Call<T>): Cada método devuelve un objeto Call parametrizado con el tipo esperado de respuesta. Este objeto representa la llamada HTTP y permite manejar la respuesta o los posibles errores, ya sea de forma síncrona o asíncrona.

Esta estructura permite definir claramente las operaciones disponibles en la API y facilita su uso desde la aplicación, manteniendo un código limpio y mantenible.

JAVA

public interface ApiService {
    @GET("ruta/{param}")
    Call<TipoRespuesta> metodoGet(@Path("param") TipoParametro parametro);

    @POST("ruta")
    Call<TipoRespuesta> metodoPost(@Body TipoCuerpo cuerpo);
}

KOTLIN

interface ApiService {
    @GET("ruta/{param}")
    fun metodoGet(@Path("param") parametro: TipoParametro): Call<TipoRespuesta>

    @POST("ruta")
    fun metodoPost(@Body cuerpo: TipoCuerpo): Call<TipoRespuesta>
}

Ejemplo de implementación

Imaginemos que queremos hacer una petición GET a "https://tuapi.com/users/42" para que nos devuelva los datos en JSON del usuario con ID=42.

// Respuesta JSON a https://tuapi.com/users/42
{
    "id": 42,
    "name": "Juan Pérez",
    "email": "juan.perez@example.com"
}

Esta estructura permite a Retrofit generar automáticamente las implementaciones necesarias para las llamadas HTTP, facilitando el manejo de respuestas y errores.

JAVA

public interface ApiService {
    // Petición GET para obtener información de un usuario específico.
    // La URL sería: https://tuapi.com/users/42 (si userId = 42)
    @GET("users/{id}")
    Call<User> getUser(@Path("id") int userId);

    // Petición POST para crear un nuevo usuario.
    // La URL sería: https://tuapi.com/users/new
    @POST("users/new")
    Call<User> createUser(@Body User user);
}

KOTLIN

interface ApiService {
    // Petición GET para obtener información de un usuario específico.
    // La URL sería: https://tuapi.com/users/42 (si userId = 42)
    @GET("users/{id}")
    fun getUser(@Path("id") userId: Int): Call<User>

    // Petición POST para crear un nuevo usuario.
    // La URL sería: https://tuapi.com/users/new
    @POST("users/new")
    fun createUser(@Body user: User): Call<User>
}

Es importante tener en cuenta que el modelo User (User.java o User.kt) debe estar previamente definido para que Retrofit pueda serializar y deserializar los datos de forma automática.

JAVA

public class User {
    private int id;
    private String name;
    private String email;

    public User() {
        // Constructor vacío requerido para la deserialización
    }

    public User(int id, String name, String email) {
        this.id = id;
        this.name = name;
        this.email = email;
    }

    // Getters y setters
    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

KOTLIN

data class User(
    val id: Int,
    val name: String,
    val email: String
)

Con esta base, la aplicación queda preparada para realizar peticiones eficientes y estructuradas, garantizando un código limpio y mantenible.

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

7.4.- Realización de peticiones HTTP

Ocultar

FlatIcon / winnievinzence (Licencia de Flaticon)

En esta sección se explica cómo utilizar la clase Retrofit para ejecutar peticiones HTTP una vez que se dispone de la interfaz definida en el apartado anterior. Se trata de conectar la definición teórica de la API con la ejecución real de las llamadas a través del cliente Retrofit.

Con esta configuración, es posible realizar peticiones GET, POST, PUT y DELETE de manera sencilla y clara, evitando el manejo manual de conexiones y parseo.

Configurar y construir la instancia de Retrofit con la URL base y el convertidor.
Obtener una implementación de la interfaz ApiService mediante retrofit.create().
Llamar a los métodos definidos en la interfaz para crear objetos Call que representan las peticiones.
Ejecutar la petición de forma síncrona o asíncrona (en este punto se abordará en detalle en la siguiente sección).

A continuación se muestra un ejemplo de implementación completo:

Implementación de APIService

Se implementa una interfaz API para realizar peticiones que obtienen y crean datos de usuarios, definiendo los endpoints para acceder a la información del usuario por ID y para registrar nuevos usuarios.

JAVA

// ApiService.java
public interface ApiService {
    @GET("users/{id}")
    Call<User> getUser(@Path("id") int userId);

    @POST("users")
    Call<User> createUser(@Body User user);

    @PUT("users/{id}")
    Call<User> updateUser(@Path("id") int userId, @Body User user);

    @DELETE("users/{id}")
    Call<Void> deleteUser(@Path("id") int userId);
}

KOTLIN

// ApiService.kt
interface ApiService {
    @GET("users/{id}")
    fun getUser(@Path("id") userId: Int): Call<User>

    @POST("users")
    fun createUser(@Body user: User): Call<User>

    @PUT("users/{id}")
    fun updateUser(@Path("id") userId: Int, @Body user: User): Call<User>

    @DELETE("users/{id}")
    fun deleteUser(@Path("id") userId: Int): Call<Void>
}

Implementación de RetrofitInstance

Se configura una instancia de Retrofit para conectar con el servidor que gestiona los datos de usuarios, estableciendo la URL base y el convertidor para trabajar con objetos JSON.

JAVA

// RetrofitInstance.java
public class RetrofitInstance {
    private static Retrofit retrofit;
    private static final String BASE_URL = "https://api.ejemplo.com/";

    public static Retrofit getRetrofit() {
        if (retrofit == null) {
            retrofit = new Retrofit.Builder()
                .baseUrl(BASE_URL)
                .addConverterFactory(GsonConverterFactory.create())
                .build();
        }
        return retrofit;
    }
}

KOTLIN

// RetrofitInstance.kt
object RetrofitInstance {
    private const val BASE_URL = "https://api.ejemplo.com/"

    val retrofit: Retrofit by lazy {
        Retrofit.Builder()
            .baseUrl(BASE_URL)
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }
}

Uso de RetrofitInstance y `APIService` en MainActivity

Se muestra cómo desde la actividad principal se ejecutan peticiones para obtener un usuario por su identificador o crear un nuevo usuario, manejando las respuestas de manera asíncrona.

JAVA

public class MainActivity extends AppCompatActivity {

    private ApiService apiService;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        Retrofit retrofit = RetrofitInstance.getRetrofitInstance();
        apiService = retrofit.create(ApiService.class);

        // Ejemplo: Obtener usuario con ID 42
        Call<User> call = apiService.getUser(42);
        call.enqueue(new Callback<User>() {
            @Override
            public void onResponse(Call<User> call, Response<User> response) {
                if (response.isSuccessful() && response.body() != null) {
                    User user = response.body();
                    // Procesar datos del usuario
                }
            }

            @Override
            public void onFailure(Call<User> call, Throwable t) {
                // Manejar error en la petición
            }
        });

        // Ejemplo: Crear un nuevo usuario
        User newUser = new User(0, "Ana García", "ana.garcia@example.com");
        Call<User> createCall = apiService.createUser(newUser);
        createCall.enqueue(new Callback<User>() {
            @Override
            public void onResponse(Call<User> call, Response<User> response) {
                if (response.isSuccessful()) {
                    // Usuario creado correctamente
                }
            }

            @Override
            public void onFailure(Call<User> call, Throwable t) {
                // Manejar error al crear usuario
            }
        });
    }
}

KOTLIN

class MainActivity : AppCompatActivity() {

    private lateinit var apiService: ApiService

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val retrofit = RetrofitInstance.getRetrofitInstance()
        apiService = retrofit.create(ApiService::class.java)

        // Ejemplo: Obtener usuario con ID 42
        val call = apiService.getUser(42)
        call.enqueue(object : Callback<User> {
            override fun onResponse(
                call: Call<User>,
                response: Response<User>
            ) {
                if (response.isSuccessful && response.body() != null) {
                    val user = response.body()
                    // Procesar datos del usuario
                }
            }

            override fun onFailure(call: Call<User>, t: Throwable) {
                // Manejar error en la petición
            }
        })

        // Ejemplo: Crear un nuevo usuario
        val newUser = User(0, "Ana García", "ana.garcia@example.com")
        val createCall = apiService.createUser(newUser)
        createCall.enqueue(object : Callback<User> {
            override fun onResponse(
                call: Call<User>,
                response: Response<User>
            ) {
                if (response.isSuccessful) {
                    // Usuario creado correctamente
                }
            }

            override fun onFailure(call: Call<User>, t: Throwable) {
                // Manejar error al crear usuario
            }
        })
    }
}

Para saber más

Ocultar

Android Developers pone a disposición de los desarrolladores una variedad de cursos gratuitos enfocados en sus herramientas y tecnologías. Estos recursos formativos están diseñados para facilitar el aprendizaje y la mejora continua en el desarrollo de aplicaciones Android. En el contexto actual, acceder a uno de estos cursos puede resultar especialmente útil para profundizar en conceptos clave, adquirir nuevas habilidades prácticas y consolidar los conocimientos relacionados con la implementación y gestión de peticiones HTTP mediante Retrofit, entre otros aspectos fundamentales. Por tanto, aprovechar esta oferta educativa contribuye a un desarrollo profesional más sólido y actualizado.

Cómo obtener datos de Internet

Creado con eXeLearning (Ventana nueva)

7.5.- Manejo de respuestas y errores

Ocultar

Representación gráfica del error HTTP 404

FlatIcon / Vectorslab. HTTP (Licencia de Flaticon)

En la implementación de aplicaciones que consumen API, la correcta gestión de las respuestas y errores es fundamental para asegurar una experiencia de usuario fluida y robusta. Esta sección aborda cómo manejar adecuadamente las respuestas exitosas, errores de cliente, errores de servidor y problemas de conectividad al utilizar Retrofit en Android.

Las respuestas HTTP pueden clasificarse en diferentes categorías según el código de estado devuelto por el servidor:

Respuestas exitosas (códigos 200-299): Indican que la petición fue procesada correctamente.
Errores de cliente (códigos 400-499): Señalan problemas en la solicitud realizada por el cliente, como datos inválidos o no autorizados.
Errores de servidor (códigos 500-599): Indican fallos en el servidor que impiden procesar la petición.
Errores de red o conectividad: Problemas en la comunicación entre cliente y servidor, como falta de conexión o tiempo de espera agotado.

Es esencial capturar y gestionar cada tipo de error para proporcionar retroalimentación útil al usuario y garantizar la estabilidad de la aplicación.

Ejemplo de implementación

JAVA

Call<User> call = apiService.getUser(42);
call.enqueue(new Callback<User>() {
    @Override
    public void onResponse(Call<User> call, 
                           Response<User> response) {
        if (response.isSuccessful() && 
            response.body() != null) {
            User user = response.body();
            // Procesar usuario correctamente recibido
        } else {
            int code = response.code();
            // Gestionar errores HTTP, por ejemplo:
            if (code == 404) {
                // Usuario no encontrado
            } else if (code == 401) {
                // No autorizado
            } else {
                // Otros errores HTTP
            }
        }
    }
    @Override
    public void onFailure(Call<User> call, Throwable t) {
        // Error de red o fallo en la petición
    }
});

KOTLIN

val call = apiService.getUser(42)
call.enqueue(object : Callback<User> {
    override fun onResponse(
        call: Call<User>,
        response: Response<User>
    ) {
        if (response.isSuccessful && 
            response.body() != null) {
            val user = response.body()
            // Procesar usuario correctamente recibido
        } else {
            val code = response.code()
            when (code) {
                404 -> {
                    // Usuario no encontrado
                }
                401 -> {
                    // No autorizado
                }
                else -> {
                    // Otros errores HTTP
                }
            }
        }
    }

    override fun onFailure(
        call: Call<User>,
        t: Throwable
    ) {
        // Error de red o fallo en la petición
    }
})

Autoevaluación

Ocultar

Solución

Creado con eXeLearning (Ventana nueva)

Condiciones y términos de uso de los materiales

Ocultar

Materiales desarrollados inicialmente por el Ministerio de Educación, Cultura y Deporte y actualizados por el profesorado de la Junta de Andalucía bajo licencia Creative Commons BY-NC-SA.

Antes de cualquier uso leer detenidamente el siguente Aviso legal

Ocultar

Historial de actualizaciones

Versión: 04.00.00	Fecha de actualización: 27/06/25	Autoría: Lindsay Barrero Martínez
Ubicación: contenidos Mejora (tipo 1): Corregidas las sugerencias Ubicación: Casi todos los apartados. Mejora (tipo 3): Cambios sugeridos: 1.3. y 1.4 Añadir ejemplos Kotlin 2 y subapartados. Añadir ejemplos Kotlin. Actualizar la normativa de ficheros en memoria externa, ya que la normativa de acceso cambió con Scoped Storage en la API 29 (Android 10), restringiendo el acceso directo y obligando al uso de APIs como MediaStore o SAF, siendo obligatorio desde API 30 (Android 11). 3, 4, 5 y subapartados. Añadir ejemplos en Kotlin. X. Añadir apartado para peticiones HTTP a APIs con Retrofit, ya que no hay contenido relacionado con el CE 2.e) Se han utilizado las clases necesarias para establecer conexiones y comunicaciones HTTP y HTTPS. Y. Añadir apartado de BD en la nube (Firebase). Esta base de datos se utiliza mucho en la actualidad (compatible con muchos lenguajes) y es en la nube, que les permite compartir datos entre diferentes usuarios de una app y la implementación de una autenticación segura mediante email, Google, Facebook, etc. Ubicación: 4.2. Crear Entidades. Mejora (tipo 1): En la introducción del apartado 4.2. Crear Entidades, aparece la siguiente frase: Una entidad es una tabla de base de datos y una clase POJO representa una fila de esa tabla.. Esto no es correcto, puesto que una clase POJO no representa una fila. Se podría decir, que un objeto POJO representa una fila. Ubicación: mapa Mejora (Mapa conceptual): Añadidos los nuevos apartados al mapa Ubicación: orientaciones Mejora (Orientaciones del alumnado): modificado el índice de orientaciones

Versión: 04.00.00

Fecha de actualización: 27/06/25

Autoría: Lindsay Barrero Martínez

Ubicación: contenidos
Mejora (tipo 1): Corregidas las sugerencias

Ubicación: Casi todos los apartados.
Mejora (tipo 3): Cambios sugeridos:
1.3. y 1.4 Añadir ejemplos Kotlin
2 y subapartados. Añadir ejemplos Kotlin. Actualizar la normativa de ficheros en memoria externa, ya que la normativa de acceso cambió con Scoped Storage en la API 29 (Android 10), restringiendo el acceso directo y obligando al uso de APIs como MediaStore o SAF, siendo obligatorio desde API 30 (Android 11).
3, 4, 5 y subapartados. Añadir ejemplos en Kotlin.
X. Añadir apartado para peticiones HTTP a APIs con Retrofit, ya que no hay contenido relacionado con el CE 2.e) Se han utilizado las clases necesarias para establecer conexiones y comunicaciones HTTP y HTTPS.
Y. Añadir apartado de BD en la nube (Firebase). Esta base de datos se utiliza mucho en la actualidad (compatible con muchos lenguajes) y es en la nube, que les permite compartir datos entre diferentes usuarios de una app y la implementación de una autenticación segura mediante email, Google, Facebook, etc.

Ubicación: 4.2. Crear Entidades.
Mejora (tipo 1): En la introducción del apartado 4.2. Crear Entidades, aparece la siguiente frase: Una entidad es una tabla de base de datos y una clase POJO representa una fila de esa tabla.. Esto no es correcto, puesto que una clase POJO no representa una fila. Se podría decir, que un objeto POJO representa una fila.

Ubicación: mapa
Mejora (Mapa conceptual): Añadidos los nuevos apartados al mapa

Ubicación: orientaciones
Mejora (Orientaciones del alumnado): modificado el índice de orientaciones

Versión: 03.00.00	Fecha de actualización: 13/06/20	Autoría: Lourdes Rodríguez Morón
Ubicación: 3 Bases de datos Mejora (tipo 3): Cambiar todo el apartado. Seguir la recomendación de Android y usar Room como abstracción para el acceso a la base de datos. Ubicación: apartado 3.3.2. Mejora (tipo 2): No se explican correctamente los cursores que devuelve las consultas a la base de datos. Ubicación: apartado 1.2 Mejora (tipo 2): La explicación de este apartado se basa en dos ejemplos que no en la versión actual no compilan correctamente. Ubicación: Nodos del mapa Mejora (Mapa conceptual): Revisión y actualización en base a los nuevos contenidos Ubicación: Tabla de contenidos Mejora (Orientaciones del alumnado): Revisión y actualización en base a los nuevos contenidos

Versión: 03.00.00

Fecha de actualización: 13/06/20

Autoría: Lourdes Rodríguez Morón

Ubicación: 3 Bases de datos
Mejora (tipo 3): Cambiar todo el apartado. Seguir la recomendación de Android y usar Room como abstracción para el acceso a la base de datos.

Ubicación: apartado 3.3.2.
Mejora (tipo 2): No se explican correctamente los cursores que devuelve las consultas a la base de datos.

Ubicación: apartado 1.2
Mejora (tipo 2): La explicación de este apartado se basa en dos ejemplos que no en la versión actual no compilan correctamente.

Ubicación: Nodos del mapa
Mejora (Mapa conceptual): Revisión y actualización en base a los nuevos contenidos

Ubicación: Tabla de contenidos
Mejora (Orientaciones del alumnado): Revisión y actualización en base a los nuevos contenidos

Versión: 02.00.00	Fecha de actualización: 25/04/14	Autoría: Víctor Gil Rodríguez
Nuevos contenidos, mapa conceptual y orientaciones actualizados con Android.

Versión: 01.00.00	Fecha de actualización: 25/04/14
Versión inicial de los materiales.

Programación en Android: Gestión de Datos

Caso práctico

1.- Preferencias

Caso práctico

Citas Para Pensar

1.1.- Diseño de la pantalla de preferencias I

Crear recurso XML de las preferencias

Tipos de preferencias

Autoevaluación

Pregunta

Respuestas

Retroalimentación

Solución

1.2.- Diseño de la pantalla de preferencias II

Autoevaluación

Pregunta 1

Retroalimentación

1.3.- Mostrar la pantalla de preferencias

Reflexiona

Retroalimentación

Autoevaluación

Pregunta 1

Retroalimentación

1.4.- Recuperar las preferencias almacenadas

Reflexiona

Retroalimentación

Ejercicio Resuelto

Retroalimentación

Para saber más

2.- Ficheros

Caso práctico

2.1.- Almacenamiento en memoria interna

Para saber más

2.1.1.- Almacenamiento en los recursos de la aplicación

Autoevaluación

Pregunta 1

Retroalimentación

Pregunta 2

Retroalimentación

2.2.- Almacenamiento en memoria externa

Para saber más

2.2.1.- Escribiendo en memoria externa

Autoevaluación

Pregunta

Respuestas

Retroalimentación

Solución

2.2.2.- Leyendo de la memoria externa

3.- Base de Datos

Caso práctico

Para saber más

3.1.- Estructura de SQLite

Para saber más

Autoevaluación

Pregunta

Respuestas

Retroalimentación

Solución

3.2.- Creación de una base de datos

Declaración de la clase

Autoevaluación

Pregunta

Respuestas

Retroalimentación

Solución

3.3.- Operaciones sobre una base de datos

3.3.1.- Inserción, actualización y eliminación de registros

Para saber más

Autoevaluación

Pregunta

Respuestas

Retroalimentación

Solución

3.3.2.- Recuperación o consulta de registros

Para saber más

Autoevaluación

Pregunta 1

Retroalimentación

4.- Room

Caso práctico