Lightbuild की मदद से, डिक्लेरेटिव और एजेंट के लिए तैयार Android बिल्ड

सभी को नमस्ते।

मेरा नाम हुआन सेबेस्टियन ओविएडो है.

मैं Android डेवलपर एक्सपीरियंस टीम में प्रॉडक्ट मैनेजर हूं.

मैं यहां स्कॉट के साथ हूं. आज हम आपके साथ Lightbuild की झलक शेयर करने के लिए बेहद उत्साहित हैं. यह Android ऐप्लिकेशन के लिए, एक्सपेरिमेंट के तौर पर उपलब्ध एक नया बिल्ड एक्सपीरियंस है.

मैं इस प्रोजेक्ट के बारे में बताऊंगी. साथ ही, इसके पीछे की सोच और यह भी बताऊंगी कि हमें क्यों लगता है कि Android प्रोजेक्ट को कॉन्फ़िगर करने के तरीके पर फिर से विचार करने का यह सही समय है.

हम यह भी बताएंगे कि यह नया तरीका, Android ऐप्लिकेशन डेवलपमेंट के भविष्य को कैसे बेहतर बनाता है.

आइए, सबसे पहले यह जानते हैं कि आज के समय में चीज़ें कैसे काम करती हैं.

Gradle और इंपरेटिव बिल्ड स्क्रिप्ट की मदद से, डेवलपर अपने बिल्ड के बारे में प्रोग्राम के हिसाब से करीब-करीब हर चीज़ तय कर सकते हैं.

उदाहरण के लिए, आपके पास ऐसा लॉजिक हो सकता है जो Git इतिहास के आधार पर, वर्शन कोड को डाइनैमिक तौर पर कंप्यूट करता है. इसके अलावा, ऐसेट को बदलने वाला कोई कस्टम टास्क तय किया जा सकता है.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

Gradle के साथ-साथ, एजीपी या Android Gradle प्लगिन भी होता है. यह Gradle के सामान्य इंजन का इस्तेमाल करता है और उसे Android टूलचेन के हिसाब से अडजस्ट करता है.

Gradle और एजीपी मिलकर एक डाइनैमिक सिस्टम बनाते हैं. इससे आज लाखों प्रोडक्शन ऐप्लिकेशन के लिए, बिल्ड कॉन्फ़िगरेशन का अनुभव बेहतर होता है.

इस सुविधा की वजह से, हमारे डेवलपर टूल एक खास आर्किटेक्चरल लाइफ़ साइकल के तहत काम करते हैं.

जब कोई प्रोजेक्ट खोला जाता है, ब्रांच बदली जाती हैं या किसी बिल्ड फ़ाइल में बदलाव किया जाता है, तो आईडीई को आपके प्रोजेक्ट के कॉन्फ़िगरेशन की पूरी जानकारी होनी चाहिए. इससे वह कोड पूरा करने और कोड नेविगेशन जैसी सुविधाओं को बेहतर तरीके से चला पाता है.

बिल्ड फ़ाइलें, ट्यूरिंग-कंप्लीट भाषा में लिखी जाती हैं. इसलिए, IDE के लिए कॉन्फ़िगरेशन जानने का एकमात्र सामान्य तरीका, बिल्ड स्क्रिप्ट चलाना है.

आईडीई सिंक के दौरान, बिल्ड सिस्टम कॉन्फ़िगरेशन के फ़ेज़ से गुज़रता है.

यह आपकी बिल्ड स्क्रिप्ट का आकलन करता है, प्लगिन लॉजिक को लागू करता है, और प्रोजेक्ट मॉडल बनाता है.

इससे Android Studio में आपके प्रोजेक्ट का व्यू, आपके असल प्रोजेक्ट कॉन्फ़िगरेशन के साथ अलाइन हो जाता है.

डेवलपर के तौर पर, आपकी सबसे बड़ी प्राथमिकता एक बेहतरीन Android ऐप्लिकेशन बनाना और उसे अपने उपयोगकर्ताओं तक पहुंचाना है.

हालांकि, बिल्ड स्क्रिप्ट को मैनेज करने, एजीपी को अप-टू-डेट रखने, और प्रोजेक्ट को आईडीई के साथ सिंक रखने में समय और मेहनत लगती है.

Google और अन्य प्लैटफ़ॉर्म पर कई ऐसी पहल की जा रही हैं जिनसे इस क्षेत्र में डेवलपर के अनुभव को बेहतर बनाया जा सके.

डिक्लेरेटिव Gradle और Kotlin टूलचेन जैसी पहलों का मकसद, एक्ज़ीक्यूटेबल बिल्ड स्क्रिप्ट को डिक्लेरेटिव बिल्ड कॉन्फ़िगरेशन से बदलना है.

Android Studio में, हमारे पास AGP अपग्रेड असिस्टेंट है. यह आपको AGP के एक वर्शन से दूसरे वर्शन पर जाने के लिए ज़रूरी बदलावों के बारे में बताता है.

हम एजेंट को अपग्रेड करने की स्किल भी उपलब्ध कराते हैं. एजेंट इसे इंस्टॉल करके, AGP को अपग्रेड कर सकते हैं.

इसके अलावा, हम फ़ेज़्ड सिंक और रेज़िलियंट सिंक जैसी सुविधाओं पर काम कर रहे हैं, ताकि डेवलपर को अपने प्रोजेक्ट सिंक और इंपोर्ट करते समय बेहतर अनुभव मिले.

इनमें से हर कोशिश, समस्या के एक हिस्से को हल करने के लिए की जाती है. इससे डेवलपर को अपने ऐप्लिकेशन बनाने के लिए ज़्यादा समय मिल पाता है. साथ ही, उन्हें अपने प्रोजेक्ट बनाने, बिल्ड फ़ाइलों को मैनेज करने, और प्रोजेक्ट को सिंक करने में कम समय लगता है.

इन कोशिशों के साथ-साथ, हमने खुद से एक बड़ा सवाल पूछा.

क्या होगा अगर हम प्रोजेक्ट को कॉन्फ़िगर करने के तरीके को नए सिरे से तैयार करें?

आज के समय में, मॉडर्न Android ऐप्लिकेशन के आर्किटेक्चर को देखने पर, हमें मॉड्यूलर आर्किटेक्चर की ओर एक बड़ा बदलाव देखने को मिलता है.

बड़े कोड बेस में अक्सर दर्जनों या सैकड़ों मॉड्यूल होते हैं: यूज़र इंटरफ़ेस (यूआई) मॉड्यूल, फ़ीचर मॉड्यूल, डोमेन मॉड्यूल, और डेटा मॉड्यूल.

हालांकि, रूट ऐप्लिकेशन को कभी-कभी कस्टम पैकेजिंग की ज़रूरत पड़ सकती है, लेकिन ज़्यादातर लाइब्रेरी मॉड्यूल, स्टैंडर्ड पैटर्न का पालन करते हैं.

उन्हें अपनी बिल्ड फ़ाइलों में, एक्ज़ीक्यूट किए जा सकने वाले किसी ऐसे कोड की ज़रूरत नहीं होती जो ओरिजनल प्रोग्राम का हिस्सा नहीं है.

उन्हें बस अपने स्ट्रक्चर और डिपेंडेंसी को साफ़ तौर पर बताने का एक तरीका चाहिए.

इस बात को ध्यान में रखते हुए, हमने Lightbuild बनाया.

Lightbuild दो मुख्य सिद्धांतों पर काम करता है.

सबसे पहले, यह कॉन्फ़िगरेशन के लिए डिक्लेरेटिव सिंटैक्स का इस्तेमाल करता है. इससे बिल्ड कॉन्फ़िगरेशन और लॉजिक के बीच साफ़ तौर पर अंतर पता चलता है.

दूसरा, यह डिपेंडेंसी को पहले से रिज़ॉल्व करके, IDE को तेज़ी से सिंक करने की सुविधा देता है.

मैं इनमें से हर पिलर के बारे में विस्तार से बताऊंगा, ताकि आप देख सकें कि वे आपके रोज़ के वर्कफ़्लो पर कैसे असर डालते हैं.

आइए, डिक्लेरेटिव बिल्ड कॉन्फ़िगरेशन के मुख्य हिस्से से शुरुआत करते हैं.

स्क्रीन पर बाईं ओर मौजूद फ़ाइल को देखें.

यह आज के लिए, किसी मॉड्यूल का कॉन्फ़िगरेशन दिखाता है.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

यह फ़ाइल, एक्ज़ीक्यूटेबल कोड है. इसलिए, इसमें लोकल वैरिएबल की परिभाषाएं, कस्टम हेल्पर फ़ंक्शन या कन्वेंशन प्लग इन के कॉल, कंडिशनल स्टेटमेंट, और इन-लाइन टास्क की परिभाषाएं हो सकती हैं.

IDE को यह जानने के लिए कि इस कॉन्फ़िगरेशन से क्या रिज़ॉल्व होता है, स्क्रिप्ट को चलाना ज़रूरी है.

अब स्क्रीन की दाईं ओर मौजूद फ़ाइल को देखें.

यह मिलते-जुलते मॉड्यूल के लिए Lightbuild कॉन्फ़िगरेशन है.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

इस फ़ाइल में सिर्फ़ डिक्लेरेटिव डेटा है.

इसमें कोई लोकल वैरिएबल डेफ़िनिशन, कस्टम हेल्पर फ़ंक्शन के लिए कोई कॉल, और कोई कंडिशनल स्टेटमेंट या इनलाइन टास्क डेफ़िनिशन नहीं होती.

इसमें मॉड्यूल के टाइप, उसके एसडीके टारगेट, और उसकी डिपेंडेंसी के बारे में साफ़ तौर पर बताया जाता है.

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

कॉन्फ़िगरेशन और लॉजिक को अलग-अलग रखने से, किसी व्यक्ति के लिए कोड को पढ़ना आसान हो जाता है. साथ ही, Agent Assist की मदद से किए जाने वाले वर्कफ़्लो के लिए भी यह काफ़ी मददगार होता है.

डेवलपर अपने वर्कफ़्लो में एजेंट का इस्तेमाल करते हैं. इसलिए, एजेंट के पास बिल्ड कॉन्फ़िगरेशन को पढ़ने और उसमें बदलाव करने की अनुमति होनी चाहिए.

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

