از زمان شروع استفاده از اندروید استدیو، گریدل به مکان اصلی برای مدیریت بسیاری از موارد مانند وابستگی‌ها، تنظیمات داده، flavorها و غیره تبدیل شده است. با گذشت زمان حفظ وابستگی در بین پروژه‌های چند ماژولی تبدیل به یک چالش شده است. بریم ببینیم که چگونه تکامل مدیریت وابستگی در پروژه‌های چند ماژولی اتفاق افتاد و چه مشکلاتی در پیش روی ما وجود دارد. لطفا برای درک بهتر مطلب قبلی در مورد Kotlin DSL را مطالعه کنید.
قسمت اصلی این مطلب درباره این است که چگونه می‌توانیم با استفاده از buildSrc و کاتلین DSL به مدیریت بهتر وابستگی دست پیدا کنیم.
<h۲ dir="RTL">مسئله اصلی</h۲>
اگر می‌خواهید از فرایند تکامل صرف نظر کنید به بخش استفاده از buildSrc با کاتلین DSL بروید و در غیر این صورت به خواندن این بخش ادامه دهید.
برای درک مشکل بیایید یک برنامه چند ماژولی را درنظر بگیریم. تعیین دستی نسخه‌ها همراه با وابستگی در چندین ماژول اولین رویکرد ماست، که چیزی شبیه به کد زیر است.
در فایل build.gradle ماژول اول، وابستگی‌ها را تعیین می‌کنیم:
در فایل build.gradle ماژول دوم، همان وابستگی‌ها را اضافه می‌کنیم:
همانطور که ما در حال تعریف نسخه‌های وابستگی‌ها در هر فایل build.gradle هستیم، اگر به درستی بروز نشوند مشکلاتی از جمله تناقض نسخه‌ها به وجود می‌آید. مدیریت نسخه‌های بروز شده وابستگی‌ها و تنظیمات داده بسیار دشوار است. هر زمان که در وابستگی تغییراتی ایجاد کنیم اگر ماژول‌های بیشتری داشته باشیم روند دستی بیشتری نیز داریم، که به هر ماژول برویم و بررسی کنیم که آیا برای وابستگی بروزرسانی وجود دارد یا خیر.
<h۳ dir="RTL">پیکربندی Propertieهای پروژه</h۳>
با استفاده از ویژگی Gradle Extra، می‌توانیم Propertyهای پروژه را تنظیم کنیم. برای استفاده از این روش، ما داده‌های پیکربندی و نسخه‌های وابستگی را در build.gradle سطح پروژه یا سطح ریشه تعریم می‌کنیم.
با این کار می‌توان از این propertyها در همه ماژول‌ها استفاده کرد
این مشکل بروزرسانی نسخه‌های وابستگی را، با نگه‌داری همه آن‌ها در یک مکان حل می‌کند. با این حال هیچ پشتیبانی برای بررسی نسخه‌ها یا پیشنهادات خودکار وجود ندارد. بنابراین بیایید به قسمت اصلی که استفاده از buildSrc با کاتلین DSL است برویم.
<h۲ dir="RTL">buildSrc چیست؟</h۲>
buildSrc یک دایرکتوری در سطح ریشه پروژه است که شامل اطلاعات ساخت است. ما می‌توانیم از این دایرکتوری برای فعال کردن کاتلین DSL و نوشتن منطق مربوط به پیکربندی سفارشی استفاده کرد و آن‌ها را در سراسر پروژه به اشتراک بگذاریم. این یکی از روش‌های محبوب در روزهای اخیر به دلیل قابل تست بودن آن است.
نکته: دایرکتوری buildSrc به عنوان یک included build تلقی می‌شود. با پیدا شدن دایرکتوری، گریدل به طور خودکار این کد را کامپایل و تست می‌کند و آن را در مسیر کلاس اسکریپت شما قرار می‌دهد. برای ساخت چند ماژول فقط یک دایرکتوری buildSrc وجود دارد که باید در ریشه پروژه قرار بگیرد. buildSrc باید به افزونه‌های اسکریپتی ترجیح داده شود زیرا نگه‌داری، ریکاوری و تست کد آسان‌تر است. برای کسب اطلاعات بیشتر می‌توانید به مستندات گریدل مراجعه کنید.
اکنون بیاید که ببینیم چگونه می‌توان یک دایرکتوری buildSrc ایجاد کنیم.
با راست کلیک کردن بر روی ریشه پروژه به -> New -> Directory بروید و buildSrc را ایجاد کنید
<h۲ dir="RTL">فعال کردن کاتلین DSL در buildSrc</h۲>
همانطور که کاتلین DSL از از زبان اصلی آن یعنی کاتلین اقتباس شده است، بیشتر سینتکس آن مشابه است. ابتدا برای این کار یک فایل خالی build.gradle.kts ایجاد کنید و سپس گزینه kotlin-dsl را در buildSrc فعال کنید.
برای اتمام تنظیمات بر روی sync کلیک کنید. پس از اتمام کار، اکنون می‌توانیم اسکریپت‌های کاتلین DSL خود را برای منطق ساخت سفارشی ایجاد کنیم. اکنون بیایید داده‌های پیکربندی ساخت و تنظیمات مدیریت وابستگی را انجام دهیم.
<h۳ dir="RTL">قدم اول</h۳>
یک دایرکتوری src در ساختار دایرکتوری buildSrc ایجاد کنید
<h۳ dir="RTL">قدم دوم</h۳>
در این دایرکتوری می‌توانیم فایل‌های کاتلین خود را ایجاد کنیم. اکنون یک object class به نام Versions.kt ایجاد می‌کنیم که همه نسخه‌های مربوط به پلاگین‌ها، وابستگی‌ها، و غیره را در آن تعریف کنیم.
<h۳ dir="RTL">قدم سوم</h۳>
حال یک فایل جدید به نام Dependencies.kt برای تعریف تمام افزونه‌ها، وابستگی و ... ایجاد می‌کنیم، که محتوای آن همانند زیر است.
همانطور که در تصویر زیر نشان داده شده است هنگام ایجاد یک فایل، می‌توانیم پیشنهادات خودکار را در Versions.kt داشته باشیم. بنابراین می‌توانیم برای بررسی مقادیر خاص به راحتی بین فایل‌ها حرکت کنیم.
<h۳ dir="RTL">قدم چهارم</h۳>
ما همچنین می‌توانیم یک فایل ConfigData.kt برای هرگونه اطلاعات مربوط به پیکربندی ساخت ایجاد کنیم.
<h۳ dir="RTL">قدم پنجم</h۳>
سرانجام از داده‌های تعریف شده در کلاس‌های فوق، همانند زیر در build.gradle.kt سطح ماژول استفاده می‌کنیم.
ساختار نهایی دایرکتوری چیزی شبیه زیر است.
buildSrc
├── src
│ └── main
│ ─└── kotlin
│ ──└── Dependencies.kt
├── build.gradle.ktsمی‌توانید از مخزن android sample kotlin dsl در گیت هاب برای نمونه کد استفاده کنید.
نکته: اگرچه می‌توانیم این فایل‌های Versions، Dependencies و غیره را در یک کلاس واحد نیز قرار دهیم، اما بهتر است که کلاس‌ها جدا شود تا کد تمیز باشد.
<h۳ dir="RTL">خلاصه</h۳>
buildSrc + Kotlin DSL بهترین گزینه برای مدیریت وابستگی است. از آنجا که این‌ها در سطح کلاس تعریف شده‌اند به راحتی قابل تست هستند. پشتیبانی از پیشنهاد خودکار و code navigation در صرفه جویی در وقت کمک می‌کند. برای هر قسمت کلاس‌های جداگانه‌ای دارید. این روش برای استفاده مجدد بهتر است و نگه‌داری آن می‌تواند آسان‌تر باشد.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید