onRestart — esența, restaurarea Activity în ciclul de viață

onRestart — esența metodei în ciclul de viață Android

onRestart — metoda callback pe care Android o apelează strict înainte de onStart, când Activity revine din starea invizibilă Stopped înapoi în starea vizibilă. Această metodă este unică prin faptul că este apelată doar la afișarea repetată a Activity — la prima creare a instanței secvența începe cu onCreate, sărind peste onRestart. Ciclul complet: onCreate → onStart → onResume (prima lansare) sau onRestart → onStart → onResume (afișare repetată).

Din punctul de vedere al sistemului Android, onRestart este o optimizare care permite Activity să se pregătească pentru revenire: să actualizeze datele din repository, să sincronizeze starea UI, să verifice conexiunea la rețea. Spre deosebire de onResume, care este apelat de fiecare dată când primește focus (inclusiv la revenirea dintr-un dialog sau meniul de sistem), onRestart se activează doar la ciclul complet de ascundere-revenire. Acest lucru face din onRestart locul ideal pentru operații „grele” de actualizare, care nu sunt necesare la pierderea parțială a focusului.

Conform specificației ciclului de viață Android Activity, intervalul de timp între onStop și onRestart poate varia de la câteva secunde (utilizatorul a comutat rapid) până la câteva ore (aplicația a fost în fundal și utilizatorul s-a întors). În acest timp datele din sursa la distanță (API, DB) s-ar fi putut modifica, de aceea onRestart este punctul natural pentru verificarea actualității.

Când este apelat onRestart: condiții și ordine

onRestart este apelat doar la revenirea Activity din starea Stopped, în care Activity a intrat după apelul onStop. Mai jos sunt enumerate toate scenariile care duc la onRestart.

Scenarii de apelare onRestart:

• Revenirea dintr-un alt Activity — utilizatorul a deschis un nou Activity (de exemplu, a dat clic pe o notificare) și apoi s-a întors (a apăsat „Înapoi”). Stiva: MainActivity.onPause → MainActivity.onStop → SecondActivity este creat → utilizatorul apasă „Înapoi” → SecondActivity.onPause → SecondActivity.onStop → SecondActivity.onDestroy → MainActivity.onRestart → MainActivity.onStart → MainActivity.onResume.
• Revenirea din minimizare — utilizatorul a minimizat aplicația (Home) și după un timp s-a întors. CurrentActivity.onPause → CurrentActivity.onStop → (aplicația în fundal) → utilizatorul revine → CurrentActivity.onRestart → CurrentActivity.onStart → CurrentActivity.onResume.
• Revenirea de pe ecranul de blocare — ecranul de blocare acoperă Activity; după deblocare Activity primește onRestart dacă a trecut un timp semnificativ (mai mult de 5 secunde).
• Revenirea dintr-o aplicație lansată prin Intent — cameră, galerie, browser — orice aplicație terță lansată prin startActivityForResult() sau ActivityResultLauncher.

Când onRestart NU este apelat: la rotirea ecranului (Activity este distrus și creat din nou prin onCreate), la revenirea dintr-o fereastră de dialog (Activity nu intră în onStop, doar onPause → onResume), la process death (Activity este creat din nou).

Diferența dintre onRestart și onCreate: ce să alegi

onRestart și onCreate sunt două abordări diferite pentru restaurarea Activity. Alegerea între ele depinde de faptul dacă Activity a fost complet distrus sau doar ascuns.

Regula de alegere: inițializarea View și abonarea la LiveData/StateFlow faceți în onCreate (sau onViewCreated pentru Fragment). Actualizarea datelor, reîncărcarea listelor și verificarea stării — în onRestart. Dacă datele sunt încărcate prin ViewModel, onRestart poate apela pur și simplu metoda refresh() pe ViewModel, iar View se va abona la datele actualizate prin fluxul reactiv.

Google recomandă: nu duplicați logica onCreate în onRestart. Separați în ViewModel metodele refresh() care încarcă datele actuale și apelați-le în onRestart. Aceasta păstrează puritatea arhitecturii MVVM și elimină duplicarea codului.

Scenarii de utilizare onRestart: actualizare date și UI

onRestart — locul ideal pentru operațiile care trebuie executate la fiecare revenire pe ecran, dar nu sunt necesare la prima deschidere. Iată scenariile tipice:

