Statusherstel in mobiele applicaties: wat is het, mechanisme en werkingsprincipe

Wat is State Restoration?

State Restoration (statusherstel) is een systeemmechanisme waarmee de huidige status van de gebruikersinterface van een applicatie kan worden bewaard en hersteld na het afsluiten of opnieuw opstarten. Wanneer de gebruiker de applicatie minimaliseert of het systeem deze sluit om bronnen vrij te maken, registreert State Restoration de belangrijkste UI-parameters en slaat deze op in een versleutelde opslag.

Zonder State Restoration verliest de gebruiker alle niet-opgeslagen gegevens bij het schakelen tussen applicaties. Bijvoorbeeld een ingevuld contactformulier, een lange zoekopdracht of een gedeeltelijk bekeken nieuwslijst — alles verdwijnt bij herstart. State Restoration lost dit probleem op door automatisch de status van de ViewController of Activity vast te leggen op het moment van minimaliseren.

Het mechanisme werkt op systeemniveau en wordt ondersteund door beide belangrijke mobiele platforms. iOS biedt State Restoration via NSUserActivity en het UIStateRestoring-protocol, en Android via SavedStateHandle in de Jetpack-architectuurcomponenten en ViewModel. De implementatie verschilt, maar het concept is identiek.

Hoe werkt het mechanisme van State Restoration?

Het State Restoration-proces is verdeeld in twee fasen: opslaan (save) en herstellen (restore). In de opslagfase roept het systeem de bijbehorende methoden van de levenscyclus aan waarin de applicatie de huidige UI-status moet serialiseren naar een compacte weergave. In de herstelfase geeft het systeem de opgeslagen gegevens terug en deserialiseert de applicatie deze om de UI te herstellen.

Mechanisme voor statusopslag

Opslaan wordt gestart door het systeem wanneer de applicatie naar de achtergrond gaat of bij ontvangst van een signaal van naderend afsluiten. In iOS wordt de methode encodeRestorableState aangeroepen in UIViewController, in Android onSaveInstanceState in Activity of opslaan via SavedStateHandle. Gegevens worden geserialiseerd naar een formaat dat primitieve typen ondersteunt: tekenreeksen, getallen, byte-arrays en Parcelable-objecten.

De hoeveelheid opgeslagen gegevens moet minimaal zijn — het systeem legt beperkingen op aan de grootte van het opgeslagen pakket. In Android bedraagt de limiet ongeveer 50 KB per proces. Overschrijding van de limiet leidt tot de uitzondering TransactionTooLargeException. Daarom raden architecten aan om alleen identificaties en sleutels op te slaan en de volledige gegevens bij herstel uit de permanente opslag te laden.

UI herstellen uit opgeslagen status

Bij herstel geeft het systeem het opgeslagen gegevenspakket door aan de applicatie op het moment van opstarten. In iOS wordt de methode decodeRestorableState aangeroepen, in Android onRestoreInstanceState of lezen uit SavedStateHandle. De applicatie extraheert identificaties en sleutels uit het pakket en herstelt de UI: scrollpositie, geselecteerde elementen, ingevoerde gegevens.

Het is belangrijk om te bedenken dat herstel in een nieuw proces kan plaatsvinden. Als de applicatie volledig uit het geheugen is verwijderd, wordt het proces opnieuw aangemaakt en zijn alle objecten in het geheugen afwezig. Daarom moet de status serialiseerbaar en onafhankelijk zijn van de runtime-context van de vorige sessie. Dit is vooral kritisch voor grote formulieren met meerdere invoervelden en lange, meerpagina-interfaces.

class MainActivity : AppCompatActivity() {
    private var searchQuery: String = ""

    override fun onSaveInstanceState(outState: Bundle) {
        super.onSaveInstanceState(outState)
        outState.putString("search_query", searchQuery)
    }

    override fun onRestoreInstanceState(savedState: Bundle) {
        super.onRestoreInstanceState(savedState)
        searchQuery = savedState.getString("search_query", "")!!
        restoreSearchUI(searchQuery)
    }
}

State Restoration op iOS en Android

De implementatie van State Restoration verschilt aanzienlijk tussen platforms. iOS gebruikt een declaratieve benadering via storyboard en UIKit-protocollen, terwijl Android een imperatieve benadering gebruikt via de levenscyclusmethoden van Activity en de Jetpack-architectuurcomponenten. De keuze van de benadering hangt af van het doelplatform en de architectuur van de applicatie.

State Restoration in iOS (UIKit)

In iOS is State Restoration gebaseerd op drie componenten: UIApplication beheert het algehele proces, UIViewController implementeert het UIStateRestoring-protocol en NSUserActivity slaat gegevens op voor het herstellen van navigatie. Om te activeren moet u restorationIdentifier instellen in UIViewController en encodeRestorableState en decodeRestorableState implementeren.

