تبدیل اپلیکیشن اندروید به Jetpack – به زبان ساده

گوگل اخیراً اقدام به برندسازی مجدد برای «کتابخانه‌های پشتیبانی» (Support Libraries) اندروید کرده و آن‌ها را Jetpack نامیده است. توسعه‌دهندگان باید به این منظور تغییراتی را در اپلیکیشن‌های خود ایجاد کنند. در این مقاله به توضیح ماهیت جت‌پک و شیوه آغاز تبدیل پروژه برای استفاده از کامپوننت‌های جدید می‌پردازیم.

جت‌پک چیست؟

Android Jetpack به مجموعه‌ای از کتابخانه‌ها، ابزارها و راهنمایی‌های مربوط به معماری گفته می‌شود که به منظور تسهیل ساخت اپلیکیشن‌های اندرویدی طراحی شده‌اند. هدف از ارائه این مجموعه ایجاد یک کد زیرساخت مشترک است تا توسعه‌دهندگان بتوانند روی نوشتن چیزهایی که اپلیکیشن‌شان را منحصر به فرد می‌سازد متمرکز شوند.

این مجموعه تلاش زیادی در جهت بهبود تجربه توسعه‌دهنده و جمع‌آوری ابزارها و فریمورک‌های مفید در یک قالب واحد صورت داده است. آلن ویورته (Alan Viverette) از اعضای تیم فریمورک اندروید این وضعیت را به صورت زیر خلاصه کرده است:

جت‌پک یک تلاش گسترده برای بهبود تجربه توسعه‌دهنده است؛ اما AndroidX یک بنیاد فنی شکل می‌دهد؛ گرچه از نقطه نظر فنی ما همچنان با کتابخانه‌هایی که در بخش‌های Support Library و Architecture Components شاهد بودیم، سر و کار داریم.

چرا جت‌پک ایجاد شد؟

شاید از خود بپرسید اگر همه این ابزارها از قبل وجود داشتند، پس چرا گوگل این همه خود و توسعه‌دهندگان را به زحمت انداخته است؟

برای پاسخ به سؤال فوق باید به فهرست مزیت‌های جت‌پک اشاره کنیم:

• ایجاد یک فضای نام سازگار (*.androidx) برای کتابخانه‌های پشتیبانی
• پشتیبانی بهتر از نسخه‌بندی معنایی برای آنچه ساخته می‌شود (که از 1.0.0 آغاز می‌شود)
• ایجاد یک چتر مشترک برای توسعه همه کامپوننت‌های پشتیبانی زیر نام واحد

