LifecycleOwner — co to je, rozhraní Jetpack a předplatné událostí

LifecycleObserver a DefaultLifecycleObserver

Existují dva způsoby, jak se přihlásit k událostem LifecycleOwner: klasický LifecycleObserver s anotacemi a moderní DefaultLifecycleObserver s explicitními metodami. Druhý přístup doporučuje Google od roku 2022, protože poskytuje lepší typovou bezpečnost a vyhýbá se reflexi, která se používala v anotačním přístupu. DefaultLifecycleObserver vyžaduje Java 8+ nebo Kotlin a je preferován pro nové projekty.

Příklad přihlášení prostřednictvím DefaultLifecycleObserver:

class MyObserver : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // Spuštění GPS sledování pouze když je komponenta aktivní
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        // Bezpečné zastavení při přechodu do režimu na pozadí
        stopLocationUpdates()
    }
}

// Připojení:
lifecycleOwner.lifecycle.addObserver(MyObserver())

Každá metoda DefaultLifecycleObserver přijímá LifecycleOwner jako parametr. To umožňuje pozorovateli přistupovat ke kontextu prováděné komponenty bez nutnosti jej předávat samostatně. Tento přístup činí kód modulárnějším a testovatelnějším — Observer není závislý na konkrétní implementaci Activity nebo Fragment, ale pracuje s abstrakcí LifecycleOwner.

Anotační přístup LifecycleObserver

Starý způsob s použitím anotace @OnLifecycleEvent se stále vyskytuje ve starších projektech, ale jeho použití se nedoporučuje pro nový kód. Reflexe potřebná pro zpracování anotací přidává režii a může vést k chybám, které nejsou odhaleny ve fázi kompilace. Google oficiálně doporučuje migraci na DefaultLifecycleObserver.

// Zastaralý přístup — nedoporučuje se pro nové projekty
class MyLegacyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        startLocationUpdates()
    }

    @OnLifecycleEvent(Lifecycle.Event.ON_STOP)
    fun onStop() {
        stopLocationUpdates()
    }
}

Anotační přístup má významný nedostatek: chybějící kontrolu životnosti Observeru. Pokud vývojář zapomene odhlásit Observer při zničení LifecycleOwner, objekt Observer zůstane v paměti až do spuštění garbage collectoru. DefaultLifecycleObserver tento problém řeší — Observer je připojen k Lifecycle a automaticky se odhlašuje při přechodu do stavu DESTROYED.

LifecycleOwner v Activity a Fragment

Od AppCompat 1.1.0 a AndroidX Fragment 1.2.0 jsou všechny Activity a Fragment, které dědí z AppCompatActivity nebo Fragment, automaticky LifecycleOwner. To znamená, že metoda getLifecycle() je v nich k dispozici ve výchozím nastavení a přihlašování k událostem životního cyklu funguje bez další konfigurace. Vývojář stačí zavolat lifecycle.addObserver() z libovolného místa v Activity nebo Fragment.

Podívejme se na příklad integrace LifecycleOwner v Activity:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        lifecycle.addObserver(LocationObserver(this))
    }
}

V tomto příkladu je lifecycle extension property dostupná díky AndroidX Activity. Observer LocationObserver bude automaticky dostávat oznámení o spuštění (ON_START) a zastavení (ON_STOP) Activity. Při otáčení obrazovky je Observer informován o ON_DESTROY a poté o ON_CREATE, což umožňuje správné zpracování změn konfigurace bez dalšího kódu.

LifecycleOwner ve Fragment

Fragment implementuje LifecycleOwner prostřednictvím rozhraní a jeho Lifecycle je vázán na životní cyklus Fragmentu, nikoli na nadřazené Activity. To je důležité: Lifecycle Fragmentu přechází do DESTROYED, když je Fragment odstraněn z transakce, zatímco Activity může zůstat v RESUMED. Tento rozdíl umožňuje Observeru přihlásit se samostatně k životnímu cyklu každé komponenty.

class MyFragment : Fragment() {
    private val uiStateObserver = UiStateObserver()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        lifecycle.addObserver(uiStateObserver)
    }
}

Důležitou výhodou použití LifecycleOwner ve Fragmentu je automatické odhlášení při přechodu Fragmentu do DESTROYED. To je obzvláště důležité pro ViewPager, kde mohou být Fragmenty dynamicky vytvářeny a ničeny. Ruční správa předplatných v tomto scénáři by byla extrémně složitá a náchylná k chybám.

Vytvoření vlastního LifecycleOwner

Rozhraní LifecycleOwner lze implementovat v libovolné třídě, která má životní cyklus. To je užitečné pro Custom Views, Service a dokonce i ViewModel v některých architektonických řešeních. Google poskytuje pomocnou třídu LifecycleRegistry, která spravuje stav Lifecycle a generuje události. Vývojář musí ručně volat příslušné metody LifecycleRegistry při změně stavu komponenty.

Příklad implementace LifecycleOwner v Custom View:

