मल्टी-मॉड्यूल प्रोजेक्ट के साथ जीवन इतना सरल नहीं है। एक नया मॉड्यूल बनाने की दिनचर्या से बचने के लिए, हमने एंड्रॉइड स्टूडियो के लिए अपना प्लग-इन बनाया। कार्यान्वयन की प्रक्रिया में, हमने व्यावहारिक प्रलेखन की कमी का सामना किया, कई तरीकों की कोशिश की और कई नुकसानों को खोदा। यह दो लेख निकला: "सिद्धांत" और "अभ्यास" । मुझसे मिलो!

मैं किस बारे में बात करूंगा?

• क्यों एक प्लगइन? क्यों एक प्लगइन?
  
  • चेकलिस्ट तैयार करना
  • चेकलिस्ट स्वचालन विकल्प
• प्लगइन विकास मूल बातें
  
  • क्रिया
  • प्लगइन्स में यूआई विकास
  • निष्कर्ष
• आईडिया इंटर्न: घटक, पीएसआई
  
  • आईडिया आंतरिक इकाई
  • पीएसआई
  • निष्कर्ष

क्यों एक प्लगइन? क्यों एक प्लगइन?

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

1. सबसे पहले, हम मेनू के माध्यम से ही मॉड्यूल बनाते हैं फ़ाइल -> नया -> नया मॉड्यूल -> एंड्रॉइड लाइब्रेरी।

2. हम सेटिंग में मॉड्यूल को पथ लिखते हैं ।ग्रेड फ़ाइल, क्योंकि हमारे पास कई प्रकार के मॉड्यूल हैं - कोर-मॉड्यूल और फ़ीचर-मॉड्यूल, जो विभिन्न फ़ोल्डरों में हैं।

// settings.gradle include ':analytics project(':analytics').projectDir = new File(settingsDir, 'core/framework-metrics/analytics) ... include ':feature-worknear' project(':feature-worknear').projectDir = new File(settingsDir, 'feature/feature-worknear') 

3. हम स्थिरांक में स्थिरांक compileSdk , minSdk , targetSdk को बदलते हैं। निर्माण : हम उन्हें स्थिरांक के साथ प्रतिस्थापित करते हैं जो मूल build.gradle में परिभाषित होते हैं।

 // Feature module build.gradle … android { compileSdkVersion rootProject.ext.targetSdkVersion defaultConfig { minSdkVersion rootProject.ext.minSdkVersion targetSdkVersion rootProject.ext.targetSdkVersion ... } } 

नोट: हमने हाल ही में अपने काम के इस हिस्से को अपने ग्रेडल प्लगइन में हटा दिया है, जो बिल्ड.ग्रेड फ़ाइल के सभी आवश्यक मापदंडों को कई लाइनों में कॉन्फ़िगर करने में मदद करता है।

4. चूंकि हम कोटलिन में सभी नए कोड लिख रहे हैं, एक मानक के रूप में हम दो प्लगइन्स कनेक्ट करते हैं: कोटलिन-एंड्रॉइड और कोटलिन-कप । यदि मॉड्यूल किसी तरह UI के साथ जुड़ा हुआ है, तो हम इसके अलावा कोटलिन-एंड्रॉइड-एक्सटेंशन मॉड्यूल को कनेक्ट करते हैं।

 // Feature module build.gradle apply plugin: 'com.android.library' apply plugin: 'kotlin-android' apply plugin: 'kotlin-android-extensions' apply plugin: 'kotlin-kapt' 

5. हम सामान्य पुस्तकालयों और कोर-मॉड्यूल को जोड़ते हैं। कोर-मॉड्यूल हैं, उदाहरण के लिए, लकड़हारा, विश्लेषिकी, कुछ सामान्य उपयोगिताओं, और पुस्तकालयों - आरएक्सजाव, मोक्सी और कई अन्य।

 // Feature module build.gradle dependencies { def libraries = rootProject.ext.deps compileOnly project(':logger') compileOnly project(':analytics') … // Kotlin compileOnly libraries.kotlin // DI compileOnly libraries.toothpick kapt libraries.toothpickCompiler } 