• Actualizarea listei din DB sau API — utilizatorul a plecat în alt Activity, acolo a modificat datele, s-a întors — lista trebuie să fie actuală. Apelați viewModel.refreshItems() în onRestart.
• Verificarea autorizării — dacă Activity a fost ascunsă o perioadă îndelungată, tokenul de acces ar fi putut expira. onRestart este punctul de verificare a valabilității tokenului și de redirecționare către ecranul de login.
• Sincronizarea stării UI — comutarea temelor, schimbarea limbii, actualizarea setărilor — modificările trebuie aplicate la revenirea pe ecran.
• Reîncărcarea media — dacă Activity afișează conținut care s-ar fi putut modifica (flux de știri, curs valutar, vreme), actualizați datele în onRestart.
• Verificarea conexiunii la rețea — la revenirea din modul offline, Activity trebuie să verifice disponibilitatea rețelei și să comute UI.
• Restaurarea animațiilor — animațiile eliberate în onStop reporniți-le în onRestart înainte de onStart.

Ce să nu faceți în onRestart: nu inițializați View din nou — ele sunt vii deoarece Activity nu a fost distrus. Nu vă abonați din nou la LiveData — abonarea în onCreate este vie. Nu creați fragmente noi — ele sunt deja în FragmentManager.

onRestart și process death: excepția importantă

Cea mai importantă excepție: onRestart nu este apelat dacă procesul aplicației a fost ucis de sistem. Acesta este momentul cheie pe care dezvoltatorii îl pierd adesea, bazându-se pe onRestart pentru restaurarea stării.

La process death:

• Aplicația era în fundal, Android a ucis procesul pentru a elibera memoria.
• Utilizatorul revine — sistemul lansează un nou proces.
• Activity este creat din nou: onCreate(Bundle) → onStart → onResume.
• onRestart NU este apelat — pentru sistem aceasta este o nouă instanță a Activity.

Cum să vă protejați: salvați întotdeauna starea critică în onSaveInstanceState(Bundle) (apelat înainte de onStop) sau folosiți SavedStateHandle în ViewModel. În onCreate verificați savedInstanceState: dacă nu este null, restaurați starea din Bundle, dacă este null — încărcați date proaspete.

Conform Google Android Vitals, aproximativ 7% dintre revenirile la Activity după o ședere îndelungată în fundal au loc după process death. Aceasta înseamnă că fiecare al 15-lea Activity care ar fi trebuit să apeleze onRestart trece de fapt prin onCreate. Ignorarea acestui scenariu este una dintre principalele cauze ale bugurilor „ecran gol după revenire”.

Exemple de cod cu onRestart în Kotlin

Exemplul 1: onRestart cu actualizarea listei prin ViewModel

Activity apelează viewModel.refreshTasks() în onRestart pentru a actualiza lista de sarcini după revenirea de pe ecranul de editare.

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", "Au fost primite ${tasks.size} sarcini")
        }
    }

    override fun onRestart() {
        super.onRestart()
        Log.d("TaskList", "onRestart: actualizarea listei de sarcini")
        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() încarcă datele actuale din repository. LiveData notifică automat Activity despre modificarea datelor — UI se actualizează fără cod suplimentar. OnRestart nu creează o nouă abonare — aceasta este deja stabilită în onCreate.

Exemplul 2: onRestart cu verificarea autorizării

Activity verifică valabilitatea tokenului la revenire și redirecționează către login dacă este necesar.

class ProfileActivity : AppCompatActivity() {
    private val authManager = AuthManager()
    private val launcher = registerForActivityResult(
        ActivityResultContracts.StartActivityForResult()
    ) { Log.d("Profile", "Ne-am întors de pe ecranul de login") }

    override fun onRestart() {
        super.onRestart()
        if (!authManager.isTokenValid()) {
            Log.d("Profile", "Tokenul a expirat — redirecționare la login")
            launcher.launch(Intent(this, LoginActivity::class.java))
        }
    }
}

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

Dacă utilizatorul a minimizat aplicația pentru o perioadă îndelungată și s-a întors după expirarea tokenului, onRestart îl va redirecționa către ecranul de login. Aceasta previne erorile API la încercarea de a efectua o cerere cu un token expirat. Atenție: verificarea în onRestart, nu în onResume, pentru a evita verificarea inutilă la revenirea dintr-un dialog.

Exemplul 3: onRestart în Fragment cu ViewLifecycleOwner

Fragment folosește onRestart prin LifecycleObserver pentru actualizarea datelor.

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 prin LifecycleObserver")
                viewModel.refreshFeed()
            }
        })
    }
}

În loc să suprascrieți onRestart în Fragment, se folosește LifecycleObserver — o abordare mai flexibilă care permite adăugarea logicii la evenimentele ciclului de viață fără moștenire. ViewLifecycleOwner garantează că observerul trăiește în domeniul View (nu supraviețuiește lui onDestroyView).