Theory
Event List, तीसरी और आख़िरी बार
इस subject ने fest की event list से OPEN किया: Android का ListView, एक adapter, getView, recycled thalis। बाईस lessons बाद वही 40 events को Flutter में listed होना है।
यह deliberate है: एक problem को 2 frameworks से solve होते देखना वही जगह है जहाँ real understanding रहती है। Flutter के answer के 2 forms हैं: मुट्ठी भर के लिए एक eager: और एक lazy जिसका heart, जब आप इससे मिलेंगे, आपको recognition में smile कराएगा।
Theory
Form 1: Eager ListView
ListView(children: [widgetA, widgetB, widgetC])
इसे children दीजिए; यह उन्हें scroll करता है। हर child तुरंत built होता है, चाहे visible हो या नहीं: 8 rows वाले एक SETTINGS page के लिए perfectly fine, किसी भी growing चीज़ के लिए wasteful।
क्योंकि एक ListView खुद को scroll करता है, Unit 1 का law intact cross करता है: इसे कभी एक दूसरे same-axis scroller में wrap मत कीजिए: gesture wars कोई framework नहीं जानते।
Practical
Form 2: Lazy Builder (itemBuilder दो बार पढ़िए)
final events = List.generate(40, (i) => 'Event ${i + 1}');
ListView.builder(
itemCount: events.length, // how many rows exist
itemBuilder: (context, index) { // called ONLY for visible rows
return ListTile(
leading: const Icon(Icons.event), // the left slot
title: Text(events[index]), // main line
subtitle: const Text('Main Ground'), // secondary line
trailing: const Icon(Icons.chevron_right),
onTap: () {
// open this event's booking screen
debugPrint('Tapped ${events[index]}');
},
);
},
)
Theory
itemBuilder getView है, फिर से जन्मा हुआ
2 frameworks को line up कीजिए:
- Android के adapter ने getView(position, ...) answer किया: इस position के लिए row build/refill कीजिए
- Flutter का itemBuilder(context, index): इस index के लिए row build कीजिए
Same contract: एक function जो demand पर ONE row manufacture करता है। और recycling? Flutter का builder design से lazy है: rows सिर्फ़ view में scroll होते हुए built होते हैं और leave करते हुए disposed होते हैं: convertView dance जो आपने Unit 1 में hand-coded किया, अब framework द्वारा perform होता है, आपके भूलने के लिए कोई null-check नहीं। 40 events हों या 40000: किसी भी moment सिर्फ़ visible दर्जन exist करते हैं।
Theory
ListTile: वह Row जिसे आप Hand-Build करना बंद करते हैं
Unit 1 की custom row को एक layout XML और findViewById choreography चाहिए थी। Flutter standard row को एक widget की तरह ship करता है, ListTile, named slots के साथ:
- leading: left slot: icon या avatar
- title / subtitle: main और secondary lines
- trailing: right slot: एक chevron, एक price
- onTap: built-in row tap
ListTile से richer rows चाहिए? itemBuilder से कोई भी widget tree return कीजिए: आपकी अपनी Column hold करने वाला एक Card: composition, हमेशा की तरह। और rows के बीच dividers: ListView.separated, जो एक separatorBuilder भी add करता है।
Quiz
5000-row list के लिए, ListView.builder ListView(children: [...]) से dramatically बेहतर क्यों है?
- builder rows automatically disk पर cached होती हैं
- itemBuilder lazily call होता है, सिर्फ़ उन rows के लिए जो scroll करके view में आती हैं: पहले से 5000 built होने की जगह एक दर्जन live rows
- builder lists animations skip करके fast scroll करती हैं
- कोई real difference नहीं है: दोनों सारी rows build करते हैं
Show the answer
itemBuilder lazily call होता है, सिर्फ़ उन rows के लिए जो scroll करके view में आती हैं: पहले से 5000 built होने की जगह एक दर्जन live rows
Children form पहले frame से पहले सारे 5000 widgets construct करता है: memory और jank: जबकि builder demand पर rows manufacture करता है और off-screen dispose करता है: सिर्फ़ visible मुट्ठी भर exist करता है। यह Unit 1 का recycling insight है (कम thalis, endless queue) automatic बनाया गया: Android ने आपसे convertView honour करने को कहा; Flutter का builder simply वह कभी नहीं बनाता जो चाहिए नहीं। Options A और C mechanisms invent करते हैं: कोई disk cache नहीं, कोई animation skipping नहीं: सिर्फ़ laziness win है। रखने वाली exam phrasing: builder = visible items का lazy, on-demand construction।
Think first
अपनी Unit 1 Vocabulary Translate कीजिए
Android के ListView से Flutter के dictionary को entry by entry complete कीजिए: adapter, getView(position), convertView recycling, setOnItemClickListener, notifyDataSetChanged। फिर tap कीजिए।
Show the answer
Adapter: खुद builder constructor (data + row factory एक जगह)। getView(position): itemBuilder(context, index)। convertView recycling: automatic laziness: कोई null-check नहीं, framework build/dispose करता है। setOnItemClickListener(position): row पर onTap जो आप build करते हैं: index पहले से scope में है, कोई listener juggling नहीं। notifyDataSetChanged: data change के around setState: हर update का एक Flutter answer। Five entries, एक lesson: frameworks spelling बदलते हैं; LIST वही problem रहता है।
Watch out
List Slips
Big Data के लिए children Form: compile होता है, चलता है, jank करता है: list data-driven होते ही builder के लिए reach कीजिए।
itemCount भूल जाना: एक infinite builder happily 40-item list के index 40 के लिए पूछता है: RangeError: itemCount fence है।
बिना Bounds के Column के अंदर एक ListView: unbounded-height errors: इसे एक Expanded wrapper दीजिए (stripes lesson का cousin)।
बिना setState List Mutate करना: rows appear या vanish नहीं होंगी: controlled law data को भी govern करता है।
Theory
Circle बंद होता है
इस subject का पहला lesson: एक Android list, एक adapter, recycled rows। तीसरा-आख़िरी lesson: वही list, और adapter idea इतना absorbed कि Flutter का version एक old friend की तरह पढ़ता है। वह arc IS subject है: platforms से ज़्यादा patterns। दो lessons बाकी हैं: dialogs और tooltips (polite interruptions), फिर toast, switch, charts और Form जो FestConnect Flutter को हमेशा के लिए finish करता है।
Summary
Key takeaways
- ListView(children:) हर row पहले से build करता है: सिर्फ़ छोटी fixed lists के लिए।
- ListView.builder(itemCount, itemBuilder): lazy: rows सिर्फ़ view में scroll होते हुए built होती हैं, बाद में disposed।
- itemBuilder(context, index) Unit 1 का getView(position) है, recycling automatic बनाई गई।
- ListTile: leading / title / subtitle / trailing / onTap: ready-made Material row; richer rows कोई भी widget tree।
- ListView.separated separatorBuilder से dividers add करता है।
- Lists खुद को scroll करते हैं (same-axis scrollers में nesting नहीं); data changes setState से गुज़रते हैं।
- Memory hook: builder सिर्फ़ वही बनाता है जो आँख देख सकती है।