onRestart — essentie, herstel van Activity in de levenscyclus

onRestart — essentie van de methode in de Android-levenscyclus

onRestart — een callback-methode die Android strikt vóór onStart aanroept, wanneer Activity terugkeert van de onzichtbare Stopped-status naar de zichtbare status. Deze methode is uniek omdat deze alleen wordt aangeroepen bij herhaalde weergave van Activity — bij de eerste instantiecreatie begint de reeks met onCreate, waarbij onRestart wordt overgeslagen. Volledige cyclus: onCreate → onStart → onResume (eerste start) of onRestart → onStart → onResume (herhaalde weergave).

Vanuit het oogpunt van het Android-systeem is onRestart een optimalisatie waarmee Activity zich kan voorbereiden op terugkeer: gegevens uit de repository bijwerken, de UI-status synchroniseren, de netwerkverbinding controleren. In tegenstelling tot onResume, dat elke keer wordt aangeroepen bij het verkrijgen van focus (inclusief bij terugkeer uit een dialoog of het systeemmenu), wordt onRestart alleen geactiveerd bij de volledige cyclus van verbergen-terugkeer. Dit maakt onRestart de ideale plek voor „zware“ update-operaties die niet nodig zijn bij gedeeltelijk focusverlies.

Volgens de specificatie van de Android Activity-levenscyclus kan het tijdsinterval tussen onStop en onRestart variëren van enkele seconden (gebruiker schakelde snel) tot enkele uren (app was op de achtergrond en gebruiker keerde terug). Gedurende deze tijd kunnen gegevens in de externe bron (API, DB) zijn gewijzigd, daarom is onRestart het natuurlijke punt om actualiteit te controleren.

Wanneer wordt onRestart aangeroepen: voorwaarden en volgorde

onRestart wordt alleen aangeroepen bij terugkeer van Activity uit de Stopped-status, waarin Activity is gekomen na het aanroepen van onStop. Hieronder staan alle scenario's die tot onRestart leiden.

Scenario's voor het aanroepen van onRestart:

• Terugkeer uit een andere Activity — gebruiker opende een nieuwe Activity (bijvoorbeeld klikte op een melding) en keerde daarna terug (drukte op „Terug“). Stack: MainActivity.onPause → MainActivity.onStop → SecondActivity wordt aangemaakt → gebruiker drukt op „Terug“ → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Terugkeer uit minimalisatie — gebruiker minimaliseerde de app (Home) en keerde na enige tijd terug. CurrentActivity.onPause → CurrentActivity.onStop → (app op achtergrond) → gebruiker keert terug → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Terugkeer van het vergrendelscherm — het vergrendelscherm bedekt Activity; na ontgrendeling krijgt Activity onRestart als er aanzienlijke tijd is verstreken (meer dan 5 seconden).
• Terugkeer uit een via Intent gestarte app — camera, galerij, browser — elke app van derden gestart via startActivityForResult() of ActivityResultLauncher.

Wanneer onRestart NIET wordt aangeroepen: bij schermrotatie (Activity wordt vernietigd en opnieuw aangemaakt via onCreate), bij terugkeer uit een dialoogvenster (Activity gaat niet naar onStop, alleen onPause → onResume), bij process death (Activity wordt opnieuw aangemaakt).

Verschil tussen onRestart en onCreate: wat te kiezen

onRestart en onCreate zijn twee verschillende benaderingen voor het herstellen van Activity. De keuze hangt af van of Activity volledig is vernietigd of alleen verborgen.

Keuzeregel: initialiseer View en abonneer op LiveData/StateFlow in onCreate (of onViewCreated voor Fragment). Gegevens bijwerken, lijsten opnieuw laden en status controleren — in onRestart. Als gegevens worden geladen via ViewModel, kan onRestart eenvoudig de methode refresh() op ViewModel aanroepen, en View abonneert zich op de bijgewerkte gegevens via de reactieve stroom.

Google adviseert: dupliceer de logica van onCreate niet in onRestart. Scheid in ViewModel de methoden refresh() die actuele gegevens laden en roep ze aan in onRestart. Dit behoudt de zuiverheid van de MVVM-architectuur en elimineert codeduplicatie.

Gebruiksscenario's van onRestart: gegevens en UI bijwerken

onRestart — de ideale plek voor bewerkingen die bij elke terugkeer naar het scherm moeten worden uitgevoerd, maar niet nodig zijn bij de eerste opening. Hier zijn typische scenario's:

