ساختار پروژه 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 یک پیمانه کتابخانه همچنین وابستگی‌های پیمانه، پردازنده‌های KSP، و آزمایش‌ها را اعلام می‌کند.

چندین پیمانه برنامه

پروژه می‌تواند بیش‌از یک واحد برنامه داشته باشد. ‫Lightbuild از نسخه‌های ویژه محصول و انواع ساخت سفارشی به معنای سنتی پشتیبانی نمی‌کند. درعوض، برای هر نسخه از برنامه‌تان، مثلاً نسخه‌های dev و prod یا نسخه‌های free و paid، یک ماژول برنامه جداگانه ایجاد می‌کنید.

هر واحد برنامه به واحدهای کتابخانه‌ای که نسخه‌اش نیاز دارد وابسته است. مدول‌های برنامه می‌توانند مدول‌های کتابخانه را هم‌رسانی کنند، برای کد و تنظیمات مختص نسخه به مدول‌های کتابخانه مختلف وابسته باشند (مثل مدول‌های تزریق وابستگی (DI) جداگانه)، و مدول‌های کتابخانه را برای ویژگی‌هایی که نسخه شامل نمی‌شود کنار بگذارند.

برای مثال، پروژه‌ای با نسخه‌های رایگان و پولی یک برنامه ممکن است دارای پیمانه‌های زیر باشد:

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 و ماژول DI خودش بستگی دارد و ماژول premium را کنار می‌گذارد:

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

هر پیمانه برنامه تنظیمات خودش را دارد، مثل شناسه برنامه و امضای نسخه پخش، بنابراین می‌توانید هر نسخه را به‌طور جداگانه بسازید، نصب کنید، و منتشر کنید. برای ساختن نسخه‌ای خاص، هنگام اجرای فرمان build، واحد برنامه آن را مشخص کنید. برای مثال:

lightbuild build app-free

وابستگی‌های حل‌وفصل‌شده

هر پیمانه در پروژه Lightbuild شامل یک فایل resolved.deps است که همه وابستگی‌های حل‌شده پیمانه، ازجمله وابستگی‌های انتقالی، را ثبت می‌کند. Lightbuild این فایل را به‌طور خودکار تولید می‌کند تا نیازی نباشد هربار که پروژه را باز می‌کنید یا می‌سازید، وابستگی‌ها را به‌طور پویا حل کند. نباید این فایل را به‌صورت دستی ویرایش کنید.

فایل‌های resolved.deps را به‌همراه فایل‌های lightbuild.yaml پروژه در کنترل نسخه ثبت کنید.

برای قفل کردن وابستگی‌هایتان، مثلاً در ساخت CI، پرچم --locked-dependencies را به lightbuild resolve یا lightbuild test اضافه کنید. با این پرچم، اگر فایل resolved.deps با وابستگی‌های واحد مطابقت نداشته باشد، فرمان به‌جای به‌روزرسانی فایل، ناموفق می‌شود:

lightbuild resolve --locked-dependencies