कॉन्फ़िगरेशन फ़ाइल में एक लाइन जोड़ने से, प्रोजेक्ट में कहीं और डाइनैमिक तौर पर कंप्यूट किए गए वैरिएबल या कन्वेंशन प्लगिन के साथ समस्या हो सकती है.

Lightbuild में, आपके प्रोजेक्ट का कॉन्फ़िगरेशन एक डिटरमिनिस्टिक और स्टैटिक डेटा ग्राफ़ होता है.

इसका मतलब है कि एजेंट उस ग्राफ़ की जांच कर सकते हैं, मॉड्यूल टोपोलॉजी को समझ सकते हैं, और किसी जाने-पहचाने स्कीमा का इस्तेमाल करके उसमें बदलाव कर सकते हैं.

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

यह आपके प्रोजेक्ट के कॉन्फ़िगरेशन को एजेंट की मदद से किए जाने वाले वर्कफ़्लो के लिए सबसे अहम बनाता है.

एक और बात जो मैं यहां बताना चाहता हूं, वह यह है कि Lightbuild, बिल्ड सिस्टम का प्लग-इन नहीं है. यह बिल्ड इंजन का इंटरफ़ेस है.

Lightbuild का जो झलक हम आज रिलीज़ कर रहे हैं वह बैकग्राउंड में Gradle का इस्तेमाल करता है.

हालांकि, Lightbuild के साथ हमने जो आर्किटेक्चरल तरीका अपनाया है उससे Android Studio, आईडीई, प्रोजेक्ट को Lightbuild प्रोजेक्ट के तौर पर देखता है और उसे उसी तरह मैनेज करता है.

अब दूसरे पिलर के बारे में बात करते हैं. यह डेवलपर की प्रोडक्टिविटी और फ़्लो के बारे में है: आईडीई को तेज़ी से सिंक करना.

डेवलपर अपने वर्कफ़्लो में एजेंट का इस्तेमाल करते हैं. इसके बावजूद, Android Studio इंटरैक्टिव टास्क के लिए एक ज़रूरी टूल बना हुआ है. उदाहरण के लिए, Compose यूज़र इंटरफ़ेस (यूआई) की झलक देखने, किसी समस्या की जांच करने के लिए डीबगर में कोड को सिलसिलेवार तरीके से देखने या प्रोफ़ाइलर की मदद से परफ़ॉर्मेंस का विश्लेषण करने के लिए.

आपके प्रोजेक्ट का कॉन्फ़िगरेशन, डिटरमिनिस्टिक और स्टैटिक डेटा ग्राफ़ होता है. इसलिए, IDE को आपके प्रोजेक्ट को समझने के लिए, स्क्रिप्ट की जांच करने या प्लगिन कोड को चलाने की ज़रूरत नहीं होती.

चाहे आपको कोई प्रोजेक्ट खोलना हो, बिल्ड फ़ाइल में बदलाव करना हो या ब्रांच स्विच करनी हो, IDE उस जानकारी को तेज़ी से प्रोसेस कर सकता है और आपको सीधे आपके टूल पर ले जा सकता है.

Lightbuild की स्पीड और भरोसेमंद होने की एक वजह यह है कि यह डिपेंडेंसी को मैनेज करता है.

आम तौर पर, जब किसी डिपेंडेंसी का एलान किया जाता है, तो बिल्ड सिस्टम को ट्रांज़िटिव डिपेंडेंसी के ट्री से गुज़रना पड़ता है. इससे वर्शन की जानकारी इकट्ठा की जाती है और समस्याओं को हल किया जाता है.

Lightbuild में, डिपेंडेंसी में बदलाव होने पर, टूल अपने-आप ट्रांज़िटिव डिपेंडेंसी की जानकारी का हिसाब लगाता है. इसके बाद, वह हर मॉड्यूल डायरेक्ट्री में मौजूद resolved.deps फ़ाइल में उसे सेव करता है.

इससे, आने वाले समय में प्रोजेक्ट को फिर से खोलने या फिर से बनाने पर, आईडीई या बिल्ड टूल को ट्रांज़िटिव डिपेंडेंसी की जानकारी को फिर से कैलकुलेट करने की ज़रूरत नहीं पड़ती.

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

इसके अलावा, इस जानकारी को सोर्स कंट्रोल में सेव करके, यह पक्का किया जा सकता है कि आप, आपकी टीम के सदस्य, और आपकी सीआई/सीडी पाइपलाइन, हर बार डिपेंडेंसी के एक ही वर्शन के साथ बिल्ड कर सकें.

हमें यह बताते हुए खुशी हो रही है कि Lightbuild, Android Studio Canary में सार्वजनिक तौर पर उपलब्ध होने से पहले वाले वर्शन के तौर पर उपलब्ध है. साथ ही, यह अलग से उपलब्ध सीएलआई टूल के ज़रिए भी उपलब्ध है.

कृपया ध्यान रखें कि Lightbuild का यह वर्शन एक्सपेरिमेंट के तौर पर उपलब्ध है. इसलिए, इसमें वे सभी सुविधाएं नहीं हैं जो आपको प्रोडक्शन ऐप्लिकेशन बनाने और उसे मैनेज करने के लिए चाहिए.