class MyCustomView(
    context: Context,
    attrs: AttributeSet?
) : FrameLayout(context, attrs), LifecycleOwner {

    private val lifecycleRegistry = LifecycleRegistry(this)

    override val lifecycle: Lifecycle
        get() = lifecycleRegistry

    fun onStart() {
        lifecycleRegistry.setCurrentState(Lifecycle.State.STARTED)
    }

    fun onStop() {
        lifecycleRegistry.setCurrentState(Lifecycle.State.CREATED)
    }
}

V tomto příkladu LifecycleRegistry funguje jako úložiště stavu. Metody onStart/onStop by měla volat nadřazená komponenta (např. Activity), když se Custom View stane viditelným nebo skryje. LifecycleRegistry automaticky vypočítává potřebné události pro přechod mezi stavy a informuje všechny přihlášené Observery.

Při implementaci vlastního LifecycleOwner je důležité dodržovat pravidlo: stav LifecycleRegistry by měl být aktualizován jako poslední v příslušné metodě životního cyklu, po všech ostatních operacích. To zaručuje, že Observery obdrží oznámení, když je komponenta plně připravena na nový stav. Použití LifecycleRegistry.createUnsafe jako alternativy je také možné, ale vyžaduje opatrnost s vlákny.

LifecycleOwner v komponentách Jetpack

LifecycleOwner je základem pro několik klíčových komponent Android Jetpack. LiveData používá LifecycleOwner k určení aktivního stavu a automatickému odhlášení při zničení komponenty. ViewModel přímo neimplementuje LifecycleOwner, ale může získat Lifecycle prostřednictvím SavedStateHandle. Navigation Component používá LifecycleOwner pro správu předplatných v NavBackStackEntry. Pochopení této souvislosti pomáhá budovat architekturu aplikace na pevném základě.

Interakce LiveData s LifecycleOwner:

class ExampleActivity : AppCompatActivity() {
    private val viewModel: ExampleViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        viewModel.userData.observe(this) { data ->
            // this — LifecycleOwner (Activity)
            // Kód se provádí pouze když je Activity ve stavu RESUMED
            updateUI(data)
        }
    }
}

LiveData vyžaduje LifecycleOwner v metodě observe(), protože to zaručuje, že aktualizace uživatelského rozhraní proběhnou pouze v aktivním stavu. Pokud je Activity na pozadí, LiveData uchovává poslední hodnotu, ale neinformuje Observer. Při návratu do RESUMED obdrží Observer aktuální hodnotu bez dalších požadavků na síť nebo databázi.

DataBinding také používá LifecycleOwner pro vázání observable polí k životnímu cyklu Activity nebo Fragment. To umožňuje předcházet únikům paměti v kombinaci ViewModel + DataBinding — všechna předplatná jsou automaticky vyčištěna při zničení LifecycleOwner. Tento přístup činí kód deklarativním a bezpečným.

Doporučení pro použití

Správné použití LifecycleOwner vyžaduje dodržování několika klíčových pravidel. První a nejdůležitější: vždy přihlašujte Observer v onCreate/onViewCreated, ne později. To zaručuje, že Observer obdrží počáteční stav Lifecycle (CREATED po onCreate) a nezmešká události. Druhé pravidlo: používejte DefaultLifecycleObserver místo anotačního přístupu pro všechny nové projekty.

• Neukládejte referenci na LifecycleOwner do statických polí nebo singletonů — vede to k úniku celého Activity
• Kontrolujte stav Lifecycle pomocí getCurrentState() před prováděním operací citlivých na stav
• Nevytvářejte Observer uvnitř lambd — každá rekompozice vytvoří nový objekt a staré Observery se automaticky neodhlásí
• Používejte repeatOnLifecycle pro korutiny — blok se spouští při vstupu do určeného stavu a ruší se při výstupu z něj
• Nevolejte setCurrentState v LifecycleRegistry z vlákna na pozadí — to porušuje záruky jednovláknovosti životního cyklu

Moderní přístup k práci s korutinami a LifecycleOwner — rozšíření repeatOnLifecycle:

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.flow.collect { value ->
            updateUI(value)
        }
    }
}

Tento vzor zaručuje, že collect na Flow je aktivní pouze ve stavu STARTED nebo RESUMED. Při přechodu do STOPPED je kolekce automaticky zrušena a při návratu do STARTED — znovu spuštěna. repeatOnLifecycle nahrazuje ruční odhlašování z Flow ve Fragmentu a je doporučeným přístupem Google pro práci s asynchronními datovými toky v komponentách uživatelského rozhraní.

Další důležité doporučení: nezneužívejte LifecycleObserver pro logiku nesouvisející s životním cyklem. Pokud má komponenta provést akci v určitém stavu, ale nevyžaduje odhlášení při zničení, je lepší použít explicitní volání metod v onStart/onStop. LifecycleObserver je ospravedlnitelný pro dlouho žijící komponenty (LocationListener, SensorManager), kde je ruční správa předplatných složitá a náchylná k chybám.