6. टूथपिक के लिए कपेट सेट करें। टूथपिक हमारा मुख्य DI ढांचा है। सबसे अधिक संभावना आप जानते हैं: रिलीज़ बिल्ड में प्रतिबिंब के बजाय कोड पीढ़ी का उपयोग करने के लिए, आपको एनोटेशन प्रोसेसर को कॉन्फ़िगर करने की आवश्यकता होती है ताकि यह समझ सके कि ऑब्जेक्ट्स को बनाने के लिए कारखाने कहाँ से प्राप्त करें:

 // Feature module build.gradle defaultConfig { ... javaCompileOptions { annotationProcessorOptions { arguments = [ toothpick_registry_package_name: "ru.hh.feature_worknear" ] } } ... 

नोट: hh.ru में हम टूथपिक के पहले संस्करण का उपयोग करते हैं, दूसरे में हमने कोड पीढ़ी का उपयोग करने की क्षमता को हटा दिया ।

7. हम बनाए गए मॉड्यूल के अंदर Moxy के लिए kapt कॉन्फ़िगर करते हैं। Moxy एक आवेदन में MVP बनाने के लिए हमारा मुख्य ढांचा है, और आपको इसे थोड़ा मोड़ने की आवश्यकता है ताकि यह एक मल्टी-मॉड्यूल प्रोजेक्ट में काम कर सके। विशेष रूप से, kapt तर्कों में बनाए गए मॉड्यूल के पैकेज को पंजीकृत करें:

 // Feature module build.gradle android { ... kapt { arguments { arg("moxyReflectorPackage", "ru.hh.feature_worknear") } } ... 

नोट: हम पहले ही मोक्सी के नए संस्करण में बदल चुके हैं, और कोड पीढ़ी का यह हिस्सा इसकी प्रासंगिकता खो चुका है।

8. हम नई फ़ाइलों का एक समूह बनाते हैं। मेरा मतलब है कि वे फ़ाइलें जो स्वचालित रूप से बनाई गई हैं (AndroidManifest.xml, build.gradle, .gitignore), लेकिन नए मॉड्यूल की सामान्य रूपरेखा: इंटरसेप्टर, रिपॉजिटरी, डीआई मॉड्यूल, प्रस्तुतकर्ता, टुकड़े। इन फ़ाइलों की एक बहुत हैं, उनके पास शुरुआत में एक ही संरचना है, और उन्हें बनाना एक दिनचर्या है।

9. हम अपने बनाए गए मॉड्यूल को एप्लिकेशन मॉड्यूल से जोड़ते हैं। इस चरण में आपको एप्लिकेशन मॉड्यूल की बिल्ड.ग्रेड फ़ाइल में टूथपिक को कॉन्फ़िगर करना याद रखना चाहिए। ऐसा करने के लिए, हम बनाए गए मॉड्यूल के पैकेज को विशेष तर्क एनोटेशन प्रोसेसर - टूथपिक_ग्रिस्ट्री_चिल्ड्रेन_पैकेज_नाम में जोड़ते हैं।

 // App module build.gradle defaultConfig { … javaCompileOptions { annotationProcessorOptions { arguments = [ toothpick_registry_package_name: "ru.hh.android", toothpick_registry_children_package_names: [ "ru.hh.analytics", "ru.hh.feature_worknear", ... ].join(",") ] } } … 

उसके बाद, हम एप्लिकेशन मॉड्यूल में मोक्सी को कॉन्फ़िगर करते हैं। हमारे पास एक वर्ग है जो @RegisterMoxyReflectorPackages एनोटेशन के साथ चिह्नित है - वहां हम बनाए गए मॉड्यूल के पैकेज का नाम जोड़ते हैं:

 // App module file @RegisterMoxyReflectorPackages( "ru.hh.feature_force_update", "ru.hh.feature_profile", "ru.hh.feature_worknear" ... ) class MoxyReflectorStub 

और, अंत में, एप्लिकेशन मॉड्यूल की निर्भरता ब्लॉक के लिए बनाए गए मॉड्यूल को कनेक्ट करना न भूलें:

 // Application module build.gradle dependencies { def libraries = rootProject.ext.deps implementation project(':logger') implementation project(':dependency-handler') implementation project(':common') implementation project(':analytics') implementation project(':feature_worknear') ... 

