LifecycleOwner — cos'è, interfaccia Jetpack e sottoscrizione eventi

Cos'è LifecycleOwner?

LifecycleOwner — è un'interfaccia del pacchetto androidx.lifecycle che contiene un unico metodo getLifecycle() che restituisce un oggetto Lifecycle. Questo oggetto traccia lo stato corrente del componente (CREATED, STARTED, RESUMED, DESTROYED) e notifica tutti gli osservatori sottoscritti quando cambia. LifecycleOwner fa parte degli Architecture Components ed è incluso nella libreria lifecycle-runtime.

Il compito principale dell'interfaccia è standardizzare l'accesso al ciclo di vita. Prima di Jetpack, gli sviluppatori usavano la sottoscrizione manuale in onStart e la cancellazione in onStop, causando duplicazione di codice ed errori. LifecycleOwner risolve questo problema fornendo un meccanismo unificato per tutti i componenti Android. Invece di chiamare esplicitamente i metodi del ciclo di vita, lo sviluppatore si sottoscrive una volta al Lifecycle e le notifiche arrivano automaticamente.

L'interfaccia è dichiarata in Kotlin come interfaccia funzionale con un unico metodo astratto:

interface LifecycleOwner {
    val lifecycle: Lifecycle
}

Grazie alla natura funzionale dell'interfaccia, è facile da implementare usando un delegato o una lambda. Ciò è particolarmente conveniente per creare Custom Views e classi ViewModel che devono reagire ai cambiamenti del ciclo di vita dell'host. L'oggetto Lifecycle ottenuto da getLifecycle() fornisce i metodi addObserver e removeObserver per gestire le sottoscrizioni.

Come funziona LifecycleOwner

LifecycleOwner lavora in combinazione con due classi chiave: Lifecycle e LifecycleObserver. Lifecycle memorizza lo stato corrente del componente come enum State (INITIALIZED, CREATED, STARTED, RESUMED, DESTROYED) e traccia le transizioni tra di essi. Quando lo stato cambia, Lifecycle notifica tutti gli osservatori registrati, chiamando i corrispondenti metodi annotati. Questo meccanismo è chiamato "lifecycle-aware" — il codice viene eseguito solo quando il componente si trova in uno stato appropriato.

Il meccanismo di trasmissione degli eventi si basa sul pattern Observer. LifecycleOwner funge da Observable, mentre l'implementazione di LifecycleObserver funge da Observer. Activity o Fragment, quando cambia il proprio stato (onCreate → onStart → onResume → onPause → onStop → onDestroy), notifica Lifecycle tramite il meccanismo interno ReportFragment, che viene aggiunto automaticamente al sistema AndroidX. Lo sviluppatore non deve chiamare manualmente i metodi di Lifecycle — tutto avviene automaticamente.

Un dettaglio importante: Lifecycle garantisce che gli eventi ON_STOP e ON_DESTROY verranno consegnati anche in caso di crash del processo. Questo rende LifecycleOwner uno strumento affidabile per liberare risorse critiche. Per il salvataggio dello stato normale, si raccomanda di utilizzare SavedStateHandle in ViewModel, ma LifecycleOwner fornisce un livello di sicurezza di base.

LifecycleObserver e DefaultLifecycleObserver

Esistono due modi per sottoscriversi agli eventi di LifecycleOwner: il classico LifecycleObserver con annotazioni e il moderno DefaultLifecycleObserver con metodi espliciti. Il secondo approccio è raccomandato da Google dal 2022 poiché offre una migliore sicurezza dei tipi ed evita la riflessione utilizzata nell'approccio ad annotazioni. DefaultLifecycleObserver richiede Java 8+ o Kotlin ed è preferibile per i nuovi progetti.

Esempio di sottoscrizione tramite DefaultLifecycleObserver:

class MyObserver : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // Avvia il tracciamento GPS solo quando il componente è attivo
        startLocationUpdates()
    }

    override fun onStop(owner: LifecycleOwner) {
        // Arresto sicuro al passaggio in modalità background
        stopLocationUpdates()
    }
}

// Connessione:
lifecycleOwner.lifecycle.addObserver(MyObserver())

