Adobe AIR

Question

मैं एक आगामी परियोजना के लिए क्लाइंट साइड कार्यान्वयन प्रौद्योगिकी के रूप में एडोब आकाशवाणी को चुनने का सोच रहा हूँ के साथ एक प्लगइन वास्तुकला का निर्माण। (पिछली पसंद सी # और डब्ल्यूपीएफ थी, लेकिन मैं हाल ही में फ्लैश/फ्लेक्स/एआईआर से प्रभावित हूं।)

लेकिन मेरे उत्पाद की सबसे महत्वपूर्ण विशेषताओं में से एक इसकी प्लगइन आर्किटेक्चर होगी, जिससे तीसरे पक्ष के डेवलपर्स को दिलचस्प तरीकों से कार्यक्षमता और जीयूआई का विस्तार करें।

मुझे पता है कि मैं सी # में वास्तुकला डिजाइन चाहते हैं: प्लग-इन लोडर विधानसभाओं के सभी स्थानीय "एप्लिकेशन/plugins /" निर्देशिका में गणना होगी। प्रत्येक असेंबली के लिए, यह "IPluginFactory" इंटरफेस के कार्यान्वयन की तलाश में सभी वर्गों की गणना करेगा। फैक्ट्री द्वारा बनाई गई प्रत्येक प्लगइन के लिए, मैं इसे अपने एमवीसी कक्षाओं के लिए पूछूंगा, और मौजूदा जीयूआई लेआउट में उचित स्लॉट में अपने जीयूआई तत्व (मेनू आइटम, पैनल इत्यादि) को स्नैप कर दूंगा।

मैं (स्थानीय फाइल सिस्टम से लोड हो रहा है प्लग इन, वेब से नहीं) आकाशवाणी के भीतर इसी कार्य को पूरा करना चाहते हैं। this article पढ़ने के बाद, मेरी समझ यह है कि यह संभव है, और मूल आर्किटेक्चर (एसडब्ल्यूएफ को सैंडबॉक्स किए गए एप्लिकेशनडोमेन आदि में लोड करना) उसी तरह से है जैसा आप इसे .NET में करेंगे।

लेकिन मैं gotchas के बारे में उत्सुक हूँ।

यदि आप में से किसी ने फ़्लैश प्लेयर (अधिमानतः मिश्रित फ्लैश/फ्लेक्स ऐप्स में, और विशेष रूप से एआईआर होस्ट के भीतर) के साथ कोई गतिशील क्लासलोडिंग किया है, तो मुझे आपके प्लगइन ढांचे के निर्माण के अनुभवों के बारे में सुनना अच्छा लगेगा और आप कहां से फ़्लैश प्लेयर, और फ्लैश, फ्लेक्स और एआईआर एपीआई के साथ मुश्किल परिस्थितियों में भाग गया।

उदाहरण के लिए, अगर किसी ने मुझे यह प्रश्न पूछा है, लेकिन जावा प्लेटफ़ॉर्म के साथ, मैं निश्चित रूप से उल्लेख करता हूं कि JVM में "मॉड्यूल" या "असेंबली" की कोई धारणा नहीं है। एकत्रीकरण का उच्चतम स्तर "वर्ग" है, इसलिए बड़ी परियोजनाओं के प्रबंधन के लिए प्लगइन सिस्टम के भीतर संगठनात्मक संरचनाएं बनाना मुश्किल हो सकता है। मैं कई क्लासलोडर्स के साथ मुद्दों के बारे में भी बात करता हूं और कैसे प्रत्येक लोड किए गए वर्ग के अपने अलग-अलग उदाहरण को बनाए रखता है (अपने स्वयं के अलग-अलग स्थिर वार्स के साथ)।

---

यहाँ कुछ विशिष्ट प्रश्न अभी भी मेरे लिए अनुत्तरित हैं:

1) actionscript "लोडर" वर्ग एक ApplicationDomain में एक SWF लोड कर सकते हैं। लेकिन उस एपडोमेन में वास्तव में क्या होता है? मॉड्यूल? क्लासेस? एमएक्सएमएल घटकों का प्रतिनिधित्व कैसे किया जाता है? मैं अपने प्लगइन इंटरफेस को लागू करने वाले सभी वर्गों को कैसे ढूंढूं?

2) यदि आप मुख्य आवेदन से एक अलग ApplicationDomain में एक प्लगइन लोड किया है, तो यह काफी अधिक जटिल है कि अन्य appdomain के भीतर से कोड कॉल करने के लिए है? क्या इंटर-एपडोमेन मार्शलिंग परत से गुज़रने वाले डेटा के प्रकार के बारे में कोई महत्वपूर्ण सीमाएं हैं? Marshalling निषिद्ध रूप से महंगा है?

