Question 1

StatefulWidget-in lifecycle metodlarını sırası ilə izah et.

Accepted Answer

Sıra: createState → initState (bir dəfə: controller, subscription, ilk yükləmə) → didChangeDependencies (InheritedWidget asılılıqları burada oxunur) → build → valideyn yeniləyəndə didUpdateWidget → build → sonda dispose. Hər metodu tərif kimi yox, nə üçün lazım olduğu ilə izah et. İki tələni mütləq qeyd et: initState-də context-dən InheritedWidget oxumaq olmaz və initState özü async ola bilməz. Sonda mounted yoxlamasını əlavə et — async iş dispose-dan sonra qayıda bilər.

Question 2

setState çağırdıqda arxa planda nə baş verir?

Accepted Answer

İki addım: callback sinxron işləyir (yəni vəziyyət dərhal dəyişir), sonra element "dirty" siyahısına düşür. Flutter növbəti frame-də dirty elementləri toplayıb onların build-ini çağırır və nəticəni köhnə widget ağacı ilə müqayisə edir. Bu modeldən iki praktik nəticə çıxarıram: (1) setState içində await etmək mənasızdır, çünki callback sinxrondur — datanı əvvəl al, sonra setState çağır; (2) bir neçə setState-i ardıcıl çağırmaq bahalı deyil, çünki hamısı eyni frame-də bir rebuild-ə yığılır.

Question 3

"setState called after dispose" xətasının səbəbi nədir və necə qarşısını alırsan?

Accepted Answer

Səbəb: async əməliyyat (şəbəkə sorğusu, timer, stream) widget ağacdan çıxandan sonra nəticə qaytarır və setState çağırır — amma həmin State artıq dispose olunub. Qarşısını almağın üç qatı: (1) hər await-dan sonra if (!mounted) return;; (2) dispose()-da subscription və timer-ləri ləğv etmək — bu, kök səbəbi aradan qaldırır; (3) ləğv oluna bilən sorğular üçün cancel token. mounted yoxlaması ən sadə qorunmadır, amma tək başına kifayət deyil: subscription ləğv olunmasa, o, işləməyə davam edir və resurs sərf edir.

Question 4

setState nə vaxt kifayət etmir və başqa həll lazım olur?

Accepted Answer

Üç əlamət var. (1) Eyni vəziyyət bir neçə ekranda lazımdır — məsələn səbət, autentifikasiya. setState ilə bunu ötürmək "props drilling"-ə çevrilir. (2) Vəziyyət widget-dən uzun yaşamalıdır — ekran bağlananda itməməlidir. (3) Biznes məntiqi UI ilə qarışır — test etmək çətinləşir. Bu hallarda Provider/Riverpod/BLoC kimi həll lazımdır. Amma tərsini də deyərdim: bir ekranın daxili vəziyyəti üçün (forma, açılıb-bağlanan panel, sayğac) setState düzgün seçimdir — hər şeyi state management paketinə köçürmək lazımsız mürəkkəblikdir.

Metod	Nə vaxt çağırılır	Nə üçün istifadə olunur
`initState`	State yaradılanda bir dəfə	Controller yaratmaq, subscription açmaq, ilk data yükləmək
`didChangeDependencies`	`initState`-dən sonra və asılı olduğu InheritedWidget dəyişəndə	`Theme.of`/`MediaQuery.of`-dan asılı işlər
`didUpdateWidget`	Valideyn eyni tipdə yeni widget verəndə	Köhnə və yeni `widget` parametrlərini müqayisə edib reaksiya vermək
`dispose`	State ağacdan həmişəlik çıxarılanda	Controller bağlamaq, subscription ləğv etmək

setState və StatefulWidget lifecycle

📚 Mənbələr və sənədlər