डेमो और एक्सपेरिमेंटल प्रोजेक्ट में Lightbuild को आज़माते समय, कृपया अपने प्रोडक्शन ऐप्लिकेशन के लिए एजीपी और Gradle का इस्तेमाल जारी रखें.

आज ही goo.gle/lightbuild पर जाकर, इसका इस्तेमाल शुरू करें. हमें आपके सुझाव, शिकायत या राय का इंतज़ार रहेगा, ताकि हम इस प्रॉडक्ट को और बेहतर बना सकें.

अब मैं प्रज़ेंटेशन स्कॉट को सौंपता हूं, ताकि वे आपको Lightbuild के बारे में बता सकें.

धन्यवाद, जुआन.

मेरा नाम स्कॉट मायर्स है.

मैं Android डेवलपर रिलेशंस इंजीनियर हूं. हम कुछ समय से Lightbuild पर काम कर रहे हैं. हमें यह बताते हुए खुशी हो रही है कि आज से इसका इस्तेमाल किया जा सकता है.

इसलिए, सबसे पहले आपको उस लिंक पर जाना होगा जो जुआन ने बताया है, goo.gle/lightbuild या फिर Lightbuild को खोजें.

इसके बाद, आपको इस दस्तावेज़ वाले पेज पर जाना चाहिए. इसमें आपको शुरू करने के लिए ज़रूरी सभी चरण मिलेंगे. इनमें Android Studio का Canary वर्शन इंस्टॉल करना भी शामिल है. ध्यान रखें कि यह अब भी झलक के तौर पर उपलब्ध है. यह अब तक Android Studio के स्टेबल वर्शन में उपलब्ध नहीं है.

इसके अलावा, Lightbuild सीएलआई भी उपलब्ध है. इसे इंस्टॉल करके, Lightbuild के साथ एजेंटिक अनुभव के सभी फ़ायदे पाए जा सकते हैं.

इसलिए, इसे सेट अप करने के बाद, जैसा कि मैंने यहां अपनी मशीन पर किया है, मेरे पास Android Studio Canary का सबसे नया वर्शन चल रहा है.

अब मैं आपको Lightbuild प्रोजेक्ट का डेमो बनाकर दिखाऊंगा. साथ ही, यह भी बताऊंगा कि इसे आज ही कैसे बनाया जा सकता है.

सबसे पहले, मैं New Project विज़र्ड पर जाऊँगा.

मैं Empty Activity चुनूंगा और Next पर क्लिक करूंगा.

अब आपको प्रोजेक्ट की जानकारी वाली सामान्य स्क्रीन दिखेगी. हालांकि, यहां सबसे नीचे एक नया विकल्प मौजूद है.

बिल्ड कॉन्फ़िगरेशन की भाषा के तौर पर, Lightbuild को चुना जा सकता है.

साथ ही, 'पूरा करें' पर क्लिक करने से पहले, आपको यह याद दिलाया जाएगा कि यह सुविधा एक्सपेरिमेंट के तौर पर उपलब्ध है.

आपको तुरंत दिखेगा कि हमारा प्रोजेक्ट, आईडीई के साथ सिंक हो गया है और काम करने के लिए तैयार है.

अब हम Lightbuild के किसी सामान्य प्रोजेक्ट के स्ट्रक्चर पर नज़र डालते हैं.

इसलिए, यह सिर्फ़ डिफ़ॉल्ट Android टेंप्लेट है, जो आपको नया ऐप्लिकेशन बनाते समय मिलता है.

यह सिर्फ़ "नमस्ते, दुनिया के लोगों!" दिखाता है

इसलिए, यह शुरुआत करने का एक आसान तरीका है.

आपको दिखेगा कि हमारे प्रोजेक्ट के रूट लेवल पर, project.lightbuild.yaml नाम की एक फ़ाइल है.

इससे हमें अपने पूरे प्रोजेक्ट के लिए ग्लोबल सेटिंग मिलती हैं.

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

इसलिए, हमें यहां दो मॉड्यूल दिख रहे हैं: app और app-core.

ऐसा इसलिए है, क्योंकि Lightbuild के सभी प्रोजेक्ट में कम से कम दो मॉड्यूल होते हैं.

ऐसा इसलिए है, क्योंकि कम से कम एक ऐप्लिकेशन मॉड्यूल और एक लाइब्रेरी मॉड्यूल होना ज़रूरी है.

हम आपको इसकी वजह बताएंगे.

सबसे पहले, इस ऐप्लिकेशन मॉड्यूल को देखते हैं.

अगर मैं इसे यहां बड़ा करूं, तो आपको दिखेगा कि मॉड्यूल के रूट लेवल पर एक lightbuild.yaml फ़ाइल है. यह फ़ाइल हर मॉड्यूल में होगी.

इसमें कुछ बुनियादी जानकारी दी गई है.

ज़ाहिर है कि हम Android प्लैटफ़ॉर्म पर काम कर रहे हैं.

यह मॉड्यूल, ऐप्लिकेशन टाइप का है.

