Algunas veces, cuando usamos las API del cliente de Firebase para Android, Firebase debe realizar ciertas tareas a pedido del programador de manera asíncrona. Puede suceder que algunos de los datos requeridos no estén disponibles inmediatamente, o que el trabajo ingrese en una cola para su eventual ejecución. Cuando decimos que ciertos trabajos se deben realizar
de manera asíncrona en una app, significa que el trabajo debe realizarse al mismo tiempo que la app realiza su tarea principal de enviar las vistas de la app, aunque sin obstruir este trabajo. Para realizar este trabajo asíncrono correctamente en las apps de Android, el trabajo no puede ocupar tiempo en el subproceso principal de Android; de lo contrario, la app puede retardar el envío de algunos marcos, lo que ocasionaría un "bloqueo" en la experiencia del usuario, o peor, ¡el temido
ANR! Las solicitudes de red, lectura y escritura de archivos y cálculos extensos son algunos ejemplos de trabajos que pueden ocasionar demoras. En general, esto se denomina
trabajo bloqueante, ¡y nunca queremos bloquear el subproceso principal!
Cuando un programador usa una API de Firebase para solicitar un trabajo que normalmente bloquearía el subproceso principal, la API debe hacer que ese trabajo se ejecute en un subproceso diferente, a fin de evitar bloqueos y ANR. Al finalizar, en ocasiones los resultados de ese trabajo deben volver al subproceso principal para actualizar las vistas de manera segura.
Esa es la tarea de la
API Play Services Task. El objetivo de la API Task es brindar un marco de trabajo simple, liviano y con reconocimiento de Android para que las API del cliente Firebase (y Play services) realicen el trabajo de manera asíncrona. Se presentó en Play services versión 9.0.0 junto con Firebase. Si has utilizado características de Firebase en tu app, es posible que hayas utilizado la API Task sin ni siquiera notarlo. Por ello, lo que me gustaría hacer en esta serie del blog es revelar algunas de las formas en que las API de Firebase utilizan Tasks y debatir algunos patrones para uso avanzado.
Antes de comenzar, es importante que sepas que la API Task no es un reemplazo completo de otras técnicas de subprocesos en Android. El equipo de Android ha preparado contenidos excelentes que describen otras herramientas de subprocesos, como
Services,
Loaders y
Handlers. También hay una serie completa de
Application Performance Patterns en YouTube en donde se describen las diferentes opciones. Algunos programadores incluso usan como opciones bibliotecas de terceros que te ayudarán con tus subprocesos en las apps de Android. Por ello, depende de ti investigar estos contenidos y determinar cuál es la mejor solución para tus subprocesos particulares. Las API de Firebase utilizan Tasks de manera uniforme para gestionar el trabajo de los subprocesos, y puedes usarlas junto con otras estrategias que creas convenientes.
Un ejemplo de una tarea simple
Si estás usando
Almacenamiento de Firebase, definitivamente encontrarás Tasks en algún punto. Aquí incluimos un ejemplo claro de obtención de metadatos sobre un archivo que ya está cargado en Almacenamiento, tomado directamente de
la documentación de los metadatos del archivo:
// Create a storage reference from our app
StorageReference storageRef = storage.getReferenceFromUrl("gs://");
// Get reference to the file
StorageReference forestRef = storageRef.child("images/forest.jpg");
forestRef.getMetadata().addOnSuccessListener(new OnSuccessListener() {
@Override
public void onSuccess(StorageMetadata storageMetadata) {
// Metadata now contains the metadata for 'images/forest.jpg'
}
}).addOnFailureListener(new OnFailureListener() {
@Override
public void onFailure(@NonNull Exception exception) {
// Uh-oh, an error occurred!
}
});
Aunque nunca veamos una "Task" en ningún lugar del código, en realidad hay una Task aquí. La última parte del código anterior se puede reescribir de manera equivalente como se indica a continuación:
Task task = forestRef.getMetadata();
task.addOnSuccessListener(new OnSuccessListener() {
@Override
public void onSuccess(StorageMetadata storageMetadata) {
// Metadata now contains the metadata for 'images/forest.jpg'
}
});
task.addOnFailureListener(new OnFailureListener() {
@Override
public void onFailure(@NonNull Exception exception) {
// Uh-oh, an error occurred!
}
});
¡Parece que después de todo había una
Task escondida en ese código!
¡Prometo que haré esto!
Con el código de muestra reescrito que se muestra más arriba, ahora es más claro cómo se utiliza una Task para obtener los metadatos del archivo. El método getMetadata() de StorageReference debe asumir que los metadatos del archivo no están disponibles inmediatamente, por lo que hará una solicitud de red para obtenerlos. De esta manera, para evitar el bloqueo del subproceso que realizó la llamada en ese acceso de red, getMetadata() devuelve una Task que se puede escuchar para el eventual éxito o falla. Luego, la API realiza la solicitud en un subproceso que controla. La API oculta los detalles de este subproceso, pero se utiliza la Task devuelta para indicar cuándo los resultados están disponibles. De esta forma, la Task devuelta garantiza que al finalizar se invocará cualquier escuchador agregado. Esta forma en que la API gestiona los resultados del trabajo asíncrono a veces recibe el nombre de
Promise en otros entornos de programación.
Nota que la Task devuelta se configura en parámetros por el tipo de StorageMetadata, y ese también es el tipo de objeto que pasa a onSuccess() en el
OnSuccessListener. De hecho, todas las Tasks deben declarar un tipo genérico de esta forma para indicar el tipo de datos que generan, y el OnSuccessListener debe compartir ese tipo genérico. Además, cuando se produce un error, se pasa una Excepción a onFailure() en el
OnFailureListener, que probablemente será la excepción específica que causó la falla. Si deseas saber más sobre esta Excepción, debes verificar su tipo para transmitirla en forma segura al tipo esperado.
Lo último que debes saber sobre este código es que se llamará a los escuchadores en el subproceso principal. La API Task se encarga de que esto suceda automáticamente. De esta manera, si deseas hacer algo en respuesta a la disponibilidad de los StorageMetadata en el subproceso principal, puedes hacerlo directamente en el método del escuchador. (¡Pero recuerda que igualmente no debes realizar ninguna tarea bloqueante en ese escuchador en el subproceso principal!) Existen algunas opciones sobre el modo en que trabajan estos escuchadores que explicaré en una publicación futura sobre las diferentes alternativas.
Solo tienes una oportunidad
Algunas funciones de Firebase ofrecen otras API que aceptan escuchadores no asociados con Tasks. Por ejemplo, si utilizas
Autenticación de Firebase, casi seguro has registrado un escuchador para descubrir cuándo el usuario accede o sale con éxito de tu app:
private FirebaseAuth auth = FirebaseAuth.getInstance();
private FirebaseAuth.AuthStateListener authStateListener = new FirebaseAuth.AuthStateListener() {
@Override
public void onAuthStateChanged(@NonNull FirebaseAuth firebaseAuth) {
// Welcome! Or goodbye?
}
};
@Override
protected void onStart() {
super.onStart();
auth.addAuthStateListener(authStateListener);
}
@Override
protected void onStop() {
super.onStop();
auth.removeAuthStateListener(authStateListener);
}
La API del cliente FirebaseAuth emite dos garantías principales aquí cuando agregas un escuchador con addAuthStateListener(). En primer lugar, llama inmediatamente a tu escuchador con el estado de acceso actualmente conocido para el usuario. Luego, llama al escuchador otra vez con
todos los cambios subsiguientes al estado de acceso del usuario, en tanto se agregue el escuchador al objeto FirebaseAuth. ¡Este comportamiento es muy diferente al modo en que trabaja Tasks!
Tasks solo llama a cualquier escuchador
como máximo una vez, y solo cuando el resultado está disponible. Además, Task invocará un escuchador
inmediatamente si el resultado ya estaba disponible antes de agregar al escuchador. El objeto de Task recuerda efectivamente el objeto del resultado final y continúa enviándolo a cualquier escuchador futuro, hasta que no haya más escuchadores y se convierta prácticamente en basura recolectada. Entonces, si estás usando una API de Firebase que trabaja con escuchadores en un elemento que no es un objeto de Task, asegúrate de comprender sus propios comportamientos y garantías.
¡No asumas que todos los escuchadores de Firebase se comportan como escuchadores de Task!
Y no te olvides este paso importante
Considera la vida útil activa de tus escuchadores de Task agregados. Si no lo haces, dos cosas pueden salir mal. En primer lugar, puedes ocasionar una pérdida de Actividad si Task continúa más allá de la vida útil de una Actividad y un escuchador agregado está referenciando sus Vistas. En segundo lugar, puede que el escuchador agregado se ejecute cuando ya no es necesario, lo que provocaría la realización de tareas innecesarias y posiblemente haría cosas que accedan al estado de la Actividad cuando ya no es válido. La siguiente parte de esta serie del blog tratará estos problemas en más detalle, y explicará cómo evitarlos.
Para concluir (la parte 1 de esta serie)
Hemos visto brevemente la API Play Services Task y descubrimos su (a veces oculto) uso en ciertos códigos de muestra de Firebase. Las Tasks son la manera en que Firebase te permite responder al trabajo que tiene una duración desconocida y se debe ejecutar fuera del subproceso principal. Tasks también permite que se ejecuten los escuchadores otra vez en el subproceso principal para gestionar el resultado del trabajo. Sin embargo, solamente vimos a grandes rasgos lo que Tasks puede hacer por ti. La próxima vez, veremos las variaciones de los escuchadores de Task, para que decidas cuál se adapta mejor a tus casos.
Si tienes alguna pregunta, puedes usar Twitter con el hashtag #AskFirebase o el
Grupo de Google firebase-talk. También tenemos un canal dedicado a Firebase Slack. Y puedes seguirme en
@CodingDoug en Twitter.
