मुख्य सामग्री पर जाएँ
CrossFly 100% ओपन सोर्सGitHub पर फ़ॉलो करें
CrossFlyCrossFly
शुरू करें

यह पृष्ठ पुर्तगाली से मशीन-अनुवादित है और इसमें त्रुटियाँ हो सकती हैं। पुर्तगाली संस्करण प्रामाणिक है।

सब कुछ एक Component है

यही वह विचार है जो बाकी फ्रेमवर्क को समझ में आने लायक बनाता है। CrossFly में “widgets” बनाम “containers” जैसी कोई पदानुक्रमिकता नहीं है। एक ही आधार प्रकार है — Component — और कोई भी Component उसी क्षण container बन जाता है जब उसे एक Layout मिलता है।

container = Component + Layout

Component painel = new Component();       // एक "खाली" Component
painel.setLayout(new VerticalLayout());   // अब यह children को व्यवस्थित करता है → यह एक container है
painel.add(LAY_AUTO, new Label("Título"));
painel.add(LAY_FILL, new ListView<>(...));

एक Button एक Component है। एक Label एक Component है। एक Window (स्क्रीन) एक पूर्ण-स्क्रीन Component है। कोई विशेष Container क्लास मौजूद नहीं है — “समाहित करने की क्षमता” बस एक Layout होने भर से है। इसका मतलब है कि आप स्क्रीनों को हमेशा एक ही तरीके से जोड़ते हैं, बटन से लेकर पूरे app तक।

आधार क्लास को इस तरह क्यों डिज़ाइन किया गया है

Component को मेमोरी फुलाए बिना हज़ारों इंस्टैंस तक स्केल करना पड़ता है। दो प्रमुख निर्णय:

  • दर्जनों boolean के बजाय Bitfield (cbits)। enabled, visible, focused, pressed, layout है, focused स्टाइल है… जैसी अवस्थाएँ एक अकेले long पूर्णांक के बिट्स हैं, अलग-अलग फ़ील्ड नहीं। हज़ारों कंपोनेंट × दर्जनों boolean फ़्लैग बर्बादी होती; एक bitfield इसे एक ही फ़ील्ड से हल कर देता है।
  • Lazy प्रॉपर्टी मैप (property(k, v))। वैकल्पिक चीज़ें (callbacks, कस्टम skin, पृष्ठभूमि की छवि, वैकल्पिक स्टाइल) निश्चित फ़ील्ड नहीं हैं — वे एक मैप में रहती हैं जो माँग पर बनाया जाता है। एक साधारण Label किसी “पृष्ठभूमि छवि” फ़ील्ड की कीमत नहीं चुकाता जिसका वह कभी उपयोग नहीं करेगा।
// property(...) वैकल्पिक चीज़ों के लिए मुहावरेदार "डेटा थैला" है:
comp.property("meuFlag", true);
boolean f = comp.property("meuFlag");   // पुनः प्राप्त करता है (यदि कभी सेट नहीं हुआ तो null)

स्टाइल भी उसी दर्शन का पालन करते हैं: वे Skin से माँग पर बनाए जाते हैं, हर कंपोनेंट के लिए शुरुआत में ही इंस्टैंशिएट नहीं किए जाते।

एकल-अभिभावक पदानुक्रम

हर Component का अधिक-से-अधिक एक ही अभिभावक होता है। रचना का वृक्ष सख्ती से पदानुक्रमिक है: किसी कंपोनेंट को किसी container में जोड़ना उसे उसके किसी भी पिछले अभिभावक से हटा देता है। यह layout और events के प्रसार को पूर्वानुमेय बनाए रखता है (हर कंपोनेंट ठीक एक ही जगह का होता है)।

इससे क्या निकलता है

  • सब कुछ जोड़ने का एक ही तरीका: एक पैनल बनाना सीखना = एक स्क्रीन बनाना जानना।
  • Layouts प्लग करने योग्य हैं: वही container केवल Layout बदलने से व्यवस्था बदल लेता है (उत्तरदायित्व का आधार — देखें Layout और Relative मॉडल)।
  • प्रति कंपोनेंट कम लागत: bitfield + lazy प्रॉपर्टीज़ ही वह है जो बड़ी सूचियों को व्यवहार्य बनाता है।

यह भी देखें

क्या यह पृष्ठ उपयोगी था?