इसमें एसडीके के टारगेट वर्शन, ऐप्लिकेशन आईडी वगैरह की जानकारी दी जा सकती है. इसके बाद, उन सभी मॉड्यूल की सूची बनाई जा सकती है जिन पर यह ऐप्लिकेशन मॉड्यूल निर्भर करता है.

इस ऐप्लिकेशन मॉड्यूल के बारे में दिलचस्प बात यह है कि यह स्टैंडर्ड Android टेंप्लेट से थोड़ा अलग है. इसके सोर्स फ़ोल्डर में कुछ भी नहीं है.

इसलिए, Lightbuild में ऐप्लिकेशन मॉड्यूल में कोई सोर्स कोड नहीं होता.

इसकी वजह यह है कि इस ऐप्लिकेशन मॉड्यूल में अक्सर बदलाव नहीं किया जाएगा. हालांकि, इसे बनाने में कुछ समय लगता है.

इसलिए, अगर ऐप्लिकेशन के सभी कोड को लाइब्रेरी मॉड्यूल में रखा जाता है, तो हर बिल्ड तेज़ी से बनेगा. ऐसा इसलिए, क्योंकि ऐप्लिकेशन मॉड्यूल में मौजूद हर चीज़ को फिर से कैलकुलेट और रीपैकेज नहीं करना पड़ेगा.

अब ऐप्लिकेशन-कोर मॉड्यूल पर नज़र डालते हैं. यह वह लाइब्रेरी मॉड्यूल है जिस पर यह ऐप्लिकेशन मॉड्यूल निर्भर करता है.

आपको दिखेगा कि इस मॉड्यूल में सोर्स कोड मौजूद है.

यहां हमारा मुख्य लॉजिक है.

यह सिर्फ़ "नमस्ते, दुनिया के लोगों!" दिखाता है

इस मॉड्यूल में मौजूद lightbuild.yaml फ़ाइल को देखने पर, आपको पता चलेगा कि यह लाइब्रेरी टाइप की है.

यहां एसडीके के कुछ वर्शन नंबर भी सेट किए जा रहे हैं. हालांकि, इस मॉड्यूल में हमारी सभी बाहरी डिपेंडेंसी की सूची दी गई है.

साथ ही, यह हमारी यूनिट और इंस्ट्रुमेंटेड टेस्ट के बारे में भी बता रहा है.

इसके बाद, आइए एक और फ़ाइल पर नज़र डालते हैं, जो आपको यहां दिख सकती है. इसके बारे में जुआन ने थोड़ी जानकारी दी थी. हर मॉड्यूल में एक resolved.deps फ़ाइल होती है.

यह फ़ाइल, Lightbuild से अपने-आप जनरेट होती है.

इसका मतलब है कि आपको इसमें मैन्युअल तरीके से बदलाव नहीं करना चाहिए. हालांकि, इसमें इस मॉड्यूल में मौजूद सभी डिपेंडेंसी की सूची शामिल होगी.

इसलिए, आपकी सभी डिपेंडेंसी और ट्रांज़िटिव डिपेंडेंसी पहले से ही यहां मौजूद हैं.

इसका मतलब है कि जब आपका ऐप्लिकेशन IDE में खोला जाता है या जब आपको कोई बिल्ड बनाना होता है, तो आपको उस समय यह पता लगाने की ज़रूरत नहीं होती है. ऐसा इसलिए, क्योंकि यह पहले से ही पता होता है और आपके प्रोजेक्ट में इसकी जांच की जा चुकी होती है.

आइए, अब एक उदाहरण देखते हैं कि Lightbuild, प्रोजेक्ट सिंक करने की सुविधा के साथ डेवलपर के अनुभव को कैसे बेहतर बनाता है.

इसलिए, अब मैं अपने रूट लेवल project.lightbuild.yaml पर वापस आ गया हूं. यहां ग्लोबल सेटिंग है, जिसमें मेरे ऐप्लिकेशन के सभी मॉड्यूल की सूची है.

आम तौर पर, कॉन्फ़िगरेशन या बिल्ड कॉन्फ़िगरेशन फ़ाइलों में बदलाव करते समय, आपको एक सिंक बटन दिखेगा. इसे प्रोसेस होने में कुछ समय लगता है. ऐसा इसलिए होता है, क्योंकि जुआन ने बताया था कि इसे आपकी सभी बिल्ड स्क्रिप्ट को चलाकर, कुछ हद तक बिल्ड करना होता है. इसके बाद, उस मॉडल को IDE के साथ सिंक करना होता है.

इसलिए, चलिए इस छोटे से प्रोजेक्ट में एक बड़ा बदलाव करते हैं.

हम सिर्फ़ एक मॉड्यूल मिटाएंगे.

सेव बटन पर क्लिक करने से पहले, आपको यह मॉड्यूल दिखेगा. इसे आईडीई ने पहचान लिया है, क्योंकि यह यहां बोल्ड में दिख रहा है.

यह सोर्स डायरेक्ट्री और टेस्ट डायरेक्ट्री की पहचान कर लेता है.

बदलाव करने के बाद, जैसे ही मैंने 'सेव करें' पर क्लिक किया, यह मॉड्यूल प्रोजेक्ट से तुरंत हट गया.