3) आदर्श रूप में, मैं प्लगइन के रूप में अपने मुख्य कोड का अधिकांश हिस्सा विकसित करना चाहता हूं (मुख्य एप्लिकेशन प्लगइन लोडिंग खोल से थोड़ा अधिक है) और प्लगइन आर्किटेक्चर का उपयोग उस कार्यक्षमता को बढ़ाने के लिए करें एप्लिकेशन। क्या यह आपके दिल में डरता है?

Answer 1

लुका Tettamanti पहले से ही अपने विशिष्ट प्रश्न के लिए अच्छा जवाब दिया, तो मैं बस सामान्य विषय पर कुछ अतिरिक्त जानकारी प्रदान करेंगे:

मैं ModuleManager वर्ग का उपयोग कर एक फ्लेक्स अनुप्रयोग के लिए एक सरल प्लगइन एपीआई को क्रियान्वित किया है (और mx.modules पैकेज में अन्य सामान।) इसका अर्थ यह है कि आप ModuleBase से प्लगइन्स को उप-वर्गीकृत करते हैं और मेजबान ऐप में उन्हें लोड करने के लिए ModuleManager का उपयोग करते हैं। फिर आपके पास प्लगइन एक सामान्य इंटरफेस को कार्यान्वित करते हैं (उदाहरण के लिए IMyAppPlugin) और कुछ प्रकार के facade का उपयोग करें ताकि प्लगइन का उपयोग करने वाले मेजबान एप्लिकेशन को इंटरफ़ेस का प्रतिनिधित्व और कार्यान्वित किया जा सके (उदाहरण के लिए MyAppFacade implements IMyAppFacade।) जब भी प्लगइन लोड हो जाते हैं, तो इस मुखौटा संदर्भ को इंजेक्ट करें उन्हें।

विषय "Modular applications overview" फ्लेक्स 3 मदद में कुछ अच्छा जानकारी है यहाँ एक अंश है (subchapter "मॉड्यूल डोमेन" मॉड्यूल के संदर्भ में आवेदन डोमेन चर्चा करता है।):

"डिफ़ॉल्ट रूप से, एक मॉड्यूल वर्तमान एप्लिकेशन डोमेन के एक बच्चे डोमेन में लोड किया गया है। का उपयोग करके एप्लिकेशन का उपयोग करके विभिन्न एप्लिकेशन डोमेन निर्दिष्ट कर सकते हैं। मॉड्यूललोडर क्लास की संपत्ति संपत्ति। "

विषय "Using the ApplicationDomain class" आवेदन डोमेन के विषय पर और अधिक गहराई में चला जाता है, और आप निश्चित रूप से इसे पढ़ना चाहिए यदि आपने ऐसा नहीं किया है।

Answer 2

1. applicationDomain अधिक एक नाम स्थान की तरह है, यह समूह वर्ग परिभाषाएँ और उन्हें एक पदानुक्रम में डाल दिया: एक डोमेन सीधे अपने स्वयं के डोमेन या माता-पिता डोमेन प्रतीकों का उपयोग कर सकते हैं, लेकिन बच्चे या भाई में नहीं डोमेन (या बेहतर: यह सीधे ऐसा नहीं कर सकता - इसे किसी दिए गए वर्ग की परिभाषा पूछने के लिए आवेदन वस्तु वस्तु के माध्यम से जाना चाहिए); बाहरी एसएफएफ लोड करते समय आप तय कर सकते हैं जहां नए प्रतीक डालने के लिए: एक बच्चे डोमेन (डिफ़ॉल्ट), सिस्टम से जुड़ा एक नया डोमेन (शून्य का उपयोग करके), वर्तमान डोमेन, कहीं और एक डोमेन संलग्न है (स्पष्ट रूप से गुजर रहा है नए डोमेन के माता-पिता)। ध्यान दें कि नए प्रतीक कभी भी मौजूदा डोमेन में प्रतीकों को ओवरराइट नहीं करेंगे, लेकिन एक ही नाम एकाधिक डोमेन में मौजूद हो सकता है।
   दुर्भाग्यवश आप किसी दिए गए डोमेन में कक्षाओं की गणना नहीं कर सकते हैं (ठीक है, कम से कम मुझे ऐसा करने का कोई तरीका नहीं पता), लेकिन सामान्य समाधान की आवश्यकता है (जैसे "प्लगइन इंटरफेस" में) कुएं की उपस्थिति प्रत्येक एसएफएफ में ज्ञात कारखाना, जो प्लगइन या प्लगइन की परिभाषा (कक्षा) को वापस कर देगा।
