Quand appeler le contexte contexte d’application OR d’activité ?

Question

Il y a eu beaucoup de poster sur ce qui, dans ces deux contextes sont.. Mais je ne suis toujours pas tout à fait à droite

Comme je l'ai compris: Chacun est une instance de sa classe, ce qui signifie que certains programmeurs vous recommandons d'utiliser cela.getcontexteapplication() aussi souvent que possible afin d'éviter toute "fuite" hors de la mémoire. C'est parce que l'autre "ce" (l'Activité de l'instance de contexte) points pour une Activité qui est détruit à chaque fois que l'utilisateur incline le téléphone ou laisser l'application etc.. Qui, apparemment, le Garbage Collector (GC) ne pas les attraper et à cet effet utilise trop de mémoire..

Mais quelqu'un peut s'il vous plaît venez avec quelques très bons exemples de code où ce serait la bonne chose à utiliser "ce" (mettre en place le contexte de l'Activité en cours d'instance) et le contexte de l'application sera inutile/mal??

Answer 1

getApplicationContext() est presque toujours tort. Mme Hackborn (entre autres) ont été très explicite sur le fait que vous seulement utiliser getApplicationContext() quand vous savez pourquoi vous utilisez getApplicationContext() , et seulement quand vous avez besoin d'utiliser getApplicationContext().

Pour être franc, "certains programmeurs" utiliser getApplicationContext() (ou getBaseContext(), dans une moindre mesure), parce que leur Java expérience est limitée. Ils mettent en œuvre un à l'intérieur de la classe (par exemple, un OnClickListener d'un Button en Activity) et ont besoin d'un Context. Plutôt que d'utiliser MyActivity.this d'obtenir à l'extérieur de la classe' this, ils utilisent l' getApplicationContext() ou getBaseContext() pour obtenir un Context objet.

Vous seulement utiliser getApplicationContext() lorsque vous savez vous avez besoin d'un Context pour quelque chose qui peut vivre plus longtemps que tout autre susceptible Context vous avez à votre disposition. Les scénarios incluent:

• Utiliser getApplicationContext() si vous besoin de quelque chose lié à un Context que lui-même aura une portée mondiale. J'utilise getApplicationContext(), par exemple, en WakefulIntentService, pour la statique WakeLock à être utilisée pour le service. Depuis, WakeLock est statique, et j'ai besoin d'un Context d'obtenir au PowerManager pour le créer, il est plus sûr d'utiliser getApplicationContext().

• Utiliser getApplicationContext() lorsque vous liez à un Service d'un Activity, si vous souhaitez passer l' ServiceConnection (c'est à dire, la poignée de la liaison) entre Activity instances via onRetainNonConfigurationInstance(). Android en interne des pistes de liaisons par l'intermédiaire de ces ServiceConnections et contient des références à l' Contexts que de créer les liaisons. Si vous liez à partir de l' Activity, puis le nouveau Activity exemple sera une référence à l' ServiceConnection qui a une référence implicite à la vieux - Activity, et le vieux - Activity ne peut pas être nettoyée.

Certains développeurs d'utiliser des sous-classes de Application de leur propre planète, ils récupèrent via getApplicationContext(). C'est certainement possible. Je préfère données membres statiques, si pour aucune autre raison que vous ne pouvez avoir qu' une coutume Application objet. J'ai construit une application à l'aide d'une coutume Application objet et l'a trouvé pour être douloureux. Mme Hackborn également en accord avec cette position.

Voici les raisons pourquoi ne pas utiliser getApplicationContext() partout où vous allez:

• C'est pas complète, Context, de soutenir tout ce qui Activity . Différentes choses que vous essayez de faire avec ce Context échouent, principalement liées à l'interface graphique.

• Il peut créer des fuites de mémoire, si l' Context de getApplicationContext() tient sur quelque chose de créé par vos appels sur ce que vous n'avez pas à nettoyer. Avec un Activity, si elle détient sur quelque chose, une fois que l' Activity obtient des ordures collectées, tout le reste bouffées de chaleur aussi. L' Application objet reste pour la durée de vie de votre processus.

Answer 2

Je pense qu'il y a beaucoup de choses qui est mal documenté sur le SDK site, c'est l'un d'entre eux. La demande que je vais faire, c'est qu'il me semble que c'est mieux de défaut à l'aide d'un contexte d'application et d'utiliser uniquement un contexte d'activité lorsque vous en avez vraiment besoin. Le seul endroit où j'ai jamais vu que vous avez besoin d'un contexte d'activité est pour une boîte de dialogue de progression. SBERG412 prétend que vous avez à utiliser un contexte d'activité pour un toast message, mais le Android docs montrent clairement un contexte d'application utilisé. J'ai toujours utilisé le contexte de l'application pour des toasts à cause de cela, Google exemple. Si c'est mal de le faire, Google a laissé tomber la balle ici.

Voici plus d'informations à réfléchir et à revoir:

Pour un toast message, le Google Dev Guide utilise le contexte de l'application et explicitement dire de l'utiliser: Les Notifications Toast

Dans les boîtes de dialogue de la section de la Dev guide, vous voyez qu'un AlertDialog.Le constructeur utilise le contexte de l'application, puis la barre de progression utilise un contexte d'activité. Ce n'est pas expliqué par Google. Les boîtes de dialogue

Il semble comme une bonne raison d'utiliser le contexte de l'application, c'est quand vous voulez pour gérer les modifications de configuration comme un changement d'orientation, et vous souhaitez conserver les objets qui ont besoin d'un contexte comme point de Vue. Si vous regardez ici: Exécuter les Changements de Temps Il y a une mise en garde sur l'utilisation d'un contexte d'activité, ce qui peut créer une fuite. Ceci peut être évité avec un contexte d'application avec les vues qui sont à conserver (au moins, c'est ma compréhension). Dans une application que je suis en train d'écrire, j'ai l'intention d'utiliser une application de contexte parce que je suis en train d'essayer de tenir plus de quelques points de vue et d'autres choses sur un changement d'orientation, et j'ai encore envie de l'activité à détruire et recréer à l'changements d'orientation. Donc je dois utiliser une application de contexte afin de ne pas provoquer une fuite de mémoire (voir en Évitant les Fuites de mémoire). Pour moi, il semble que il ya beaucoup de bonnes raisons pour utiliser le contexte de l'application au lieu d'un contexte d'activité, et pour moi, il semble presque comme vous l'utiliser plus souvent que d'un contexte d'activité. C'est ce que Android nombreux livres que j'ai traversé semblent le faire, et c'est ce que beaucoup de la Google les exemples que j'ai vu faire.