हमें नौ बिंदुओं की एक सूची मिली।

चूंकि कई बिंदु हैं, यह कुछ भूल जाने की संभावना है। और फिर यह सोचकर घंटों बिताए कि क्या हुआ और परियोजना क्यों नहीं चल रही है।

हमने तय किया कि आप ऐसे नहीं रह सकते और आपको कुछ बदलने की जरूरत है।

चेकलिस्ट स्वचालन विकल्प

चेकलिस्ट को संकलित करने के बाद, हमने इसकी वस्तुओं को स्वचालित करने के लिए विकल्पों की तलाश शुरू की।

पहला विकल्प "Ctrl + C, Ctrl + V" करने का प्रयास था। हमने एंड्रॉइड लाइब्रेरी मॉड्यूल बनाने के लिए एक कार्यान्वयन खोजने की कोशिश की, जो हमारे लिए "बॉक्स से बाहर" उपलब्ध है। एंड्रॉइड स्टूडियो के साथ फ़ोल्डर में ( MacOs के लिए: / एप्लीकेशन / Android / Studio.app/Contents/plugins/android/lib/templates/gradle-projects/ ) उन विशेष टेम्पलेट्स के साथ एक विशेष फ़ोल्डर पा सकते हैं, जिन्हें आप फ़ाइल चुनते समय देखते हैं - > नया -> नया मॉड्यूल। हमने टेम्पलेट.xml.ftl फ़ाइल के अंदर आईडी बदलकर NewAndroidModule टेम्पलेट को कॉपी करने का प्रयास किया। फिर उन्होंने आईडीई लॉन्च किया, एक नया मॉड्यूल बनाना शुरू किया, और ... एंड्रॉइड स्टूडियो क्रैश हो गया क्योंकि नए मॉड्यूल बनाने के लिए मेनू में आपके द्वारा देखे जाने वाले मॉड्यूल की सूची हार्ड-कोडित है, आप इसे एक आदिम कॉपी-पेस्ट के साथ नहीं बदल सकते। जब आप किसी तत्व को लेने और जोड़ने, हटाने या बदलने का प्रयास करते हैं, तो Android Studio बस क्रैश हो जाता है।

चेकलिस्ट को स्वचालित करने का दूसरा विकल्प फ्रीमेकर टेम्पलेट इंजन था । एक असफल कॉपी-पेस्ट के प्रयास के बाद, हमने मॉड्यूल टेम्प्लेट पर एक करीब से देखने का फैसला किया और हुड के नीचे फ्रीमर्कर टेम्प्लेट पाए।

मैंने आपको यह नहीं बताया कि FreeMarker विस्तार से क्या है - RedMadRobot का एक अच्छा लेख है और Lesha Bykov के MosDroid का एक वीडियो है । लेकिन संक्षेप में - यह टेम्प्लेट और विशेष मानचित्र-की जावा-ऑब्जेक्ट्स का उपयोग करके फ़ाइलों को बनाने के लिए एक इंजन है। आप टेम्प्लेट, ऑब्जेक्ट्स फ़ीड करते हैं, और फ़्रीमेकर आउटपुट पर कोड उत्पन्न करता है।

लेकिन चेकलिस्ट को फिर से देखें:

यदि आप बारीकी से देखते हैं, तो आप देख सकते हैं कि यह कार्यों के दो बड़े समूहों में विभाजित है:

• एक नया कोड (1, 3, 4, 5, 6, 7, 8) और उत्पन्न करने के कार्य
• मौजूदा कोड को संशोधित करने के लिए कार्य (2, 7, 8, 9)

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

FreeMarker के साथ विफलता के बाद, चेकलिस्ट के प्रदर्शन के लिए मेरी खुद की कंसोल उपयोगिता लिखने का विचार आया। Intellij IDEA के अंदर टर्मिनल का उपयोग करना संभव है, तो क्यों नहीं? चलो बैश पर एक स्क्रिप्ट लिखें, कुल व्यवसाय:

लेकिन चूंकि हम बनाए गए मॉड्यूल को लचीले ढंग से कॉन्फ़िगर करने में सक्षम होना चाहते हैं, इसलिए हमें कई अलग-अलग झंडे दर्ज करने होंगे, जो कंसोल में प्रिंट करना बहुत सुविधाजनक नहीं होगा।