2. आप किसी भी तरह वस्तु (कारखाना) का संदर्भ प्राप्त कर चुके हैं, तो यह सिर्फ एक और वस्तु है। कोई marshalling नहीं है: डोमेन यह नामस्थान की सिर्फ एक तार्किक विभाजन है (यह सिस्टम डोमेन की एक वृक्ष शाखा है)।
3. नहीं :) लेकिन चेतावनी दी जानी चाहिए: यह आसानी से जीसी के लिए नरक में बदल सकता है, जहां अप्रयुक्त डोमेन को अन्य डोमेन में फैले संदर्भों के कारण अनलोड नहीं किया जा सकता है। मैं प्लगइन के बीच सख्त अलगाव सुनिश्चित करने के लिए संभवतः पाइप के साथ बहु-कोर शुद्ध एमवीसी ढांचे पर एक नज़र डालने का सुझाव देता हूं।

बीटीडब्ल्यू, फ़्लैश प्लेयर सुरक्षा डोमेन की अवधारणा भी है, लेकिन मैंने वास्तव में इसे कभी छुआ नहीं है, इसलिए मुझे नहीं पता कि संभावनाएं क्या हैं।

Answer 3

जावा एक संभव प्लग-इन आर्किटेक्चर के रूप में के बारे में बयान पर प्रतिक्रिया:

यह जावा पता चला है कई वर्षों के लिए प्लग-इन आर्किटेक्चर सिस्टम वसीयत करने के लिए इस्तेमाल किया गया है। क्लाइंट-साइड के रूप में, विषुव ओएसजीआई मॉड्यूल प्रबंधन ढांचे शायद सबसे अच्छी तरह से जाना जाता है। एक बिंदु पर ग्रहण आईडीई ने इक्विनोक्स ओएसजीआई के शीर्ष पर अपने प्लग-इन आर्किटेक्चर को दोहराया। ग्रहण आईडीई शायद सबसे सफल क्लाइंट-साइड प्लग-इन आर्किटेक्चर सिस्टमों में से एक है जिसे अभी तक बनाया गया है - ऐतिहासिक दीर्घायु दृष्टिकोण से और उपयोगकर्ता आधार की चौड़ाई और प्लग-इन विकास के फॉलो-ऑन समुदाय से। वे अपने प्लगइन आर्किटेक्चर को अनियंत्रित क्लाइंट-साइड अनुप्रयोगों - ग्रहण आरसीपी बनाने के लिए एक आधारभूत रूपरेखा के रूप में भी पेश करते हैं।

मुझे बस इसे इंजेक्ट करना पड़ा क्योंकि जावा को शायद इसके लिए बहुत ही कमजोर विकल्प के रूप में रखा गया था, लेकिन वास्तव में यह किसी भी अन्य भाषा/रनटाइम पर्यावरण की तुलना में कहीं अधिक सफल है, जो कि इस प्रकार की कार्य प्रणाली प्रदान करने में आज तक है - खासकर बनाम। सी # .NET, जो, निश्चित रूप से, मॉड्यूल के लिए अच्छी सहज सुविधा है। तरह का विडंबना है, लेकिन वहां आपके पास है।

एडोब एयर के रूप में, मैं एक परियोजना का प्रबंधन कर रहा हूं जिसे यह एआईआर पर तैयार किया जा रहा है। हमारे मामले में हमारी मॉड्यूल विस्तारशीलता हमेशा वेब सर्वर से वितरित की जा रही है - स्थानीय निर्देशिका नहीं। फ्लेक्स मॉड्यूल जो रनटाइम पर कड़ाई से लोड किया जा सकता बनाने के लिए

<mx:Module/>

टैग है।

हां, एआईआर के साथ एक निराशा अन्य अनुप्रयोगों को लॉन्च करने के लिए किसी भी वर्ग एपीआई की कमी है। आप उपयोगकर्ता के डिफ़ॉल्ट ब्राउज़र में कुछ लोड करने के लिए एक यूआरएल लोड कर सकते हैं, लेकिन आप एक्सेल लॉन्च नहीं कर सकते हैं। जावा और सी # दोनों में बाहरी ऐप्स के रूप में अन्य ऐप्स लॉन्च करने के लिए एपीआई हैं।

Answer 4

क्या आपने उप-एप्लिकेशन लोड करने का प्रयास किया है?
एआईआर में ऐसा करने के लिए अच्छा दस्तावेज है और मैं कुछ घंटों में इसके साथ सफल रहा। हालांकि, उप-अनुप्रयोग और मुख्य आवेदन के बीच सैंडबॉक्स उल्लंघन के कारण फ्लेक्स में एक ही कार्यान्वयन एक अलग कहानी है। मैंने दीवारों में अपने सिर को तेज़ करने में सप्ताह बिताए हैं।