Ogni metodo di DefaultLifecycleObserver accetta LifecycleOwner come parametro. Ciò consente all'osservatore di accedere al contesto del componente in esecuzione senza doverlo passare separatamente. Questo approccio rende il codice più modulare e testabile — l'Observer non dipende da una specifica implementazione di Activity o Fragment, ma lavora con l'astrazione LifecycleOwner.

Approccio ad annotazioni LifecycleObserver

Il vecchio metodo con l'annotazione @OnLifecycleEvent si trova ancora in progetti legacy, ma il suo uso non è raccomandato per il nuovo codice. La riflessione necessaria per elaborare le annotazioni aggiunge overhead e può causare errori non rilevati in fase di compilazione. Google consiglia ufficialmente di migrare a DefaultLifecycleObserver.

// Approccio obsoleto — non raccomandato per nuovi progetti
class MyLegacyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        startLocationUpdates()
    }

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

L'approccio ad annotazioni ha uno svantaggio significativo: mancanza di controllo sulla durata di vita dell'Observer. Se lo sviluppatore dimentica di cancellare l'Observer quando il LifecycleOwner viene distrutto, l'oggetto Observer rimane in memoria fino alla chiamata del garbage collector. DefaultLifecycleObserver risolve questo problema — l'Observer è legato al Lifecycle e viene automaticamente cancellato al passaggio allo stato DESTROYED.

LifecycleOwner in Activity e Fragment

A partire da AppCompat 1.1.0 e AndroidX Fragment 1.2.0, tutte le Activity e i Fragment che ereditano da AppCompatActivity o Fragment sono automaticamente LifecycleOwner. Ciò significa che il metodo getLifecycle() è disponibile per impostazione predefinita e la sottoscrizione agli eventi del ciclo di vita funziona senza configurazione aggiuntiva. Lo sviluppatore deve solo chiamare lifecycle.addObserver() da qualsiasi punto dell'Activity o del Fragment.

Consideriamo un esempio di integrazione di LifecycleOwner in una Activity:

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

In questo esempio, lifecycle è una extension property disponibile grazie ad AndroidX Activity. L'osservatore LocationObserver riceverà automaticamente notifiche sull'avvio (ON_START) e l'arresto (ON_STOP) dell'Activity. Durante la rotazione dello schermo, l'Observer viene notificato di ON_DESTROY e poi ON_CREATE, consentendo di gestire correttamente i cambi di configurazione senza codice aggiuntivo.

LifecycleOwner in Fragment

Fragment implementa LifecycleOwner tramite l'interfaccia e il suo Lifecycle è legato al ciclo di vita del Fragment, non all'Activity padre. Questo è importante: il Lifecycle del Fragment passa a DESTROYED quando il Fragment viene rimosso dalla transazione, mentre l'Activity può rimanere in RESUMED. Questa differenza consente all'Observer di sottoscriversi separatamente al ciclo di vita di ciascun componente.

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

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

Un vantaggio importante dell'uso di LifecycleOwner in Fragment è la cancellazione automatica quando il Fragment passa a DESTROYED. Ciò è particolarmente rilevante per ViewPager, dove i Fragment possono essere creati e distrutti dinamicamente. La gestione manuale delle sottoscrizioni in questo scenario sarebbe estremamente complessa e soggetta a errori.

Creare un proprio LifecycleOwner

L'interfaccia LifecycleOwner può essere implementata in qualsiasi classe che abbia un ciclo di vita. Ciò è utile per Custom Views, Services e persino ViewModel in alcune soluzioni architetturali. Google fornisce la classe helper LifecycleRegistry che gestisce lo stato del Lifecycle e genera eventi. Lo sviluppatore deve chiamare manualmente i corrispondenti metodi di LifecycleRegistry quando lo stato del componente cambia.

Esempio di implementazione di LifecycleOwner in una 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)
    }
}

In questo esempio, LifecycleRegistry funge da archivio di stato. I metodi onStart/onStop devono essere chiamati dal componente padre (ad esempio Activity) quando la Custom View diventa visibile o viene nascosta. LifecycleRegistry calcola automaticamente gli eventi necessari per la transizione tra stati e notifica tutti gli Observer sottoscritti.

