hilos - Android: recomendaciones de AsyncTask: clase privada o clase pública?
hilos asynctask android (2)
Actualmente estoy desarrollando algunas aplicaciones de Android en un equipo y hemos usado 2 enfoques diferentes durante los últimos meses (uno que personalmente prefiero, y el otro que el otro desarrollador prefiere).
Aunque hasta ahora los resultados son los mismos, esto me hizo preguntarme ... si deberíamos:
- use AsyncTasks como clases privadas dentro de las Actividades que las usan.
- o use AsyncTasks como clases públicas separadas que reciben el contexto de la actividad
¿Alguno de los enfoques recomendados por Google?
¿Qué dice tu experiencia sobre esto (ventajas, desventajas, problemas)?
Las clases internas son buenas para representar objetos que están destinados a ser privados o, de alguna manera, íntimamente ligados a la clase adjunta. Ocasionalmente, hay razones técnicas para usar clases internas (por ejemplo, simular cierres). También reducen la contaminación del espacio de nombres.
Una desventaja de las clases internas es que si acceden a miembros privados (campos o funciones) de la clase envolvente, el compilador generará funciones de acceso a esos miembros. Los puristas del lenguaje discutirán si esta ruptura de la encapsulación es una cosa buena o mala. Las funciones de acceso agregan un poco de sobrecarga a cada acceso (lo que generalmente no es un factor, pero ahí está). Otra desventaja es que hace que el archivo de origen sea más complejo y, por lo tanto, más difícil de administrar. (De vez en cuando me picó al editar una función en la clase interna mientras pensaba que estaba en la clase externa, y viceversa.) Finalmente, las clases internas tienden a no ser reutilizables, mientras que las clases separadas a menudo se pueden parametrizar para tener múltiples usos .
Estos pros y contras están fuera de mi cabeza. Estoy seguro de que otros tendrán pensamientos adicionales.
ACTUALIZAR:
En este video Google IO, la opción AsyncTask interna está claramente marcada como una opción incorrecta.
No importa, use lo que tenga más sentido para su código. Lo importante es observar una tarea asíncrona que tenga una referencia en una actividad después de que la actividad haya sido destruida, ya sea implícitamente como una clase interna de la actividad, o explícitamente al recibir la actividad / objeto de contexto.