Lightbuild प्रोजेक्ट का स्ट्रक्चर

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

प्रोजेक्ट का लेआउट

डिफ़ॉल्ट Lightbuild प्रोजेक्ट टेंप्लेट में, ये बिल्ड फ़ाइलें और मॉड्यूल होते हैं:

MyApp/
├── project.lightbuild.yaml  # Project-wide settings
├── app/                     # App module
│   ├── lightbuild.yaml
│   └── resolved.deps
└── app-core/                # Library module
    ├── lightbuild.yaml
    ├── resolved.deps
    └── src/                 # The app's source code

प्रोजेक्ट में तीन बिल्ड कॉन्फ़िगरेशन फ़ाइलें होती हैं: रूट डायरेक्ट्री में एक project.lightbuild.yaml फ़ाइल और हर मॉड्यूल में एक lightbuild.yaml फ़ाइल. हर मॉड्यूल में एक resolved.deps फ़ाइल भी होती है. हर कॉन्फ़िगरेशन फ़ाइल में मौजूद सेटिंग के बारे में जानने के लिए, Lightbuild कॉन्फ़िगरेशन का रेफ़रंस देखें.

ऐप्लिकेशन मॉड्यूल

Lightbuild प्रोजेक्ट, आपके ऐप्लिकेशन के लिए ऐप्लिकेशन मॉड्यूल का इस्तेमाल करते हैं. इसे "ऐप शेल" भी कहा जाता है, क्योंकि यह बिना किसी सोर्स कोड के प्रोजेक्ट असेंबली को मैनेज करता है. आपकी सभी सुविधाएं और लॉजिक, अलग-अलग लाइब्रेरी मॉड्यूल में रहते हैं. साथ ही, ऐप्लिकेशन शेल, फ़ाइनल कॉन्फ़िगरेशन पर फ़ोकस करता है. जैसे, साइनिंग और ऑप्टिमाइज़ेशन.

ऐप्लिकेशन मॉड्यूल की lightbuild.yaml फ़ाइल, मॉड्यूल के type को application पर सेट करती है. साथ ही, यह बताती है कि फ़ाइनल ऐप्लिकेशन को कैसे बनाया जाता है. इसमें ये चीज़ें शामिल हैं:

• ऐप्लिकेशन की पहचान: इसका ऐप्लिकेशन आईडी, वर्शन कोड, और वर्शन का नाम
• ऐप्लिकेशन के लिए एसडीके की ज़रूरी शर्तें: इसके compileSdk, minSdk, और targetSdk वर्शन
• वे मॉड्यूल जिन पर ऐप्लिकेशन निर्भर करता है. इस उदाहरण में app-core

लाइब्रेरी मॉड्यूल

लाइब्रेरी मॉड्यूल में वह कोड होता है जिसे ऐप्लिकेशन मॉड्यूल इकट्ठा करता है. जैसे, आपके ऐप्लिकेशन की सुविधाएं, यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट, और कारोबारी नियम. नए प्रोजेक्ट टेंप्लेट में, app-core लाइब्रेरी मॉड्यूल में MainActivity.kt फ़ाइल होती है. इसमें उदाहरण के तौर पर कोड दिया होता है.

लाइब्रेरी मॉड्यूल की lightbuild.yaml फ़ाइल, मॉड्यूल की type वैल्यू को library पर सेट करती है. लाइब्रेरी मॉड्यूल, अपने compileSdk और minSdk वर्शन तय करते हैं. हालांकि, वे targetSdk सेटिंग के साथ काम नहीं करते. लाइब्रेरी मॉड्यूल की lightbuild.yaml फ़ाइल में, मॉड्यूल की डिपेंडेंसी, केएसपी प्रोसेसर, और टेस्ट भी शामिल होते हैं.

एक से ज़्यादा ऐप्लिकेशन मॉड्यूल

किसी प्रोजेक्ट में एक से ज़्यादा ऐप्लिकेशन मॉड्यूल हो सकते हैं. Lightbuild में, पारंपरिक तरीके से ऐप्लिकेशन टाइप और कस्टम बिल्ड टाइप का इस्तेमाल नहीं किया जा सकता. इसके बजाय, आपको अपने ऐप्लिकेशन के हर वर्शन के लिए एक अलग ऐप्लिकेशन मॉड्यूल बनाना होगा. जैसे, dev और prod वर्शन या free और paid वर्शन.

हर ऐप्लिकेशन मॉड्यूल, लाइब्रेरी मॉड्यूल पर निर्भर करता है. लाइब्रेरी मॉड्यूल, ऐप्लिकेशन मॉड्यूल के वर्शन के हिसाब से तय होते हैं. ऐप्लिकेशन मॉड्यूल, लाइब्रेरी मॉड्यूल शेयर कर सकते हैं. साथ ही, वे वर्शन के हिसाब से कोड और सेटिंग (जैसे, अलग-अलग डिपेंडेंसी इंजेक्शन (डीआई) मॉड्यूल) के लिए, अलग-अलग लाइब्रेरी मॉड्यूल पर निर्भर हो सकते हैं. इसके अलावा, वे उन सुविधाओं के लिए लाइब्रेरी मॉड्यूल को छोड़ सकते हैं जो किसी वर्शन में शामिल नहीं हैं.

उदाहरण के लिए, किसी ऐप्लिकेशन के बिना शुल्क वाले और पैसे चुकाकर लिए जाने वाले वर्शन वाले प्रोजेक्ट में ये मॉड्यूल हो सकते हैं:

MyApp/
├── project.lightbuild.yaml
├── app-free/   # App module for the free version
├── app-paid/   # App module for the paid version
├── core/       # Library module that both versions use
├── di-free/    # DI module for the free version
├── di-paid/    # DI module for the paid version
└── premium/    # Library module for paid-only features

पैसे चुकाकर लिए जाने वाले वर्शन की app-paid/lightbuild.yaml फ़ाइल, पैसे चुकाकर लिए जाने वाले वर्शन के सभी मॉड्यूल पर निर्भर करती है:

android:
  applicationId: com.example.myapp.paid
  dependencies:
    module:
      - //core
      - //di-paid
      - //premium

मुफ़्त वर्शन की app-free/lightbuild.yaml फ़ाइल, शेयर किए गए core मॉड्यूल और उसके डीआई मॉड्यूल पर निर्भर करती है. साथ ही, premium मॉड्यूल को छोड़ देती है:

android:
  applicationId: com.example.myapp.free
  dependencies:
    module:
      - //core
      - //di-free

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

lightbuild build app-free

हल की गई डिपेंडेंसी

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

अपने प्रोजेक्ट की lightbuild.yaml फ़ाइलों के साथ-साथ, वर्शन कंट्रोल के लिए अपनी resolved.deps फ़ाइलों में भी चेक इन करें.

अपनी डिपेंडेंसी लॉक करने के लिए, उदाहरण के लिए, सीआई बिल्ड में, lightbuild resolve या lightbuild test में --locked-dependencies फ़्लैग जोड़ें. इस फ़्लैग का इस्तेमाल करने पर, अगर कोई resolved.deps फ़ाइल, मॉड्यूल की डिपेंडेंसी से मेल नहीं खाती है, तो फ़ाइल को अपडेट करने के बजाय कमांड काम नहीं करता:

lightbuild resolve --locked-dependencies