उसके बाद, हमने एक कदम पीछे लिया और याद किया कि हम Intellij IDEA के अंदर काम कर रहे हैं। और इसकी व्यवस्था कैसे की जाती है? कक्षाओं का एक निश्चित कोर है, एक इंजन जिसके लिए कई प्लग-इन संलग्न हैं, जो हमें आवश्यक कार्यक्षमता जोड़ते हैं।

आप में से कितने स्क्रीनशॉट में दो से अधिक जुड़े प्लगइन्स देखते हैं?

यहां वे कम से कम तीन से जुड़े हुए हैं। यदि आप कोटलिन के साथ काम करते हैं, तो आपके पास कोटलिन प्लगइन सक्षम है। यदि आप ग्रैडल के साथ किसी प्रोजेक्ट में काम कर रहे हैं, तो ग्रैडल प्लगइन भी शामिल है। यदि आप एक संस्करण नियंत्रण प्रणाली के साथ एक परियोजना में काम कर रहे हैं - गिट, एसवीएन या कुछ और - आपके पास इस वीसीएस को एकीकृत करने के लिए उपयुक्त प्लग-इन शामिल है।

हमने आधिकारिक JetBrains प्लगइन रिपॉजिटरी में देखा, और यह पता चला कि पहले से ही 4000 से अधिक आधिकारिक तौर पर पंजीकृत प्लगइन्स हैं! लगभग पूरी दुनिया प्लगइन्स लिखती है, और ये प्लगइन्स कुछ भी कर सकते हैं: एक प्रोग्रामिंग भाषा को आईडीईए में एकीकृत करने से शुरू होता है और विशिष्ट उपकरणों के साथ समाप्त होता है जिन्हें आईडीईए के भीतर से चलाया जा सकता है।

संक्षेप में, हमने अपना खुद का प्लगइन लिखने का फैसला किया।

प्लगइन विकास मूल बातें

हम प्लगइन विकास की मूल बातें पर चलते हैं। आरंभ करने के लिए, आपको केवल तीन चीजों की आवश्यकता है:

1. IntelliJ IDEA , न्यूनतम सामुदायिक संस्करण (आप अंतिम संस्करण में काम कर सकते हैं, लेकिन यह प्लगइन्स को विकसित करते समय विशेष लाभ नहीं देगा);
2. प्लगिन देवकैट इससे जुड़ा एक विशेष प्लगइन है जो अन्य प्लगइन्स को लिखने की क्षमता जोड़ता है;
3. और कोई भी JVM भाषा जिसमें आप एक प्लगइन लिखना चाहते हैं। यह कोटलिन, जावा, ग्रूवी - कुछ भी हो सकता है।

हम एक प्लगइन प्रोजेक्ट बनाकर शुरू करते हैं। हम नई परियोजना का चयन करते हैं, ग्रेड को इंगित करते हैं, हम IntelliJ प्लेटफ़ॉर्म प्लगइन पर टिक करते हैं और हम प्रोजेक्ट बनाते हैं।

नोट: यदि आप IntelliJ Platform Plugin चेकबॉक्स नहीं देखते हैं, तो इसका मतलब है कि आपके पास Plugin DevKit इंस्टॉल नहीं है।

आवश्यक फ़ील्ड भरने के बाद, हम एक खाली प्लगइन संरचना देखेंगे।

आइए इसे करीब से देखें। इसमें निम्न शामिल हैं:

• फ़ोल्डर जिसमें आप भविष्य की परियोजना के लिए कोड लिखेंगे; ( मुख्य / जावा , मुख्य / कोटलिन , आदि);
• build.gradle फ़ाइल, जिसमें आप कुछ पुस्तकालयों पर अपने प्लगइन की निर्भरता की घोषणा करेंगे, और इस तरह की चीज़ को gradle-intellij-plugin भी कॉन्फ़िगर करेंगे।

gradle-intellij-plugin - ग्रैडल प्लगइन जो आपको ग्रैडल को एक प्लगइन बिल्ड सिस्टम के रूप में उपयोग करने की अनुमति देता है। यह सुविधाजनक है क्योंकि लगभग हर Android डेवलपर ग्रैडल से परिचित है और जानता है कि इसके साथ कैसे काम करना है। इसके अलावा, gradle-intellij-plugin विशेष रूप से आपकी परियोजना में उपयोगी ढाल कार्य जोड़ता है:

