To będzie bardzo krótki wpis, w którym dowiedziecie się jak jest różnica pomiędzy dwoma różnymi kontekstami w aplikacji na Androida – Activity Context oraz Application Context 😎.

U samych podstaw Context jest zwyczajną klasą abstrakcyjną, która jest implementowana przez system Android zgodnie z aktualnymi potrzebami. Context jest obiektem, który przechowuje wszystkie istotne dane związane z aktualnym stanem naszej aplikacji lub danego obiektu (np. aktywności). Pozwala on m.in na rozeznanie się w sytuacji nowo utworzonym obiektom, które będą potrzebowały określonych informacji związanych z funkcjonowaniem aplikacji. Dzięki niemu możemy też wykonywać operacje o charakterze „globalnym” (komunikacja pomiędzy poszczególnymi komponentami aplikacji), takie jak np. wysyłanie intentów, uruchamianie nowych aktywności, dostęp do zasobów aplikacji (resources) lub lokalnych baz danych.

Bardzo duża ilość obiektów wykorzystuje klasę abstrakcyjną Context, ale najczęściej będziemy wykorzystywali obiekty Application oraz Activity. Niewłaściwy wybór jednego z nich może doprowadzić do wycieków pamięci (a tego nie chcemy 😝).

 

Memory Leak – jak wycieka pamieć? Android.

 

Jeżeli chcecie sprawdzić pozostałe obiekty z biblioteki Androida, które wykorzystują klasę Context, to możecie przejrzeć oficjalna dokumentację:

 

Klasa abstrakcyjna Context.

 

Activity Context

 

Kontekst dostępny na poziomie aktywności, w której się aktualnie znajdujemy. Jest on ściśle powiązany z jej cyklem życia. Context ten powinien być wykorzystywany tylko jeżeli obiekt, który będzie z niego korzystał również powiązany z długością życia danej aktywności / kontekstu. Acitivity Context wykorzystujemy głównie w przypadku korzystania z elementów UI zarządzanych przez daną aktywność (znajdujących się w ramach jej „kontekstu”). Standardowym przykładem są Toasty oraz Snackbary.

Jeżeli tworzony przez nas obiekt jest zależny od danej aktywności – jest on wykorzystywany tylko przez nią lub tylko z nią współpracuje – to powinniśmy korzystać z Acitivty Context. Pomoże to w zapobieganiu wyciekom pamięci. Jeżeli utworzony przez nas obiekt będzie korzystał z Application Context (który siedzi sobie w pamięci aplikacji aż do jej zamknięcia) to istnieje duże ryzyko, że po zamknięciu wykorzystującej go aktywności nie zostanie on prawidłowo usunięty i będzie niepotrzebnie zajmował bardzo cenną przestrzeń w pamięci urządzenia. Obiekt Activity po zakończeniu swojego żywota zostanie usunięty z pamięci przez garabge collector (no chyba, że namieszaliśmy 😝), a wraz z nim powinny z pamięci zniknąć zależne obiekty, o ile oczywiście jasno nie zaznaczyliśmy inaczej (jak w przypadku obiektów Service).

 

Application Context

 

Jest obiektem typu Singleton, do którego możemy uzyskać dostęp za pomocą funkcji getApplicationContext(). Jest ściśle powiązany z cyklem życia aplikacji (procesu). Korzystamy z niego gdy potrzebujemy kontekstu wykraczającego poza ten lokalny (jak w przypadku aktywności). Dobrym przykładem jest potrzeba utworzenia instancji obiektu typu Singleton, który do działania będzie potrzebował danych o globalnym stanie naszej aplikacji (jak choćby obiekt pochodny klasy Application). Obiekty typu Singleton domyślnie istnieją w pamięci urządzenia, aż do zakończenia działania aplikacji. Przekazując do nich kontekst aktywności (zamiast aplikacji), ryzykujemy, że dana aktywność (po zakończeniu swojego cyklu) nie zostanie poprawnie usunięta z pamięci przez garbage collector.

W skrócie – starajcie się zawsze w pierwszej kolejności korzystać z kontekstu, znajdującego się najbliżej Waszego obiektu. Jeżeli jednak jesteście pewni, że jego cykl życia będzie wykraczał poza cykl życia „otaczającego” go obiektu, to skorzystajcie z kontekstu globalnego.

I to właściwie na tyle. Taka szybka notatka spisana z potrzeby chwili 🤩.

 

 


 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *