Theory
एक Screen जो पूरी तरह एक Noun से बनी है
पिछले lesson की minimal app 4 widgets deep थी: MaterialApp, Scaffold, Center, Text। Flutter से पूछिए screen पर कुछ भी क्या है: एक button, इसके around का gap, screen खुद: और answer हमेशा same noun होता है: एक widget।
एक noun classification के बिना chaos होता। Syllabus widget world को 3 clean axes में काटता है, और उनके बीच वे इकलौते 3 सवालों का answer देते हैं जो matter करते हैं जब आप एक widget के लिए reach करते हैं: क्या यह SHOW करता है? क्या यह CHANGE हो सकता है? कितने CHILDREN?
Theory
Axis 1: Visible बनाम Invisible
Visible widgets screen पर pixels रखते हैं या input लेते हैं: Text, Image, Icon, ElevatedButton, TextField: वे जिन पर एक user point करेगा।
Invisible widgets खुद कुछ draw नहीं करते: वे दूसरों को ARRANGE करते हैं: Row और Column children को line up करते हैं, Center एक को position करता है, Padding एक के चारों तरफ़ space push करता है, Stack एक pile overlap करता है, Scaffold पूरी screen frame करता है (app bar slot, body slot, floating button slot)।
एक screen invisible scaffolding है जो visible leaves hold करती है: exactly वही XML-layouts-holding-widgets structure जो Unit 1 का था, Dart objects की तरह rewritten।
Theory
Axis 2: Stateless बनाम Stateful (Exam Axis)
StatelessWidget: immutable। इसकी build() method purely उस configuration से render करती है जो इसे दी गई: same inputs, same pixels, हमेशा के लिए। Fest का name label, एक poster, एक rules page।
StatefulWidget: 2 pieces में आता है: widget plus एक State object जो rebuilds survive करता है। Mutable data (seats left, एक checkbox की tick) State में रहता है, और इसे बदलना एक gate से गुज़रता है:
setState(() { seats--; });
setState mutate करता है AND Flutter को बताता है build() फिर से run करे, नई values के साथ repainting। setState wrapper भूल जाना Flutter का सबसे classic bug है: data बदलता है, screen नहीं।
At a glance
एक Glance में 3 Classifications
| Axis | Kind A | Kind B |
|---|---|---|
| Pixels | Visible: Text, Image, Button, Icon, TextField | Invisible: Row, Column, Center, Padding, Stack, Scaffold |
| Change | Stateless: immutable, config से build होता है | Stateful: State object + setState() rebuilds |
| Children | Single-child: child: (Center, Padding, Container) | Multi-child: children: [ ] (Row, Column, Stack, ListView) |
Practical
हर Change-Kind का एक-एक, Side by Side
// STATELESS: fixed configuration in, same pixels out, forever
class FestTitle extends StatelessWidget {
const FestTitle({super.key});
@override
Widget build(BuildContext context) {
return const Text('TechnoUtsav 2026');
}
}
// STATEFUL: the seat counter that must change on screen
class SeatCounter extends StatefulWidget {
const SeatCounter({super.key});
@override
State<SeatCounter> createState() => _SeatCounterState();
}
class _SeatCounterState extends State<SeatCounter> {
int seats = 350; // mutable data lives in State
@override
Widget build(BuildContext context) {
return Column( // multi-child, invisible
children: [
Text('Seats left: $seats'), // visible leaf
ElevatedButton(
onPressed: () => setState(() { seats--; }), // the gate
child: const Text('Book one'),
),
],
);
}
}
Quiz
FestConnect Flutter को एक seats-left display चाहिए जो हर बार Book tap होने पर घटे। कौन सा widget kind, और क्यों?
- StatelessWidget: counter का layout कभी नहीं बदलता
- StatefulWidget: displayed value को समय के साथ बदलना है, तो इसे एक State object और setState चाहिए
- एक invisible widget: counters pixels draw नहीं करते
- दोनों काम करते हैं: stateless widgets भी build() के ज़रिए update हो सकते हैं
Show the answer
StatefulWidget: displayed value को समय के साथ बदलना है, तो इसे एक State object और setState चाहिए
Decide करने वाला सवाल हमेशा है: क्या इस widget का OUTPUT screen पर रहते हुए बदलना चाहिए? एक ticking counter हाँ कहता है, और changeable data को एक ऐसा home चाहिए जो rebuilds survive करे (State object) plus repainting trigger करने के लिए setState gate। Option A layout stability को data stability से confuse करता है: arrangement रहता है, NUMBER move करता है। Option C axis को पूरी तरह misfile करता है: एक counter text दिखाता है: visible। Option D एक grain of truth वाला trap है: एक stateless widget अपने parent द्वारा नए config के साथ rebuild हो सकता है, पर यह खुद को change नहीं कर सकता: self-updating screens definition से stateful हैं।
Think first
Booking Screen को Classify कीजिए
अगले lessons यह screen बनाते हैं: एक event poster, event title, एक name TextField, एक Book button, सब vertically arranged breathing space के साथ, एक Scaffold के ऊपर। Tap करने से पहले हर piece पर सभी 3 axes चलाइए।
Show the answer
Poster (Image) और title (Text): visible, stateless, childless leaves। TextField: visible, और इसे hold करने वाली screen STATEFUL है (typed text changing data है)। Button: visible; इसका onPressed setState call करेगा: इसके around की screen stateful है। Column: invisible, multi-child, इन सबको arrange करता है। Padding: invisible, single-child, breathing space। Scaffold: invisible skeleton जो screen frame करता है। यह जो habit बनाता है: code करने से PEHLE classify कीजिए, और widget tree खुद लिख जाता है: जो literally अगले lesson का agenda है।
Watch out
Classification Traps
बिना setState के Mutate करना: seats-- अकेले variable बदलता है और कुछ भी repaint नहीं करता: classic silent bug; हर visible change gate से गुज़रता है।
child बनाम children: Center(children: [...]) compile नहीं होता; Row(child: ...) भी नहीं। Single-child widgets child: लेते हैं, multi-child children: [ ] लेते हैं: error message पढ़ना इसे solve करता है, axis पढ़ना इसे prevent करता है।
"Invisible" "Unimportant" नहीं है: layout widgets हर real tree का ज़्यादातर हिस्सा हैं; invisible का मतलब है अपने pixels नहीं, कोई effect नहीं ऐसा नहीं।
Theory
हर Widget से पहले तीन सवाल
Interview internalise कीजिए: क्या यह show करता है? (visible या layout): क्या यह change होता है? (stateless या stateful): एक child या कई? हर widget के लिए जो आप कभी add करेंगे यह पूछिए, और Flutter का enormous catalogue एक filing system में collapse हो जाता है। Unit 4 अब catalogue के पहले shelf को walk करती है: visible four (Text, Image, Button, Icon), हर एक इसके constructor और named-parameter properties के through।
Summary
Key takeaways
- Screen पर सब कुछ एक widget है; UI इनका एक tree है, named parameters के ज़रिए configured।
- Axis 1: visible widgets pixels दिखाते हैं या input लेते हैं; invisible ones (Row, Column, Center, Padding, Stack, Scaffold) दूसरों को arrange करते हैं।
- Axis 2: StatelessWidget fixed config render करता है; StatefulWidget एक State object owns करता है, और setState(() {...}) mutate + rebuild करता है।
- बिना setState के data बदलना screen पर कुछ भी update नहीं करता: classic bug।
- Axis 3: single-child widgets child: लेते हैं; multi-child children: [ ] लेते हैं।
- Kind decide कीजिए पूछकर: show? change? कितने children?
- Memory hook: show, change, children: 3-question widget interview।