• runIde - यह कार्य एक प्लगइन के साथ एक अलग IDEA उदाहरण लॉन्च करता है जिसे आप विकसित कर रहे हैं ताकि आप इसे डिबग कर सकें;
• buildPlugin - आपके प्लगइन का ज़िप संग्रह एकत्र करता है ताकि आप इसे स्थानीय रूप से या आधिकारिक IDEA रिपॉजिटरी के माध्यम से वितरित कर सकें;
• VerPlugin - यह कार्य सकल त्रुटियों के लिए आपके प्लगइन की जांच करता है जो इसे एंड्रॉइड स्टूडियो या कुछ अन्य आईडिया में एकीकृत करने की अनुमति नहीं दे सकता है।

और क्या है gradle-intellij-plugin दे रहा है ? इसकी मदद से, अन्य प्लगइन्स पर निर्भरता जोड़ना आसान हो जाता है, लेकिन हम इसके बारे में थोड़ी देर बाद बात करेंगे, लेकिन अब मैं कह सकता हूं कि gradle-intellij-plugin आपका भाई है, इसका उपयोग करें।

वापस प्लगइन संरचना के लिए। किसी भी प्लगइन की सबसे महत्वपूर्ण फ़ाइल plugin.xml है ।

 <idea-plugin> <id>com.experiment.simple.plugin</id> <name>Hello, world</name> <vendor email="myemail@yourcompany.com" url="http://www.mycompany.com"> My company </vendor> <description><![CDATA[ My first ever plugin - try to open Hello world dialog<br> ]]></description> <depends>com.intellij.modules.lang</depends> <depends>org.jetbrains.kotlin</depends> <depends>org.intellij.groovy</depends> <idea-version since-build="163"/> <actions> <group description="My actions" id="MyActionGroup" text="My actions"> <separator/> <action id="com.experiment.actions.OpenHelloWorldAction" class="com.experiment.actions.OpenHelloWorldAction" text="Show Hello world" description="Open dialog"> <add-to-group group-id="NewGroup" anchor="last"/> </action> </group> </actions> <idea-plugin> 

यह एक फ़ाइल है जिसमें शामिल है:

• आपका प्लगइन मेटाडेटा: पहचानकर्ता, नाम, विवरण, विक्रेता जानकारी, परिवर्तन लॉग
• अन्य प्लगइन्स पर निर्भरता का विवरण;
• यहां आप आईडीईए संस्करण भी निर्दिष्ट कर सकते हैं जिसके साथ आपका प्लगइन सही ढंग से काम करेगा
• यहां क्रियाओं का भी वर्णन किया गया है।

क्रिया

क्रिया क्या है? मान लीजिए कि आप एक नई फ़ाइल बनाने के लिए एक मेनू खोलते हैं। वास्तव में, इस मेनू के प्रत्येक तत्व को कुछ प्रकार के प्लगइन द्वारा जोड़ा गया है:

