Android: recommandations AsyncTask: classe privée ou classe publique?

Je développe actuellement des applications Android au sein d’une équipe et nous avons utilisé deux approches différentes au cours des derniers mois (l’une que je préfère personnellement et l’autre que le développeur préfère).

Bien que jusqu’à présent les résultats sont les mêmes, cela m’a fait me demander… devrions-nous:

  • utilisez AsyncTasks comme classes privées dans les activités qui les utilisent.
  • ou utilisez AsyncTasks comme classes publiques distinctes recevant le contexte de l’activité

Est-ce que certaines des approches recommandées par Google?

Que dit votre expérience à ce sujet (avantages, inconvénients, problèmes)?

Les classes internes sont appropriées pour représenter des objects destinés à être privés ou intimement liés à la classe englobante. Il y a parfois des raisons techniques pour utiliser des classes internes (par exemple, simuler des fermetures). Ils ont également réduit la pollution des espaces de noms.

Un inconvénient des classes internes est que si elles accèdent à des membres privés (champs ou fonctions) de la classe englobante, le compilateur générera des fonctions d’access à ces membres. Les puristes du langage se demanderont si cette rupture de l’encapsulation est une bonne ou une mauvaise chose. Les fonctions d’access ajoutent un peu de surcharge à chaque access (ce qui n’est généralement pas un facteur, mais c’est le cas). Un autre inconvénient est que cela rend le fichier source plus complexe et donc plus difficile à gérer. (J’ai parfois été piqué en éditant une fonction dans la classe interne tout en pensant qu’elle était dans la classe externe, et vice versa.) Enfin, les classes internes ne sont pas réutilisables, alors que des classes séparées peuvent souvent être paramétrées .

Ces avantages et ces inconvénients sont au dessus de ma tête. Je suis sûr que d’autres auront des pensées supplémentaires.

METTRE À JOUR:

Dans cette vidéo Google IO, l’option AsyncTask interne est clairement indiquée comme étant une mauvaise option.

Peu importe, utilisez ce qui convient le mieux à votre code. L’important est de rechercher une tâche asynchrone contenant une référence sur une activité après la destruction de l’activité, soit implicitement en tant que classe interne de l’activité, soit explicitement en recevant l’object activité / contexte.