وابستگی متقابل ابزار و کتابخانه

وابستگی های ساخت اجزای خارجی هستند که برای ساخت موفقیت آمیز پروژه شما مورد نیاز هستند. یک ساخت می‌تواند به کتابخانه‌ها، پلاگین‌ها، پروژه‌های فرعی ، Android SDK، ابزارهایی مانند کامپایلرهای Kotlin و Java ، محیط‌های توسعه مانند Android Studio و خود Gradle بستگی داشته باشد.

هر وابستگی خود می تواند به وابستگی های دیگری نیاز داشته باشد. ما این وابستگی‌های گذرا را می‌نامیم و می‌توانیم به سرعت وابستگی‌های کلی مورد استفاده برنامه شما را افزایش دهیم. وقتی می‌خواهید یک وابستگی را ارتقا دهید، چه کتابخانه، ابزار یا Android SDK، آن ارتقا می‌تواند به صورت آبشاری انجام شود و بسیاری از وابستگی‌های دیگر را ارتقا دهد.

اغلب، این کار باعث درد نمی شود، زیرا بسیاری از کتابخانه ها از طرحی به نام Semantic Versioning پیروی می کنند. این کتابخانه ها انواع تغییراتی را که ایجاد می کنند برای ارائه سازگاری با نسخه های پایین تر خود محدود می کنند.

نسخه‌سازی معنایی از قالب major.minor.patch پیروی می‌کند. برای مثال در نسخه شماره 4.8.3، 4 نسخه major ، 8 نسخه minor و 3 شماره patch است. وقتی بخش major تغییر می کند، کتابخانه ممکن است تغییرات قطعی در API یا رفتار داشته باشد. این می تواند بر رفتار ساخت یا برنامه شما تأثیر بگذارد.

هنگامی که بخش‌های minor (ویژگی‌های جدید) یا patch (رفع اشکال) تغییر می‌کنند، توسعه‌دهندگان کتابخانه به شما می‌گویند که کتابخانه همچنان سازگار است و نباید بر برنامه شما تأثیر بگذارد.

مهم است که مراقب چنین تغییراتی باشید و چندین ابزار ارتقاء Dependency می توانند به شما کمک کنند.

روابط در ساخت شما

بیلدهای اندروید شامل روابط بین:

• کد منبع - کد و منابعی که بر آنها کنترل دارید
• وابستگی‌های کتابخانه - کتابخانه‌های خارجی یا ماژول‌هایی که پروژه و پروژه‌های فرعی شما هنگام ساختن شامل می‌شوند
• ابزارها - کامپایلرها، افزونه ها و SDKهایی که منبع شما را به یک برنامه کاربردی یا کتابخانه ترجمه می کنند

کد منبع

کد منبع شما Kotlin یا کد جاوا است که در برنامه یا کتابخانه خود می نویسید. (برای جزئیات بیشتر در مورد استفاده از C++، به Android NDK مراجعه کنید.)

کد منبع به کتابخانه ها (از جمله کتابخانه های زمان اجرا Kotlin و جاوا) و Android SDK بستگی دارد و به کامپایلر Kotlin یا جاوا مربوطه آن نیاز دارد.

برخی از کدهای منبع حاوی حاشیه نویسی هستند که نیاز به پردازش اضافی دارند. برای مثال، اگر در حال نوشتن کد Jetpack Compose هستید، حاشیه‌نویسی‌هایی مانند @Composable را اضافه می‌کنید که باید توسط افزونه Compose Kotlin کامپایلر پردازش شوند. سایر حاشیه نویسی ها ممکن است توسط یک پردازنده نماد Kotlin (KSP) یا ابزارهای پردازش حاشیه نویسی جداگانه پردازش شوند.

وابستگی های کتابخانه

کتابخانه ها حاوی کد بایت هستند که به عنوان بخشی از برنامه شما وارد شده است. این می تواند یک جاوا JAR، کتابخانه اندروید (AAR) یا یک پروژه فرعی در ساخت شما باشد. بسیاری از کتابخانه‌ها از Semantic Versioning پیروی می‌کنند، که می‌تواند به شما کمک کند در صورت ارتقاء سازگاری (یا عدم سازگاری) آنها را درک کنید.

کتابخانه‌ها ممکن است برای استفاده مجدد به کتابخانه‌های دیگری وابسته باشند که به آن وابستگی گذرا می‌گویند. این امر وابستگی هایی را که باید به صراحت مدیریت کنید کاهش می دهد. شما وابستگی هایی را که مستقیماً استفاده می کنید مشخص می کنید و Gradle آنها را همراه با آن وابستگی های گذرا می کشد. توجه داشته باشید که وقتی وابستگی های مستقیم خود را ارتقا می دهید، ممکن است وابستگی های گذرا را ارتقا دهند.

گاهی اوقات ممکن است یک کتابخانه به حداقل نسخه های Android SDK در زمان اجرا ( minSdk ) یا زمان کامپایل ( compileSdk ) نیاز داشته باشد. این زمانی ضروری است که یک کتابخانه از توابع موجود در Android SDK یا APIهای JDK ارائه شده آن استفاده می کند. minSdk موثر برنامه شما بالاترین minSdk درخواست شده توسط برنامه شما و تمام وابستگی های مستقیم و انتقالی کتابخانه آن است.

استفاده از برخی از کتابخانه ها ممکن است نیاز به استفاده از یک پلاگین Gradle خاص داشته باشد. این پلاگین های کمکی اغلب پردازنده های نماد Kotlin یا سایر پردازشگرهای حاشیه نویسی را نصب می کنند که کد تولید می کنند یا کامپایل منبع شما را تغییر می دهند تا از استفاده شما از ویژگی های کتابخانه پشتیبانی کند. به عنوان مثال، اتاق Jetpack شامل حاشیه نویسی و KSP است که آنها را به کد تولید شده برای بازیابی و اصلاح داده ها در یک پایگاه داده تبدیل می کند. Jetpack Compose به افزونه کامپایلر Compose نیاز دارد تا توابع حاشیه نویسی را برای مدیریت نحوه و زمان اجرای مجدد آن تابع تغییر دهد.

ابزار

محدوده های گرید

Gradle وابستگی های کتابخانه را در حوزه های مختلف گروه بندی می کند (که در Gradle API پیکربندی نامیده می شود)، به شما امکان می دهد مجموعه های مختلفی از وابستگی های کتابخانه را برای استفاده در بخش های مختلف ساخت خود مشخص کنید. برای مثال، احتمالاً نمی‌خواهید کتابخانه‌های آزمایشی مانند JUnit را در برنامه یا کتابخانه منتشر شده خود بگنجانید، اما هنگام ساخت و اجرای آزمون‌های واحد خود، آنها را می‌خواهید. شما همچنین از scope ها برای اضافه کردن نمادها یا پردازشگرهای حاشیه نویسی برای تجزیه و تحلیل کد خود استفاده می کنید.

برای مثال، AGP implementation و دامنه‌های api را تعریف می‌کند، روش شما برای تعیین اینکه آیا یک وابستگی باید در معرض کاربران پروژه فرعی شما قرار گیرد یا خیر. برای توصیف این و سایر حوزه‌های مورد استفاده در ساخت اندروید به پیکربندی وابستگی‌ها مراجعه کنید.

وابستگی های کتابخانه را در بلوک dependencies فایل های ساخت خود اضافه کنید، یا به صورت group:artifact:version strings:

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

یا در کاتالوگ نسخه :

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

و متغیرهای تولید شده را در فایل های ساخت خود مشخص کنید:

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}