Nell'implementare il proprio LifecycleOwner, è importante seguire la regola: lo stato di LifecycleRegistry deve essere aggiornato per ultimo nel corrispondente metodo del ciclo di vita, dopo tutte le altre operazioni. Ciò garantisce che l'Observer riceva la notifica quando il componente è già completamente pronto per il nuovo stato. L'uso di LifecycleRegistry.createUnsafe come alternativa è possibile, ma richiede cautela con i thread.

LifecycleOwner nei componenti Jetpack

LifecycleOwner è il fondamento per diversi componenti chiave di Android Jetpack. LiveData usa LifecycleOwner per determinare lo stato attivo e cancellare automaticamente la sottoscrizione alla distruzione del componente. ViewModel non implementa direttamente LifecycleOwner ma può ottenere Lifecycle tramite SavedStateHandle. Navigation Component usa LifecycleOwner per gestire le sottoscrizioni in NavBackStackEntry. Comprendere questa interrelazione aiuta a costruire un'architettura dell'applicazione su basi solide.

Interazione di LiveData con 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)
            // Il codice viene eseguito solo quando l'Activity è nello stato RESUMED
            updateUI(data)
        }
    }
}

LiveData richiede LifecycleOwner nel metodo observe() perché questo garantisce che gli aggiornamenti dell'interfaccia utente avvengano solo nello stato attivo. Se l'Activity è in background, LiveData conserva l'ultimo valore ma non notifica l'Observer. Al ritorno in RESUMED, l'Observer riceve il valore corrente senza ulteriori richieste di rete o database.

DataBinding utilizza anch'esso LifecycleOwner per legare i campi osservabili al ciclo di vita dell'Activity o del Fragment. Ciò consente di evitare perdite di memoria nella combinazione ViewModel + DataBinding — tutte le sottoscrizioni vengono automaticamente pulite alla distruzione del LifecycleOwner. Questo approccio rende il codice dichiarativo e sicuro.

Raccomandazioni d'uso

L'uso corretto di LifecycleOwner richiede il rispetto di diverse regole chiave. La prima e più importante: sottoscrivi sempre l'Observer in onCreate/onViewCreated, non dopo. Questo garantisce che l'Observer riceva lo stato iniziale del Lifecycle (CREATED dopo onCreate) e non perda eventi. Seconda regola: usa DefaultLifecycleObserver invece dell'approccio ad annotazioni per tutti i nuovi progetti.

• Non memorizzare il riferimento a LifecycleOwner in campi statici o singleton — causa la perdita dell'intera Activity
• Verifica lo stato del Lifecycle tramite getCurrentState() prima di eseguire operazioni sensibili allo stato
• Non creare Observer all'interno di lambda — ogni ricomposizione creerà un nuovo oggetto e i vecchi Observer non verranno cancellati automaticamente
• Usa repeatOnLifecycle per le coroutine — il blocco viene avviato all'ingresso nello stato specificato e cancellato all'uscita
• Non chiamare setCurrentState in LifecycleRegistry da un thread in background — viola le garanzie di single-thread del ciclo di vita

L'approccio moderno per lavorare con coroutine e LifecycleOwner — l'estensione repeatOnLifecycle:

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

Questo pattern garantisce che collect su Flow sia attivo solo nello stato STARTED o RESUMED. Al passaggio a STOPPED, la raccolta viene automaticamente cancellata e al ritorno a STARTED viene riavviata. repeatOnLifecycle sostituisce la cancellazione manuale della sottoscrizione da Flow in Fragment ed è l'approccio raccomandato da Google per lavorare con flussi di dati asincroni nei componenti dell'interfaccia utente.

Un'altra raccomandazione importante: non abusare di LifecycleObserver per logiche non correlate al ciclo di vita. Se un componente deve eseguire un'azione in uno stato specifico ma non richiede la cancellazione alla distruzione, è meglio usare chiamate esplicite di metodi in onStart/onStop. LifecycleObserver è giustificato per componenti di lunga durata (LocationListener, SensorManager) dove la gestione manuale delle sottoscrizioni è complessa e soggetta a errori.