Le Google de la documentation donne vraiment l'impression d'utiliser le contexte de l'application est parfaitement bien dans la plupart des cas, et, en fait, apparaît le plus souvent à l'aide d'un contexte d'activité dans leurs exemples (au moins les exemples que j'ai vu). Si c'est vraiment un problème pour utiliser le contexte de l'application, Google a vraiment besoin de mettre plus d'accent sur ce point. Dont ils ont besoin pour faire clair, et ils ont besoin de refaire certaines de leurs exemples. Je ne le blâme pas totalement inexpérimentés développeurs car l'autorité (Google) a vraiment fait ressembler ce n'est pas un problème pour utiliser l'application à des contextes.

Answer 3

Which context to use?

Il existe deux types de Contexte:

Le contexte de l'Application est associée à l'application et sera toujours le même tout au long de la durée de vie de l'application, car il n'a pas changé. Donc, si vous utilisez des Toasts, vous pouvez utiliser le contexte de l'application ou même contexte d'activité (les deux) parce que les toasts peuvent être affichées à partir de n'importe où dans votre application et n'est pas attaché à une fenêtre spécifique. Mais il y a de nombreuses exceptions, la seule exception est lorsque vous avez besoin d'utiliser ou de transmettre le contexte d'activité.

Contexte d'activité est associé à l'activité et peuvent être détruits si l'activité est détruit -- il peut y avoir de multiples activités (plus que probable) avec une seule application. Et parfois, vous avez absolument besoin de l'activité handle de contexte de. Par exemple, si vous lancez une nouvelle activité, vous devez utiliser contexte d'activité dans son Intention, de sorte que le lancement de la nouvelle activité est liée à l'activité en cours en termes d'activité de la pile. Toutefois, vous pouvez utiliser l'application en contexte pour lancer une nouvelle activité, mais ensuite, vous devez définir l'indicateur Intent.FLAG_ACTIVITY_NEW_TASK dans l'intention de la traiter comme une nouvelle tâche.

Examinons quelques cas:

MainActivity.this se réfère à la MainActivity contexte qui s'étend de l'Activité de classe, mais la classe de base (activité) s'étend aussi au Contexte de la classe, de sorte qu'il peut être utilisé pour offrir contexte d'activité.

getBaseContext() offres contexte d'activité.

getApplication() offre de contexte de l'application.

getApplicationContext() propose également le contexte de l'application.

Pour plus d'informations, veuillez consulter ce lien.

Answer 4

Deux grands exemples d’où vous devez utiliser le contexte de l’activité par rapport au contexte de l’Application sont lors de l’affichage d’un message de Toast ou un message de dialogue intégré à utiliser le contexte de l’Application provoquera une exception :

ou

Ces deux ont besoin d’informations à partir du contexte d’activité qui n’est pas fourni dans le cadre de l’Application.

Answer 5

Contexte d’application live jusqu'à ce que votre application est vivante seulement et il n’est ne pas dépendre de Cycle de vie d’activité mais, contexte garder objet longue durée de vie. Si l’objet dont vous êtes temporaires utilisés, que temps utiliser le Contexte de l’Application et Le contexte de l’activité est utilisé totalement opposé du contexte d’Application.