iOS slaat automatisch de status van de navigatiecontroller (UINavigationController) en alle geneste ViewControllers op, als ze een restorationIdentifier hebben ingesteld. Het systeem beheert de navigatiestack en herstelt deze in de oorspronkelijke staat. De gegevens binnen de controllers (ingevoerde tekst, scrollpositie) moeten echter expliciet door de ontwikkelaar worden opgeslagen.

State Restoration in Android (SavedStateHandle)

In Android is de moderne benadering van State Restoration gebaseerd op SavedStateHandle — een component uit de AndroidX Lifecycle-bibliotheek. SavedStateHandle is beschikbaar binnen ViewModel en slaat automatisch gegevens op en herstelt deze bij configuratiewijziging (schermrotatie) en bij herstart van het proces. Gegevens worden opgeslagen in Bundle en automatisch geserialiseerd.

SavedStateHandle gedraagt zich als een sleutel-waarde opslag met ondersteuning voor LiveData. Bij configuratiewijziging worden gegevens automatisch opgeslagen en hersteld. Voor ondersteuning van het herstarten van het proces moet ViewModel worden aangemaakt via SavedStateViewModelFactory — dit stelt ViewModel in staat om het volledig afsluiten van de applicatie te overleven.

class SearchViewModel(
    private val savedStateHandle: SavedStateHandle
) : ViewModel() {

    companion object {
        private val KEY_QUERY = string("search_query")
    }

    fun getSearchQuery(): String? = savedStateHandle[KEY_QUERY]

    fun saveSearchQuery(query: String) {
        savedStateHandle[KEY_QUERY] = query
    }
}

State Restoration implementeren in code

De praktische implementatie van State Restoration vereist het in overweging nemen van verschillende aspecten: het kiezen van de juiste opslag, het bepalen van de hoeveelheid op te slaan gegevens en het testen van verschillende afsluitscenario's. Laten we stap voor stap de implementatie bekijken voor een Flutter-applicatie met behulp van het pakket state_restoration.

class RestorableSearchField extends RestorableProperty<String> {
  String _value = '';

  @override
  String get value => _value;

  @override
  void set value(String newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  @override
  String? toPrimitives() => _value;

  @override
  void fromPrimitives(String? data) {
    _value = data ?? '';
  }
}

Bij de implementatie is het belangrijk om de opslaggrenzen in gedachten te houden. Niet elk UI-veld hoeft te worden hersteld. Scrollpositie in een lange lijst — ja. Tijdelijke animatiestatus — nee. De ontwikkelaar moet bewust kiezen welke gegevens kritisch zijn voor de gebruikerservaring en welke veilig kunnen worden gereset zonder verlies van gebruiksgemak.

Het testen van State Restoration is een aparte taak die simulatie van procesbeëindiging vereist. Op Android kan dit worden gedaan via het commando adb shell am kill, op iOS via simulatie van beëindiging in Xcode. UI-testframeworks zoals Espresso en XCTest bieden speciale methoden voor het controleren van statusherstel.

Beste praktijken voor State Restoration

Eerste regel — sla identificaties op, niet de gegevens zelf. In plaats van een volledig object met honderden velden op te slaan, slaat u de unieke identificatie ervan op en laadt u bij herstel de actuele gegevens uit de database of API. Dit bespaart ruimte in Bundle en garandeert de actualiteit van gegevens op het moment van herstel.

Tweede regel — test alle scenario's. Controleer het herstel na schermrotatie, na minimaliseren en terugkeren na een uur, na het sluiten van de applicatie door het systeem wegens geheugengebrek. Elk scenario kan zich anders gedragen afhankelijk van de status van het besturingssysteem en de beschikbare bronnen.

Derde regel — gebruik systeemmechanismen, niet uw eigen. iOS en Android bieden ingebouwde API's voor State Restoration die zijn geoptimaliseerd voor het specifieke platform. Een eigen implementatie via SharedPreferences of UserDefaults kan leiden tot synchronisatieproblemen en onverwacht gedrag bij herstel.

Vierde regel — ga om met afwezigheid van status. Bij de eerste start of na het wissen van gegevens kan de status ontbreken. De UI moet correct werken in de oorspronkelijke staat zonder uitzonderingen te genereren. Controleer alle opgeslagen gegevens op null voor gebruik en voorzie standaardwaarden.

Vijfde regel — documenteer de opgeslagen sleutels. Wanneer er tientallen schermen in het project zijn en elk scherm meerdere velden opslaat, ontstaat er chaos zonder gecentraliseerd sleutelbeheer. Maak één klasse of bestand met sleutelconstanten voor State Restoration in elke module. Dit vereenvoudigt het onderhoud en voorkomt het per ongeluk overschrijven van gegevens bij refactoring.