अवस्था और डेटा प्रवाह

यहीं CrossFly Flutter, Compose, SwiftUI या React से आने वालों को सबसे ज़्यादा चौंकाता है। दो जानबूझकर की गई अनुपस्थितियाँ:

• कोई स्वचालित रिएक्टिव binding नहीं है। न setState, न observables, न @State, न recomposition। मॉडल बदलना UI को स्वयं अपडेट नहीं करता।
• कोई dependency injection कंटेनर नहीं है। न Dagger/Guice/Spring। आप अपनी निर्भरताएँ हाथ से बनाते और पास करते हैं (आमतौर पर स्क्रीन के कंस्ट्रक्टर के ज़रिए)।

मॉडल: अनिवार्य + स्पष्ट अमान्यीकरण

आप मॉडल को पढ़ते/लिखते हैं, कंपोनेंट को सीधे अपडेट करते हैं और फ्रेमवर्क पुनः पेंट करता है:

model.nome = "Ana";
label.setText(model.nome);   // अधिकांश setters पहले से ही layout अमान्य कर repaint() को कॉल करते हैं

अधिकांश कंपोनेंट setters पहले से ही आपके लिए repaint() चालू करते हैं / layout को अमान्य करते हैं। याद रखने योग्य एकमात्र नियम:

ऐसी अवस्था बदली जिसे फ्रेमवर्क नहीं जानता (आपका कोई काउंटर, कोई गणना, onPaint में बनाया गया कोई फ़ील्ड)? आप repaint() को बुलाते हैं। (देखें paint thread।)

क्लासिक प्रति-उदाहरण

this.progresso = 0.7f;   // मैंने एक फ़ील्ड बदला जिसे केवल मेरा onPaint पढ़ता है…
// …और स्क्रीन नहीं बदलती। कमी है:
Component.repaint();      // ✔ अब अगला frame नए मान को दर्शाता है

“मैंने अवस्था बदली और स्क्रीन अपडेट नहीं हुई” लगभग हमेशा एक छूटा हुआ repaint() होता है।

यह चुनाव क्यों

• पूर्वानुमेयता: प्रवाह रैखिक और दृश्यमान है — डेटा → setter → repaint → frame। डिबग करने के लिए न कोई जादुई recomposition है, न कोई छिपा रिएक्टिव चक्र।
• शून्य जादू, कम लागत: न कोई रिएक्टिव निर्भरता ग्राफ़, न कॉन्फ़िगर करने के लिए कोई DI फ्रेमवर्क।
• इसकी कीमत स्पष्टता है: अवस्था प्रबंधित करना एप्लिकेशन की ज़िम्मेदारी है, फ्रेमवर्क की नहीं।

संचार के तंत्र जो फ्रेमवर्क प्रदान करता है

• Callbacks / actions — onAction(...), कंस्ट्रक्टर से पास किए गए callbacks (देखें मान लौटाना)।
• अभिभावक/बच्चा पदानुक्रम — कंपोनेंट के वृक्ष में नेविगेट करना।
• property(k, v) — प्रति कंपोनेंट “डेटा की थैली” (देखें सब कुछ एक Component है)।
• वैश्विक अवस्था — जब समझ में आए, तब साझा static फ़ील्ड/सेवाएँ।

अनुशंसित पैटर्न

चूँकि फ्रेमवर्क केवल ब्लॉक देता है, संगठन का पैटर्न (प्रति स्क्रीन एक ViewModel/controller + डेटा के लिए repository) एप्लिकेशन की परंपरा है — जो best-practices में प्रलेखित है। फ्रेमवर्क आर्किटेक्चर थोपता नहीं; वह कंपोनेंट और setter→repaint() जोड़ी प्रदान करता है।

यह भी देखें

• संबंधित: paint thread · app आर्किटेक्चर (best-practices)