EDITAR : Esta pregunta no es un duplicado como
- Hace solo un par de días se realizó el compromiso de AOSP con respecto a la degradación.
- La otra pregunta es sobre el uso de AsyncTaskLoader sobre AsyncTask.
Google está desaprobando la API de Android AsyncTask en Android 11 y sugiere usar java.util.concurrent
en su lugar. puedes ver el commit aquí
*
* @deprecated Use the standard <code>java.util.concurrent</code> or
* <a href="https://developer.android.com/topic/libraries/architecture/coroutines">
* Kotlin concurrency utilities</a> instead.
*/
@Deprecated
public abstract class AsyncTask<Params, Progress, Result> {
Si mantiene una base de código más antigua con tareas asincrónicas en Android, es probable que tenga que cambiarla en el futuro. Mi pregunta es cuál debería ser el reemplazo adecuado del fragmento de código que se muestra a continuación utilizando java.util.concurrent
. Es una clase interna estática de una Actividad. Estoy buscando algo que funcioneminSdkVersion 16
private static class LongRunningTask extends AsyncTask<String, Void, MyPojo> {
private static final String TAG = MyActivity.LongRunningTask.class.getSimpleName();
private WeakReference<MyActivity> activityReference;
LongRunningTask(MyActivity context) {
activityReference = new WeakReference<>(context);
}
@Override
protected MyPojo doInBackground(String... params) {
// Some long running task
}
@Override
protected void onPostExecute(MyPojo data) {
MyActivity activity = activityReference.get();
activity.progressBar.setVisibility(View.GONE);
populateData(activity, data) ;
}
}
AsyncTask
no se puede eliminar sin romper la compatibilidad con versiones anteriores.Respuestas:
Buena idea de que está en desuso, porque
WeakReference<Context>
siempre fue un truco, y no una solución adecuada .Ahora las personas tendrán la oportunidad de desinfectar su código.
Basado en este código, en
Progress
realidad no es necesario, y hay unaString
entrada +MyPojo
salida.En realidad, esto es bastante fácil de lograr sin el uso de AsyncTask.
¿Cómo pasar la cuerda? Al igual que:
Y
Este ejemplo utilizó un grupo de subprocesos único que es bueno para las escrituras de DB (o solicitudes de red serializadas), pero si desea algo para lecturas de DB o solicitudes múltiples, puede considerar la siguiente configuración de Ejecutor:
fuente
executor.post
. No se puede resolver el métodoexecute()
lugar depost()
Context
esto? Sé que pasar unContext
intoAsyncTask
fue uno de sus problemas.newSingleThreadExecutor
es mejor para las escrituras, pero definitivamente debe usarTHREAD_POOL_EXECUTOR
al final de la publicación para las lecturas de la base de datos.Google recomienda utilizar el marco de simultaneidad de Java o Kotlin Coroutines. pero Rxjava termina teniendo mucha más flexibilidad y características que la concurrencia de Java, por lo que ganó bastante popularidad.
fuente