अगर मैं उस बदलाव को फिर से पहले जैसा करके सेव करूं, तो वह तुरंत वापस आ जाता है.

यह Lightbuild की मदद से, आपके प्रोजेक्ट के लिए आईडीई को तेज़ी से सिंक करने का उदाहरण है.

इसके अलावा, Android Studio में इस्तेमाल किए जाने वाले सभी सामान्य कमांड भी इस्तेमाल किए जा सकते हैं.

'चलाएं' बटन पर क्लिक करें.

यह आपके ऐप्लिकेशन को कंपाइल करके यहां चलाएगा.

यह डेमो ऐप्लिकेशन बहुत बड़ा नहीं है, लेकिन मैं इसे ज़ूम इन करके दिखाऊंगा कि यह "हेलो Android" कह रहा है.

अपनी टेस्ट फ़ाइल में जाकर, टेस्ट को सामान्य तरीके से चलाया जा सकता है. इसके लिए, गटर से टेस्ट को इस तरह चलाएं.

इन टेस्ट को चलाने के लिए, यह पर्दे के पीछे Lightbuild को कॉल कर रहा है.

इसलिए, यह सब आपकी उम्मीद के मुताबिक काम करता है.

इसके बाद, मैं आपको यह दिखाना चाहता हूं कि अगर आप Android Studio में नहीं हैं, तो Lightbuild का इस्तेमाल कैसे किया जा सकता है. ऐसा तब होता है, जब किसी अन्य एजेंटिक फ़्लो का इस्तेमाल किया जा रहा हो.

इसके लिए, हमारे पास कमांड-लाइन है.

इसलिए, Lightbuild के सीएलआई में, मैं सिर्फ़ बुनियादी सहायता कमांड चलाऊंगा.

इस प्रोजेक्ट में आज आपको टाइपिंग की जो भी गलतियां दिख रही हैं वे मेरी हैं.

इसलिए, Lightbuild में कई अलग-अलग कमांड होंगे, जो इसमें पहले से मौजूद होंगे. जैसे, माफ़ करें, मैं इसे किसी प्रोजेक्ट के बाहर चला रहा हूं.

यह मुझे बार-बार यही बताता है.

हां, लाइव डेमो.

इसलिए, Lightbuild का कोई भी निर्देश चलाने से पहले, मुझे Lightbuild प्रोजेक्ट बनाने दें.

इसके लिए, मैं android create का इस्तेमाल करने जा रहा हूं. यह नए प्रोजेक्ट टेंप्लेट बनाने के लिए, हमारा स्टैंडर्ड कमांड-लाइन टूल है.

मैं empty-activity-lightbuild टेंप्लेट का इस्तेमाल करूंगा और अपने ऐप्लिकेशन का नाम Lightbuild Demo रखूंगा. इसके बाद, मैं इसे डेमो आउटपुट डायरेक्ट्री में डालूंगा.

ठीक है, अब अगर मैं उस डायरेक्ट्री में जाकर lightbuild -h टाइप करूं, तो मुझे Lightbuild में उपलब्ध सभी अलग-अलग कमांड दिखेंगे.

इसलिए, हमारे पास ऐसी कई चीज़ें हैं जिनकी आपको उम्मीद होगी: बिल्ड, क्लीन, टेस्ट.

हालांकि, कुछ नई सुविधाएं भी जोड़ी गई हैं.

एक रिज़ॉल्व कमांड होता है, जो आपके प्रोजेक्ट की डिपेंडेंसी के ज़रिए चलता है और वे resolved.deps फ़ाइलें जनरेट करता है जो मैंने पहले दिखाई थीं.

साथ ही, एक क्वेरी कमांड भी है. इसकी मदद से, आपको और आपके एजेंट को अपने प्रोजेक्ट के स्ट्रक्चर को बेहतर तरीके से समझने में मदद मिलती है.

सबसे पहले, मैं आपको क्वेरी कमांड की नई सुविधा के बारे में बताती हूं.

इसलिए, अगर मैं कमांड लाइन का इस्तेमाल करके इस प्रोजेक्ट का स्ट्रक्चर देखूं, तो यह वही है जो मेरे पास Android Studio के डेमो में था.

लेकिन इससे मुझे यह नहीं पता चल रहा है कि मेरा प्रोजेक्ट कैसा दिखेगा.

इसलिए, अगर मैं Lightbuild क्वेरी करता हूं और इस ऐप्लिकेशन मॉड्यूल को देखता हूं, तो मैं इस खास सिंटैक्स का इस्तेमाल करके कहूंगा, "मुझे इस ऐप्लिकेशन मॉड्यूल में मौजूद हर चीज़ दिखाओ."

इससे मुझे अलग-अलग टारगेट की यह अच्छी टेबल मिलती है, जिसे मैं ऐप्लिकेशन मॉड्यूल में बना सकता हूं.

इसलिए, इसमें डीबग और रिलीज़ बाइनरी, दोनों के लिए APK और एएबी होते हैं.

अगर मैं सिर्फ़ ऐप्लिकेशन टारगेट चलाऊं, तो यह सब कुछ बना देगा.

इसके अलावा, आउटपुट को JSON के तौर पर भी सेट किया जा सकता है.