• Lijst bijwerken uit DB of API — gebruiker ging naar een andere Activity, wijzigde daar gegevens, keerde terug — de lijst moet actueel zijn. Roep viewModel.refreshItems() aan in onRestart.
• Autorisatie controleren — als Activity langdurig verborgen was, kan het toegangstoken zijn verlopen. onRestart is het punt om de geldigheid van het token te controleren en door te sturen naar het inlogscherm.
• UI-status synchroniseren — thema's wisselen, taal wijzigen, instellingen bijwerken — wijzigingen moeten worden toegepast bij terugkeer naar het scherm.
• Media herladen — als Activity inhoud toont die kan zijn gewijzigd (nieuwsfeed, wisselkoers, weer), werk gegevens bij in onRestart.
• Netwerkverbinding controleren — bij terugkeer uit offline-modus moet Activity de netwerkbeschikbaarheid controleren en de UI omschakelen.
• Animaties herstellen — animaties die in onStop zijn vrijgegeven, herstart in onRestart vóór onStart.

Wat niet te doen in onRestart: initialiseer View niet opnieuw — ze leven omdat Activity niet is vernietigd. Abonneer niet opnieuw op LiveData — de abonnement in onCreate leeft. Maak geen nieuwe fragmenten — ze zijn al in FragmentManager.

onRestart en process death: belangrijke uitzondering

De belangrijkste uitzondering: onRestart wordt niet aangeroepen als het proces van de app door het systeem is gedood. Dit is het cruciale punt dat ontwikkelaars vaak missen door te vertrouwen op onRestart voor statusherstel.

Bij process death:

• App was op de achtergrond, Android doodde het proces om geheugen vrij te maken.
• Gebruiker keert terug — systeem start een nieuw proces.
• Activity wordt opnieuw aangemaakt: onCreate(Bundle) → onStart → onResume.
• onRestart wordt NIET aangeroepen — voor het systeem is dit een nieuwe Activity-instantie.

Hoe u zich hiertegen beschermt: bewaar altijd kritieke status in onSaveInstanceState(Bundle) (aangeroepen vóór onStop) of gebruik SavedStateHandle in ViewModel. Controleer in onCreate of savedInstanceState: als deze niet null is, herstel status uit Bundle, als deze null is — laad verse gegevens.

Volgens Google Android Vitals vindt ongeveer 7% van de terugkeer naar Activity na langdurige achtergrond plaats na process death. Dit betekent dat elke 15e Activity die onRestart had moeten aanroepen, in werkelijkheid door onCreate gaat. Het negeren van dit scenario is een van de belangrijkste oorzaken van bugs met „leeg scherm na terugkeer“.

Codevoorbeelden met onRestart in Kotlin

Voorbeeld 1: onRestart met lijstupdate via ViewModel

Activity roept viewModel.refreshTasks() aan in onRestart om de takenlijst bij te werken na terugkeer van het bewerkingsscherm.

class TaskListActivity : AppCompatActivity() {
    private val viewModel: TaskViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_task_list)
        viewModel.tasks.observe(this) { tasks ->
            Log.d("TaskList", "${tasks.size} taken ontvangen")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: takenlijst bijwerken")
        viewModel.refreshTasks()
    }
}

class TaskViewModel : ViewModel() {
    private val _tasks = MutableLiveData<List<Task>>()
    val tasks: LiveData<List<Task>> get() = _tasks

    fun refreshTasks() {
        viewModelScope.launch {
            _tasks.value = TaskRepository().getAllTasks()
        }
    }
}

ViewModel.refreshTasks() laadt actuele gegevens uit de repository. LiveData stelt Activity automatisch op de hoogte van gegevenswijzigingen — de UI wordt bijgewerkt zonder extra code. OnRestart maakt geen nieuw abonnement — deze is al ingesteld in onCreate.

Voorbeeld 2: onRestart met autorisatiecontrole

Activity controleert de geldigheid van het token bij terugkeer en stuurt door naar inloggen indien nodig.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Teruggekeerd van inlogscherm") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Token verlopen — doorsturen naar inloggen")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

class AuthManager {
    fun isTokenValid(): Boolean {
        val expiry = SharedPreferencesManager().getTokenExpiry()
        return System.currentTimeMillis() < expiry
    }
}

Als de gebruiker de app langdurig heeft geminimaliseerd en terugkeert na het verlopen van het token, stuurt onRestart hem door naar het inlogscherm. Dit voorkomt API-fouten bij het uitvoeren van een verzoek met een verlopen token. Let op: controle in onRestart, niet in onResume, om onnodige controle bij terugkeer uit een dialoog te voorkomen.

Voorbeeld 3: onRestart in Fragment met ViewLifecycleOwner

Fragment gebruikt onRestart via LifecycleObserver voor gegevensupdate.

class FeedFragment : Fragment() {
    private val viewModel: FeedViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        viewLifecycleOwner.lifecycle.addObserver(object : LifecycleObserver {
            @OnLifecycleEvent(Lifecycle.Event.ON_RESTART)
            fun onRestart() {
                Log.d("FeedFragment", "onRestart via LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

In plaats van onRestart in Fragment te overschrijven, wordt LifecycleObserver gebruikt — een flexibelere benadering waarmee logica kan worden toegevoegd aan levenscyclusgebeurtenissen zonder overerving. ViewLifecycleOwner garandeert dat de observer leeft binnen de View-scope (overleeft onDestroyView niet).