همچنین لازم به ذکر است که نسخه کنونی از (AppCompat(v28.x، نسخه نهایی محسوب می‌شود. نسخه‌های بعدی این کد صرفاً به صورت جت‌پک خواهند بود. بدین ترتیب توسعه‌دهندگان باید از این موضوع آگاهی داشته و هر چه سریع‌تر به جت‌پک سوئیچ کنند.

ماهیت واقعی Jetpack چیست؟

پاسخ کوتاه به سؤال فوق این است که جت‌پک همه چیز است. در واقع جت‌پک مجموعه‌ای از کتابخانه‌های فراوان موجود است که اغلب توسعه‌دهنده‌ها از آن‌ها استفاده می‌کنند (مانند AppCompat, Permissions, Notifications یا Transitions) و همچنین کامپوننت‌های معماری جدیدتر که در سال‌های اخیر معرفی شده‌اند (مانند LiveData, Room, WorkManager یا ViewModel) را نیز شامل می‌شود.

فیلم آموزش جت پک کامپوز Jetpack Compose برای ساخت رابط کاربری اندروید – مقدماتی در فرادرس

کلیک کنید

توسعه‌دهندگان می‌توانند همان انتظاراتی را که از AppCompat داشتند از جت‌پک نیز داشته باشند که شامل سازگاری با نسخه‌های قبلی و چرخه‌های انتشار در ارتباط با به‌روزرسانی‌های سیستم عامل است.

آیا باید همین الان ارتقا بدهیم و آیا می‌توان صرفاً بخشی از کد را به‌روزرسانی کرد؟

الزامی برای به‌روزرسانی سریع وجود ندارد، اما باید در آینده نزدیک همه توسعه‌دهندگان از جت‌پک استفاده کنند. نسخه کنونی (AppCompat (v28.x دقیقاً همان نسخه (AndroidX (v1.x است. در واقع کتابخانه‌های AppCompat با تغییر دادن مختصات maven و نام‌های بسته کدبیس AndroidX از سوی ماشین تولید شده‌اند. برای نمونه مختصات و بسته‌های قدیمی به صورت زیر بودند:

implementation “com.android.support:appcompat-v7:28.0.0"

import android.support.v4.widget.DrawerLayout

و اینک به صورت زیر هستند:

implementation 'androidx.appcompat:appcompat:1.0.2'

import androidx.drawerlayout.widget.DrawerLayout

لازم به ذکر است که نمی‌توان AppCompat و Jetpack را در یک پروژه با هم استفاده کرد. اگر می‌خواهید به جت‌پک ارتقا دهید، باید همه چیز را در کد خود به‌روزرسانی کنید.

گام اول – ارتقای اپلیکیشن به جدیدترین کتابخانه‌های پشتیبانی

زمانی که برای ارتقا به Jetpack آماده بودید، ابتدا باید مطمئن شوید که اپلیکیشنتان از جدیدترین نسخه از Gradle و AppCompat استفاده می‌کند. بدین ترتیب این اطمینان حاصل می‌شود که refactor تنها نام‌های بسته را تغییر می‌دهد و مشکلات بزرگ‌تری که با به‌روزرسانی‌های کتابخانه مرتبط هستند رخ نمی‌دهند.

به‌روزرسانی پروژه بسیار مهم است و هر مشکلی مانند وابستگی منسوخ به یک نسخه قدمی از کتابخانه که با حرکت در این مسیر ممکن است رخ دهد را افشا می‌کند. اگر نمی‌توانید به جدیدترین نسخه‌ها به‌روزرسانی کنید، باید مشکلاتی را که وجود دارد، پیش از ادامه مراحل رفع کنید. حتماً سری به این آدرس (+) بزنید و اطلاعات وابستگی جدیدترین نسخه از Gradle را بررسی کنید.

استفاده از ابزار Refactor برای به‌روزرسانی پروژه

زمانی که پروژه خود را ارتقا دادید، می‌توانید از ابزار Refactor در اندروید استودیو برای بازسازی پروژه خود استفاده کنید. این ابزار را می‌توانید از مسیر Refactor\Refactor to AndroidX مانند تصویر زیر اجرا کنید:

این ابزار اپلیکیشن شما را بررسی می‌کند و پیش‌نمایشی از تغییرات ضروری را نشان می‌دهد:

اگر مشکلی با این تغییرات ندارید، می‌توانید دکمه «Do Refactor» را انتخاب کنید تا ابزار تبدیل، 3 تغییر زیر را روی اپلیکیشن شما انجام دهد:

به‌روزرسانی ایمپورت‌ها برای نمایش نام‌های بسته‌های جدید

به‌روزرسانی مختصات Gradle برای وابستگی‌های شما

افزون 2 فلگ به فایل gradle.properties. فلگ اول به افزونه اندروید اعلام می‌کند که از بسته‌های AndroidX به جای AppCompat استفاده کند و فلگ دوم باعث فعال‌سازی Jetifier می‌شود. Jetifier ابزاری است که به استفاده از کتابخانه‌های بیرونی کمک می‌کند و در بخش بعدی در مورد آن توضیح بیشتری ارائه می‌کنیم.

android.useAndroidX=true

android.enableJetifier=true

به طور کلی این تغییرات را می‌توان در 3 زمینه توصیف کرد؛ اما تغییرات دیگری نیز وجود دارد که ابزار بازسازی اجرا می‌کند. این ابزار کدی که مسئول Kotlin Nullability است را به کد شما اضافه می‌کند و همچنین برخی تغییرات دیگر نیز وجود دارند. بهتر است همه تغییراتی که این ابزار در کد ایجاد می‌کند را به دقت مورد نظارت قرار دهید و مطمئن شوید که همه این تغییرات اشکالی در کار اپلیکیشن شما ایجاد نخواهند کرد.

Jetifier

ابزار Refactor اندروید استودیو تنها تغییراتی را در کد منبع پروژه شما ایجاد می‌کند. این ابزار نمی‌تواند تغییراتی در کتابخانه‌ها یا وابستگی‌های بیرونی ایجاد کند. به همین دلیل گوگل ابزاری به نام Jetifier ایجاد کرده است که طوری طراحی شده است تا «وابستگی‌های ترایا» (Transitive dependency) را در زمان build به کتابخانه‌های AndroidX تبدیل کند. اگر این ابزار وجود نمی‌داشت، می بایت منتظر می‌ماندیم تا همه کتابخانه‌های شخص ثالث به‌روزرسانی ارائه می‌کردند تا بتوانیم از AndroidX استفاده کنیم.

به جز این که می‌دانیم این ابزار با استفاده از فلگ gradle کار می‌کند اطلاعات چندانی در مورد آن وجود ندارد، زیرا به طور خودکار عمل می‌کند و به هیچ پیکربندی نیاز ندارد. گوگل اخیراً اعلام کرده است که گزینه مستقلی برای اجرای running ارائه کرده است. حتی می‌توان آن را در حالت معکوس (reverse mode) نیز اجرا کرد که موجب de-jetify شدن کد می‌شود. این حالت برای دیباگ کردن بسیار مفید است.

مشکلاتی که ممکن است با آن‌ها مواجه شوید

• ممکن است با یک کتابخانه شخص ثالث مواجه شوید که لازم است به‌روزرسانی شود. برای نمونه برخی افراد متوجه شده‌اند که نسخه کنونی SqlDelight به یک نسخه قدیمی از کتابخانه Room persistence نیاز دارد. بدین ترتیب تقاضای یک به‌روزرسانی کرده‌اند و Square نسخه به‌روز شده کتابخانه را عرضه کرده است. اگر با چنین مشکل‌هایی مواجه شدید، هر چه زودتر از توسعه‌دهنده تقاضای به‌روزرسانی بکنید، بهتر است. جدیدترین نسخه از Room یعنی نسخه 2.1 هم اینک نیازمند AndroidX است که احتمالاً باعث خواهد شد بسیاری از افراد این ارتقا را انجام دهند. در زمان نگارش این مقاله Facebook SDK همچنان به‌روز نشده است و این مسئله احتمالاً برای افراد زیادی موجب بروز مشکل خواهد شد.
• به‌روزرسانی پروژه به آخرین نسخه از AppCompat ممکن است چندان ساده نباشد. در این فرایند ممکن است مشکلاتی در کد شما وجود داشته باشد که از باگ‌های قبلی بر جای مانده‌اند و یا این ارتقا نیازمند برخی بازنویسی‌های عمده در کد باشد. برای این مسائل باید از پیش برنامه‌ریزی کرده باشید.
• فایل‌های منبع از سوی Jetifier تغییر نمی‌یابند و از این رو ممکن است هنگام استفاده از مستندات دچار سردرگمی شوید.
• نمی‌توان بر اساس ماژول Jetify کرد و از این رو این عمل یک کار «همه یا هیچ» روی کد شما محسوب می‌شود. این فرایند احتمالاً موجب توقف فرایند توسعه مداوم پروژه شود و یا این که مشکلاتی در زمان ادغام کدهای توسعه ایجاد کند.
• ابزار نگاشت می‌تواند وابستگی‌های آلفا (alpha) برای نمونه ConstraintLayout alpha را در کد شما درج کند.
• اندروید استودیو در مورد Jetifier اطلاع دارد و خطاهایی را در این خصوص نشان می‌دهد. اجرای یک عملیات «Invalidate Cache and Restart» می‌تواند این مشکل را رفع کند.
• Jetifier کد تولید شده را تغییر نمی‌دهد و بنابراین در این خصوص به کار بیشتری نیاز هست.
• برخی از نام‌های جایگزین به درستی نگاشت نمی‌شوند (که اکثر آن‌ها به طور عمده در کتابخانه design قرار دارند). ابزار refactor در این موارد عمل نخواهد کرد و کد شما کامپایل نمی‌شود. برای حل این مشکل باید به طور دستی ایمپورت‌ها را بررسی کنید. خوشبختانه این مشکلات در طی زمان به کمترین مقدار رسیده‌اند، چون این ابزار به بلوغ رسیده و باگ‌ها در ابزار Reactor اصلاح می‌شوند.

نکته مفید: قاعده نام‌گذاری استاندارد در Jetpack استفاده از یک کپی از نام بسته در مختصات Mavem است. در جت‌پک، بسته همواره با groupid یکسان است.

برای نمونه اگر بدانید که نام بسته «androidx.webkit» بوده است، در این صورت این وابستگی به «androidx.webkit:webkit:VERSION» نگاشت خواهد شد.

سخن پایانی

از قبل در مورد تغییرات مورد نیاز ابزار مهاجرت به Jetpack کسب اطلاع کنید. دشوارترین بخش این ارتقا احتمالاً به‌روزرسانی پروژه برای استفاده از جدیدترین وابستگی‌ها است. ممکن است برخی کتابخانه‌های شخص ثالث هنوز به‌روزرسانی نشده باشند. مهم است که این موارد را شناسایی کرده و از توسعه‌دهنده تقاضا کنید که آن‌ها را به‌روزرسانی کند.

فیلم مجموعه آموزش برنامه نویسی اندروید – مقدماتی تا پیشرفته در فرادرس

کلیک کنید

اگر این مطلب برایتان مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:

• مجموعه آموزش‌های برنامه نویسی اندروید
• گنجینه برنامه نویسی اندروید (Android)
• مجموعه آموزش‌های برنامه‌نویسی
• ۵ گام ضروری برای یادگیری برنامه‌نویسی اندروید — راهنمای جامع
• آموزش برنامه نویسی اندروید (Android) – مقدماتی
• گنجینه آموزش های پروژه محور برنامه نویسی اندروید (Android)
• آموزش برنامه نویسی اندروید (Android) – تکمیلی

==