Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Propósito de los parámetros de varianza de AsyncTask

¿Cuáles son las razones por las que Google utiliza varargs para los parámetros en AsyncTask ? Por ejemplo, los métodos execute() , doInBackground() y publishProgress() utilizan la notación [Type]...

Creo que hace que sea "más difícil" de usar por lo que debe tener algunas buenas razones que he pasado por alto?


Por lo tanto, tampoco tenemos parámetros, uno o muchos parámetros. Vamos a desglosar:

  1. Sin parámetros (fácil): Params parámetro es Void y eso es todo. (Los métodos no pueden usarlo … así que es bastante seguro.)

  2. Un parámetro : Aquí, al menos, siento la necesidad de hacer una comprobación al principio del método doInBackground() . Por ejemplo, aquí es una tarea que recibe un Integer y produce un resultado del tipo Double :

     public Double doInBackground(Integer... myParameters) { // we are only expecting one parameter if (myParameters.length != 1) throw new IllegalArgumentException("!= 1"); return 100d * myParameters[0]; } 
  3. Más de un parámetro . Ahora aquí debe ser donde Google hizo la elección correcta? Pero como veo es o usted está interesado en una lista de parámetros del mismo tipo , o usted quiere diversos tipos de parámetros. Google sólo se ocupó de uno de estos casos (con diferentes tipos se necesita algún tipo de interfaz común En muchos casos termino con Object... y que no es realmente tipo seguro …)


Entonces, ¿cuál es el problema si simplemente varargs las varargs completo? He aquí un subconjunto de los métodos:

 class AsyncTask<Param, Progress, Result> { abstract Result doInBackground(Param param); void publishProgress(Progress progress) { ... } } 

Esto funcionaría para todos los casos anteriores. Por ejemplo, si queremos manejar una matriz de parámetros, podríamos usar un param tipo array:

 class MyAsyncTask extends AsyncTask<String[], Integer, String> { String doInBackground(String[] param) { return Arrays.toString(param); } } 

No veo cuándo podría ser de uso práctico. Pero estoy seguro de que estoy perdiendo algo curia que debo saber. 🙂

  • ¿Cómo obtengo una variable en otra actividad?
  • Observable.empty () hace que java.util.NoSuchElementException: Secuencia no contiene elementos
  • ¿Cómo se puede detectar el modo avión en Android?
  • Rotar un mapa de bits guardado en android
  • Certificado de fijación en Android con Robospice
  • Grabación cifrada y carga descifrada de un ArrayList de objetos serializables
  • Dobles, comas y puntos
  • Cómo descomprimir el archivo de InputStream
  • 3 Solutions collect form web for “Propósito de los parámetros de varianza de AsyncTask”

    Creo que los argumentos vararg sólo hace que sea un poco más conveniente cuando se llama para ejecutar el AsyncTask .

    Mientras nos preguntamos por qué AsyncTask fue diseñado de la manera que es: 🙂

    En mi opinión, las plantillas Param y Result no habrían sido realmente necesarias para lograr lo mismo.

    Cuando escribes tu propia AsyncTask , la subclases. En lugar de declarar los tipos reales de Param y Result , también puede agregar campos finales a su subclase (Params) y agregar campos modificables a su subclase (Result). P.ej:

     public class MyAsyncTask extends AsyncTask<Void> { // Input Params private final int inParam1; private final String inParam2; // Output Results private Bitmap resultBitmap; public MyAsyncTask(int param1, String param2) { inParam1 = param1; inParam2 = param2; } @Override protected void doInBackground() { // use param1 and param2 as input to the background process. ... ... // Finished: assign to result resultBitmap = ....; } @Override protected void onPostExecute() { // Send result to UI. ... resultBitmap ... ... resultBitmap = null; } } 

    No se necesitan medicamentos genéricos, tal vez excepto para mostrar Progreso.

    Esto es lo que suelo hacer de todos modos, especialmente si el resultado es un Bitmap . El valor devuelto por doInBackground y manejado por onPostExecute no está configurado como null después de que todo está establecido y hecho y sneakily 'filtra' Bitmaps esta manera (errores de memoria causados ​​por mapas de bits almacenados en AsyncTasks finalizados o terminados).

    Creo que tienes razón, el único uso del parámetro de tipo Params está en Params... , lo que implica que es realmente el Params[] que se quiere aquí. Sin embargo, ahora la API sólo funciona con tipos de matriz, se pierde un montón de tipos de no-matriz.

    La única ventaja de varargs está en el sitio de la llamada, pero no es mucho tampoco –

    Versión de Google:

     AsyncTask<String> task = ... task.execute("a", "b"); 

    Tu versión:

     AsyncTask<List<String>> task = ... task.execute(Arrays.asList("a", "b")); 
    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.