क्रियाएँ उपयोगकर्ताओं के लिए आपके प्लगइन के प्रवेश बिंदु हैं। हर बार जब उपयोगकर्ता मेनू आइटम पर क्लिक करता है, तो आपको प्लगइन के अंदर नियंत्रण मिलता है, आप इस क्लिक का जवाब दे सकते हैं और जो आवश्यक है उसे करते हैं।
एक्ट कैसे बनाए जाते हैं? आइए एक सरल एक्शन लिखें जो संदेश "हैलो, वर्ल्ड" के साथ एक संवाद प्रदर्शित करेगा।

 class OpenHelloWorldAction : AnAction() { override fun actionPerformed(actionEvent: AnActionEvent) { val project = actionEvent.project Messages.showMessageDialog( project, "Hello world!", "Greeting", Messages.getInformationIcon() ) } override fun update(e: AnActionEvent) { super.update(e) // TODO - Here we can update our action (for example, disable it) } override fun beforeActionPerformedUpdate(e: AnActionEvent) { super.beforeActionPerformedUpdate(e) // TODO - This method calls right before 'actionPerformed' } } 

एक्शन बनाने के लिए, हम, सबसे पहले, एनाशन क्लास से विरासत में मिली एक क्लास बनाएँ। दूसरे, हमें एक्शनपर्फ़ पद्धति को फिर से परिभाषित करना होगा, जहां एनाएवेंट क्लास का विशेष पैरामीटर आता है । इस पैरामीटर में आपके एक्शन के निष्पादन संदर्भ के बारे में जानकारी है। संदर्भ उस परियोजना को संदर्भित करता है जिसमें आप काम कर रहे हैं, फ़ाइल जो अब कोड संपादक में उपयोगकर्ता के लिए खुली है, प्रोजेक्ट ट्री में चयनित तत्व और अन्य डेटा जो आपके कार्यों को संसाधित करने में मदद कर सकते हैं।

"हैलो, दुनिया" संवाद दिखाने के लिए, हम पहले प्रोजेक्ट (बस AnActionEvent पैरामीटर से) प्राप्त करते हैं, और फिर डायलॉग बॉक्स प्रदर्शित करने के लिए उपयोगिता वर्ग संदेशों का उपयोग करते हैं।

एक्शन के अंदर हमारे पास क्या अतिरिक्त विशेषताएं हैं? हम दो तरीकों को ओवरराइड कर सकते हैं: अपडेट और पहले AAPPerformedUpdate ।

हर बार अपडेट विधि को आपके एक्शन परिवर्तनों का निष्पादन संदर्भ कहा जाता है। यह आपके लिए उपयोगी क्यों हो सकता है: उदाहरण के लिए, अपने प्लगइन द्वारा जोड़े गए मेनू आइटम को अपडेट करने के लिए। मान लीजिए आपने एक एक्शन लिखा है जो केवल कोटलिन फाइलों के साथ काम कर सकता है, और उपयोगकर्ता ने अब ग्रूवी फाइल को खोला है। फिर अपडेट विधि में आप अपनी कार्रवाई को दुर्गम बना सकते हैं।

पहले AActionPerformedUpdate विधि अद्यतन विधि के समान है, लेकिन इसे कार्रवाई से पहले सही कहा जाता है। अपनी कार्रवाई को प्रभावित करने का यह अंतिम अवसर है। प्रलेखन की सलाह है कि आप इस विधि में "भारी" कुछ भी नहीं करते हैं ताकि यह जल्द से जल्द चले।

आप IDEA इंटरफ़ेस के कुछ तत्वों में क्रियाओं को भी बांध सकते हैं और उन्हें कॉल करने के लिए डिफ़ॉल्ट कुंजी संयोजन सेट कर सकते हैं - मैं यहां इसके बारे में और अधिक पढ़ने की सलाह देता हूं।

प्लगइन्स में यूआई विकास

यदि आपको अपने स्वयं के संवाद डिजाइन की आवश्यकता है, तो आपको कड़ी मेहनत करनी होगी। हमने अपना UI विकसित किया क्योंकि हम एक सुविधाजनक चित्रमय इंटरफ़ेस चाहते थे जिसमें कुछ टिकों को चिह्नित करना संभव होगा, एनम मानों के लिए एक चयनकर्ता होगा, और इसी तरह।

यूआई के विकास के लिए प्लगइन देवकीट में कुछ क्रियाएं शामिल हैं, जैसे कि जीयूआई फॉर्म और डायलॉग । पहला हमारे लिए एक खाली फॉर्म बनाता है, दूसरा - दो बटन वाला एक फॉर्म: ठीक है और रद्द करें ।

ठीक है, एक फॉर्म डिजाइनर है , लेकिन वह है ... सो-सो। तुलना में, यहां तक ​​कि एंड्रॉइड स्टूडियो में लेआउट डिजाइनर आरामदायक और अच्छा दिखता है। पूरे यूआई को एक पुस्तकालय जैसे जावा स्विंग पर विकसित किया गया है। यह फ़ॉर्म डिज़ाइनर मानव-पढ़ने योग्य XML फ़ाइल बनाता है। यदि आप फॉर्म डिज़ाइनर में कुछ नहीं कर सकते हैं (उदाहरण: एक ही ग्रिड सेल में कई नियंत्रण सम्मिलित करें और सभी को छिपाएं लेकिन एक नियंत्रण), तो आपको इस फ़ाइल पर जाने और इसे बदलने की आवश्यकता है - IDEA इन परिवर्तनों को उठाएगा।

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

हम मूल बातें संक्षेप में प्रस्तुत करते हैं

• एक प्लगइन बनाने के लिए आपको आवश्यकता होगी: IDEA कम्युनिटी एडिशन, प्लगइन देवकित और जावा इससे जुड़ा।
• gradle-intellij-plugin आपका भाई है, यह आपके जीवन को बहुत सरल करेगा, मैं इसका उपयोग करने की सलाह देता हूं।
• जब तक आवश्यक न हो, अपना यूआई न लिखें। आईडीईए में कई उपयोगिता वर्ग हैं जो आपको बॉक्स से बाहर अपना यूआई बनाने की अनुमति देते हैं। यदि आपको कुछ जटिल चाहिए - कड़ी मेहनत करने के लिए तैयार हो जाओ।
• प्लगइन में किसी भी प्रकार की क्रिया हो सकती है। एक ही प्लगइन आपके आईडिया में बहुत अधिक कार्यक्षमता जोड़ सकता है।

आईडिया इंटर्न: घटक, पीएसआई

आइए आइडिए की आंतों के बारे में बात करते हैं, यह कैसे अंदर व्यवस्थित होता है। मैं आपको इसलिए बता रहा हूं कि जब मैं व्यावहारिक भाग समझाता हूं, तो आपके सिर में कुछ भी नहीं फटेगा, और ताकि आप समझ सकें कि यह कहां से आता है।

IDEA की व्यवस्था कैसे की जाती है? पदानुक्रम के पहले स्तर पर एक वर्ग है जैसे कि अनुप्रयोग । यह एक अलग विचार है। प्रत्येक IDEA उदाहरण के लिए, एक अनुप्रयोग वर्ग ऑब्जेक्ट बनाया जाता है। उदाहरण के लिए, यदि आप एक ही समय में AppCode, Intellij IDEA, Android Studio चलाते हैं, तो आपको एप्लिकेशन वर्ग के तीन अलग-अलग उदाहरण मिलेंगे। इस वर्ग को इनपुट / आउटपुट स्ट्रीम को संभालने के लिए डिज़ाइन किया गया है।

अगला स्तर प्रोजेक्ट क्लास है। IDEA में एक नया प्रोजेक्ट खोलते समय आप जो देखते हैं, वह यह निकटतम अवधारणा है। IDEA के अंदर अन्य घटकों को प्राप्त करने के लिए प्रोजेक्ट की आवश्यकता होती है: उपयोगिता वर्ग, प्रबंधक और बहुत कुछ।

विस्तार का अगला स्तर मॉड्यूल वर्ग है। सामान्य तौर पर, एक मॉड्यूल एक फ़ोल्डर में वर्गीकृत कक्षाओं का एक पदानुक्रम है। लेकिन यहाँ मॉड्यूल से हमारा मतलब है मावेन मॉड्यूल, ग्रैड मॉड्यूल। इस वर्ग की जरूरत है, सबसे पहले, मॉड्यूल के बीच निर्भरता निर्धारित करने के लिए, और दूसरी बात, इन मॉड्यूल के अंदर कक्षाओं की खोज करने के लिए।

विस्तार का अगला स्तर VirtualFile वर्ग है। यह वास्तविक फ़ाइल पर एक अमूर्तता है जो आपकी डिस्क पर है। कई VirtualFile इंस्टेंस प्रत्येक वास्तविक फ़ाइल के अनुरूप हो सकते हैं, लेकिन वे सभी समान हैं। उसी समय, यदि वास्तविक फ़ाइल हटा दी जाती है, तो VirtualFile को अपने आप हटाया नहीं जाएगा, लेकिन बस अमान्य हो जाएगा।

एक इकाई जैसे कि डॉक्यूमेंट प्रत्येक VirtualFile के साथ जुड़ा हुआ है। यह आपकी फ़ाइल के पाठ पर अमूर्तता है। दस्तावेज़ की आवश्यकता है ताकि आप फ़ाइल के पाठ में परिवर्तन से संबंधित घटनाओं को ट्रैक कर सकें: उपयोगकर्ता ने एक पंक्ति डाली, एक पंक्ति को हटा दिया, आदि, आदि।

इस पदानुक्रम का थोड़ा सा हिस्सा संपादक वर्ग है - यह एक कोड संपादक है। प्रत्येक प्रोजेक्ट में एक संपादक हो सकता है। यह आवश्यक है ताकि आप कोड संपादक से संबंधित घटनाओं को ट्रैक कर सकें: उपयोगकर्ता ने उस रेखा को हाइलाइट किया है जहां कैरेट है, और इसी तरह।

आखिरी बात जो मैं बात करना चाहता था वह है PsiFile । यह भी वास्तविक फ़ाइलों पर एक अमूर्त है, लेकिन कोड तत्वों का प्रतिनिधित्व करने के दृष्टिकोण से। PSI का मतलब प्रोग्राम स्ट्रक्चर इंटरफेस है।

और प्रत्येक कार्यक्रम में क्या होता है? एक नियमित जावा वर्ग पर विचार करें।

 package com.experiment; import javax.inject.Inject; class SomeClass { @Inject String injectedString; public void someMethod() { System.out.println(injectedString); } } 

इसमें एक पैकेज, आयात, वर्ग, फ़ील्ड, विधियाँ, एनोटेशन, कीवर्ड, डेटा प्रकार, संशोधक, पहचानकर्ता, विधि संदर्भ, अभिव्यक्ति और टोकन निर्दिष्ट करने के होते हैं। और प्रत्येक तत्व के लिए PsiElement का अमूर्तन है । अर्थात्, आपके प्रत्येक कार्यक्रम में PsiElements होते हैं।

PsiFile , बदले में, एक पेड़ की संरचना है जहां प्रत्येक तत्व में एक माता-पिता और कई वंशज हो सकते हैं।

मैं यह उल्लेख करना चाहूंगा कि पीएसआई एक सार वाक्यविन्यास पेड़ के बराबर नहीं है। एक सार वाक्यविन्यास वृक्ष आपके कार्यक्रम का एक प्रतिनिधित्व करने वाला पेड़ है, क्योंकि पार्सर आपके कार्यक्रम को पारित कर चुका है, और यह किसी भी प्रोग्रामिंग भाषा से अलग है। पीएसआई, इसके विपरीत, एक विशिष्ट प्रोग्रामिंग भाषा से बंधा हुआ है। जब आप एक जावा वर्ग के साथ काम करते हैं, तो आप Java PsiElements के साथ काम कर रहे हैं। जब एक ग्रूवी वर्ग के साथ काम कर रहा है - ग्रूवी साइलीस के साथ, और इसी तरह। यह विचार करना महत्वपूर्ण है, क्योंकि यदि आप किसी प्रोग्रामिंग भाषा के अंदर गलत PSI तत्वों के साथ काम करने की कोशिश करते हैं, तो प्लगइन आपके इच्छित तरीके से काम नहीं करेगा, यह शूट और क्रैश करेगा।

PSI के बारे में जानना अभी भी महत्वपूर्ण क्यों है - क्योंकि पूरे IDEA को PSI संरचना के साथ अनुमति दी गई है। यदि मौजूदा कार्यक्रमों के कोड के साथ काम करते समय आप इस संरचना को ध्यान में नहीं रखते हैं, तो इसके चारों ओर काम करने की कोशिश करें, फिर आपका प्लगइन बिल्कुल भी काम नहीं करेगा जैसा कि आप उम्मीद करते हैं। मैं व्यावहारिक भाग में इसका अलग से उल्लेख करूंगा।

हम IDEA के आंतरिक भाग के बारे में संक्षेप में बताते हैं

• IDEA के अंदर कार्यक्रम का प्रतिनिधित्व करने के लिए PSI की आवश्यकता होती है;
• पूरे आईडीईए को पीएसआई संरचना के साथ अनुमति दी गई है, सभी प्लगइन्स इसके बारे में जानते हैं, और आपको इसके बारे में भी जानना चाहिए;
• प्रत्येक प्रोग्रामिंग भाषा में PsiElements का अपना संग्रह है।

, . .