इस तरह से, ओह, माफ़ करें.

आज भी, टाइपिंग की मेरी सभी गलतियां असली हैं.

यहां, मैं इंटरैक्टिव Lightbuild की मदद का इस्तेमाल करता हूं, ताकि यह पक्का कर सकूं कि मैं इसे सही तरीके से कर रहा हूं.

ओह…

हां, यह काम करना चाहिए.

ठीक है।

अगर किसी को लगता है कि मैं कुछ गलत कर रहा हूं, तो इस बातचीत के बाद मुझसे बात करें.

हालांकि, इस टेबल के बजाय, Lightbuild कमांड को JSON के तौर पर भी आउटपुट किया जा सकता है. इससे आपके एजेंट के लिए काम करना आसान हो जाता है.

--format json…

ओह, फ़ॉर्मैट.

ओह, माफ़ करें.

धन्यवाद.

यह डेवलपर को लाइव सुझाव/राय देने या शिकायत करने की सुविधा है.

धन्यवाद.

ठीक है, हाँ, और आउटपुट कमांड भी है जिसे मैं डेमो भी कर सकता हूँ, शायद आपकी मदद से.

इसलिए, अगर मैं टारगेट के बजाय फ़ाइलों को आउटपुट करूं, तो इससे मुझे अपने बिल्ड में मौजूद सभी अलग-अलग बाइनरी की जगहें दिखेंगी.

इसलिए, यह आपके और आपके एजेंट के लिए, Lightbuild का इस्तेमाल करके कमांड लाइन से अपने प्रोजेक्ट को बेहतर तरीके से एक्सप्लोर करने और समझने का एक तरीका है.

इसके बाद, ज़ाहिर है कि lightbuild resolve कमांड का इस्तेमाल किया जाएगा, जिसके बारे में मैंने पहले बताया था. इससे आपकी सभी resolved.deps फ़ाइलें जनरेट हो जाएंगी.

उसमें कुछ अतिरिक्त सुविधाएं भी हैं.

उदाहरण के लिए, लॉक की गई डिपेंडेंसी का यह पैरामीटर है. इसकी मदद से, इन फ़ाइलों को जनरेट करने के बजाय, फ़ाइलों के कॉन्टेंट की तुलना उन डिपेंडेंसी से की जाएगी जिनका एलान आपने बिल्ड कॉन्फ़िगरेशन में किया है.

अगर कोई अंतर होता है, तो यह आपको इसकी जानकारी देगा और बिल्ड को फ़ेल कर देगा.

इस तरह, रिज़ॉल्व की गई डिपेंडेंसी वाली ये फ़ाइलें, लॉक फ़ाइलों के तौर पर काम कर सकती हैं. उदाहरण के लिए, अगर प्रोडक्शन के लिए सीआई/सीडी सिस्टम में ऐप्लिकेशन बनाया जा रहा है, तो आपको यह जानना होगा कि उस बिल्ड के दौरान कोई डिपेंडेंसी बदल रही है या नहीं.

चलिए, यह भी देखते हैं कि Lightbuild में टेस्ट करने की सुविधा पहले से मौजूद है. इस लाइब्रेरी मॉड्यूल में मौजूद सभी टेस्ट भी चलाए जा सकते हैं. उदाहरण के लिए, सीधे कमांड लाइन से.

एक और चीज़ है जो मैं आपको दिखाना चाहता हूँ.

इसमें सहायता भी उपलब्ध है. इससे आपको उन सभी पैरामीटर और सब-कमांड की पूरी सूची मिलेगी जिनका इस्तेमाल किया जा सकता है.

यह आपके एजेंट के लिए उपलब्ध है. इसलिए, यह एजेंट के लिए आउटपुट है.

ठीक है।

हमने Lightbuild की मदद से बनाए गए कुछ आसान प्रोजेक्ट देख लिए हैं. अब मैं आपको एक ऐसा प्रोजेक्ट दिखाना चाहता हूं जो थोड़ा ज़्यादा मुश्किल है.

इसलिए, हमारे पास सैंपल के तौर पर मिला एक ऐप्लिकेशन है, जिसे Android टीम ने उपलब्ध कराया है. इसे Now in Android कहा जाता है. इसमें आपको Android की कुछ नई सुविधाएं मिलती हैं. साथ ही, उन्हें इस्तेमाल करने का तरीका और कुछ सबसे सही तरीके भी बताए जाते हैं.

यह एक ऐसा ऐप्लिकेशन है जिसे आसानी से इस्तेमाल किया जा सकता है.

मेरे हिसाब से, इसे 32 अलग-अलग मॉड्यूल में बांटा गया है.

GitHub में यह कुछ ऐसा दिखता है.

हालांकि, मैं Android Studio पर वापस जाऊंगा. यहां मैंने पहले ही अपने एजेंट का इस्तेमाल कर लिया है.

मैं Now in Android प्रोजेक्ट को Lightbuild में बदलने के लिए, Gemini Argon का इस्तेमाल कर रहा था.

इसलिए, यह कुछ ऐसा नहीं है जिसे हमने पब्लिश किया है. यह कुछ ऐसा है जो मैंने खुद किया है.

आपने देखा कि मेरे project.lightbuild.yaml में मौजूद इस प्रोजेक्ट में ये सभी अलग-अलग मॉड्यूल हैं. इसके बावजूद, यह बहुत तेज़ी से खुला और इस IDE के साथ बहुत तेज़ी से सिंक हुआ.

इस प्रोजेक्ट के बारे में एक और बात ध्यान देने वाली है. वह यह कि इसमें कुछ बिल्ड फ़्लेवर या खास बिल्ड कॉन्फ़िगरेशन का इस्तेमाल किया जा रहा था, ताकि डेमो बिल्ड और प्रॉड बिल्ड, दोनों को इस्तेमाल किया जा सके. इनमें से हर एक में, ऐप्लिकेशन को दिखाने का तरीका थोड़ा अलग था.

डेमो वर्शन में, पहले से मौजूद डेटा सोर्स का इस्तेमाल किया जाता है. वहीं, प्रॉड वर्शन में, नेटवर्क से डेटा फ़ेच किया जाता है.

Lightbuild की मदद से ऐसा करने के लिए, आपको ऐप्लिकेशन मॉड्यूल में जाना होगा और यह बताना होगा कि यह ऐप्लिकेशन मॉड्यूल, उदाहरण के लिए, डेमो ऐप्लिकेशन है. Lightbuild, अलग-अलग बिल्ड कॉन्फ़िगरेशन या ऐप्लिकेशन टाइप जैसी चीज़ों को इसी तरह मैनेज करता है.

इसलिए, यह सभी मुख्य कॉम्पोनेंट पर निर्भर करेगा. हालांकि, यह ऐप्लिकेशन के डेमो वर्शन के लिए खास सेटिंग भी लागू करेगा.

इस तरह, आपके पास कई ऐप्लिकेशन मॉड्यूल हो सकते हैं.

हर एक ट्रैक, आपके ऐप्लिकेशन के पैसे चुकाकर लिए जाने वाले या मुफ़्त वर्शन को दिखा सकता है.

साथ ही, आपको ऐप्लिकेशन मॉड्यूल के खाली शेल होने के फ़ायदे भी मिलते हैं. इसमें कोई कोड नहीं होता, जिससे यह काफ़ी तेज़ी से बनता है. इसके अलावा, जब भी आपकी लाइब्रेरी बदलती हैं, तो आपके ऐप्लिकेशन को फिर से बनाने के लिए, सिर्फ़ उन्हें फिर से कंपाइल करना पड़ता है.

चलिए, देखते हैं कि Now in Android ऐप्लिकेशन, Lightbuild की मदद से सही तरीके से बनाया जा रहा है या नहीं. इसमें 32 अलग-अलग मॉड्यूल शामिल हैं.

हां, यह रहा.

मैं यह भी बताना चाहता हूं कि इस तरह के एक्सपेरिमेंट से हमें यह भी पता चला कि Lightbuild, हर उस बिल्ड सुविधा के साथ काम नहीं करता जिसकी आपको ज़रूरत पड़ सकती है.

उदाहरण के लिए, Now in Android ऐप्लिकेशन, Hilt का इस्तेमाल करने के लिए Hilt प्लग-इन पर निर्भर करता है. फ़िलहाल, Lightbuild में इस तरह की सुविधा काम नहीं करती.

इसलिए, मेरे एजेंट ने इसका एक तरीका निकाला और प्रोजेक्ट के कोड में ज़्यादा बदलाव किए बिना, उसमें Hilt की सुविधा जोड़ दी.

जैसे, इन सभी मॉड्यूल में मौजूद सारा कोड, ओरिजनल रिपॉज़िटरी जैसा ही है.

हालांकि, Lightbuild को खुद आज़माते और डेमो करते समय, आपको यह बात ज़रूर ध्यान में रखनी चाहिए कि आपके मौजूदा प्रोजेक्ट की हर चीज़, बिल्ड कॉन्फ़िगरेशन के साथ काम नहीं करेगी.

इसलिए, Lightbuild अब भी झलक के तौर पर उपलब्ध है और Android Studio Canary में मौजूद है.

इसके साथ ही, मैं स्लाइड पर वापस जाना चाहूंगा.

हमने यहां जो भी बात की है उसे खत्म करने के लिए, Lightbuild को याद रखें. यह Android के लिए एक नया बिल्ड प्लैटफ़ॉर्म है. फ़िलहाल, यह एक्सपेरिमेंट के तौर पर उपलब्ध है.

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

इसमें बेहतरीन एआई एजेंट की सुविधा है. साथ ही, कमांड लाइन में वे सभी सुविधाएं मौजूद हैं जिन्हें आज आपने मुझे डेमो में दिखाया.

इसलिए, हम आपको इसे आज़माने और डेमो और एक्सपेरिमेंटल प्रोजेक्ट के लिए इस्तेमाल करने का न्योता देते हैं.

साथ ही, मैं, जुआन, और टीम के कुछ इंजीनियर, एजेंटिक एआई बूथ पर मौजूद रहेंगे. अगर आपका कोई सवाल है, तो हमसे पूछें.

इसलिए, आपका बहुत-बहुत धन्यवाद.