نوشته های لیلا صدیقی

مدیریت Dependencyهای اندروید به سبک تر و تمیز

لیلا صدیقی — Tue, 16 Apr 2024 22:31:51 +0330

احتمالا توی ورژن آخر اندروید استودیو دیدین که وقتی یه پروژه جدید ایجاد میکنید، Dependencyها دیگه به سبک قدیمی و شلوغ و stringهای پشت سر هم نیستن. بلکه خیلی تر و تمیز و مشابه تصویر پایین هستند.build.gradleو اگه روی هرکدوم از این ها که کلیک کنید وارد فایلی میشید که همه dependencyها در اونجا قرارداره به اسم libs.versions.toml. به کمک این فایل میتونیم همه dependencyهارو در یک قسمت هندل کنیم و همه ماژول های داخل پروژه به این فایل ارجاع داده میشن.اسم این روش version catalog هست که توی این مقاله قراره راجع به اون بیشتر بدونیم.libs.versions.tomlمزایای این روششاید اگه قبلا برای مدیریت dependencyها از build.src، که یکی از روش هایی هست که قبلا ازش برای مدیریت dependency استفاده میشد، استفاده کرده باشین براتون سوال باشه که خب اصلا این چه امکانات اضافه ای به ما میده که قبلی رو رهاکنیم و بیایم سراغ این یکی!اگه به تصویر بالا دقت کنین زیر یه سری ورژن ها علامت زرد رنگ warning وجود داره که با بردن موستون روی اونها میبینید که ورژن جدیدی از اون در دسترس هست و میتونید اونهارو به راحتی update کنید. علاوه بر این اگه پروژه تون مولتی ماژول باشه، توی روش build.src اگه dependency یکی از ماژولها رو آپدیت کنید همه ماژولها compile میشن. اما با این روش فقط اونهایی compile میشن که دارن ازش استفاده میکنن و سرعت بیلدتون بیشتر میشه که این خودش به تنهایی مزیت بزرگی محسوب میشه!حالا چجوری باید از این روش استفاده کنیماگه پروژه ای دارین که libs.versions.toml رو نداره در مرحله اول کافیه اندروید استودیو رو درحالت project قراربدین و بعد داخل gradle یه فایل بسازین و اسمش رو libs.versions.toml قرار بدین.تا اینجا یه فایل خالی دارین که باید داخل اون dependencyهای مدنظرتون رو اضافه کنید. پس اول ببینیم فرمت این فایل چجوری هست.این فایل قسمت های مختلف داره و میتونین با [] از هم تفکیکشون کنید.عکس دوم همین مقاله رو ببینید که فایل تصویر، سه قسمت versions, libraries, plugins داره. توی قسمت versions باید ورژن هر dependency رو بذارید، توی libraries خود dependencyها قرارمیگیره و قسمت plugins هم که مخصوص قرار دادن پلاگین هایی هست که تو پروژه بهش نیاز دارین.برای اینکه dependencyهارو به سبک اندروید استودیو قراربدیم کافیه با فرمت زیر بنویسیم:dependency-name = { group = "dependency.groupId", name = "dependency.name", version.ref = "dependency.version" }قسمت dependency.groupId میشه از ابتدای رشته dependency تا اولین : که هستقسمت dependency.name میشه بعد از اولین : تا قبل از : دوم که برای ورژن هستهمچنین dependency.version هم ورژن dependency مدنظر ماستبرای مثال اگر این dependency رو داشته باشیمandroidx.core:core-ktx:1.10.1تبدیل میشه به[versions] coreKtx = "1.10.1" [libraries] androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }بعد از sync کردن هم داخل فایل gradle حالا خواهیم داشتimplementation(libs.androidx.core.ktx)در اینجا libs که اشاره میکنه به فایلمون و باقی قسمت ها هم از تبدیل - به . در اسمی که گذاشتیم به دست میاد.برای پلاگین ها هم مشابه همین عمل رو داریم با این تفاوت که بجای group از id استفاده میکنیم و داخل gradle هم بجای id خواهیم داشت alias. مشابه فرمت زیر:toml: [versions] agp = "8.3.2" [plugins] androidApplication = { id = "com.android.application", version.ref = "agp" } gradle: alias(libs.plugins.androidApplication)سخن آخرحالا که با مزایای این روش آشنا شدین بهتون پیشنهاد میکنم که پروژه هاتون رو migrate کنید به version catalog - مخصوصا اگه با چند ماژول کار میکنین - تا سروکله زدن با gradle یکم براتون راحت تر بشه.

مسیر ایجاد دمو برای ویوهای تازه متولد شده

لیلا صدیقی — Sun, 21 May 2023 12:56:23 +0330

Demo view in android applicationاخیرا قرار بر این بود که به اپلیکیشن شرکت ظاهر متفاوتی بدیم. در همین راستا تیم دیزاین یه سری طرح برای ویوها ایجاد کرد تا با کاستوم کردن اونها بتونیم ازشون استفاده کنیم.تیم ما (تیم اندروید) هم تصمیم گرفت از این فرصت نهایت استفاده رو بکنه و صفحاتی که اکثرا توسط xml طراحی شده بودند رو ببره روی jetpack compose که در July 2021 رسما معرفی شده بود.کار به این صورت شکسته شد که ابتدا میبایست design systemهای بیسیک (چیزی که بهش میگفتیم atomic views) زده میشد و بعد از اونها برای پیاده سازی ویوهای پیچیده تر استفاده میکردیم. برای این کار اول یه ماژول بهش اختصاص دادیم به اسم widgets که پیش از این هم برای نگهداری custom viewهایی که داخل اپ اومده بودن ازش استفاده میکردیم. برای هر دیزاین یه composable function ایجادکردیم و تمام حالت هایی که ممکن بود ویوی مدنظر(disable, bordered و ...) بگیره رو داخلش لحاظ کردیم.مسـأله ای که حالا تیممون درگیرش بود این بود که سیستمی پیاده کنیم که هم بتونیم به کمکش پرفورمنس functionهایی که نوشتیم رو خیلی سریع بررسی کنیم، هم چیزی داشته باشیم برای انجام ui test و هم برای داکیومنت کردن فعالیتمون در راستای بهبود ظاهر اپ رو داکیومنت کرده باشیم. ضمنا وقتی نیروی جدیدی بهمون اضافه شه به کمک این قابلیت میتونه چک کنه که این چیزی که داخل طرح از سمت تیم ui اومده رو قبلا داشتیم یا باید اون هم پیاده سازی بشه با بررسی ریپوی now in android (که به نظرم میتونه یه مرجع قوی برای پیداکردن به روزترین روش برای هر مسـأله ای باشه) متوجه شدیم دقیقا روشی برای پیاده سازی دموی ui اونجا پیاده سازی شده. پس وقتش بود ما هم دست به کار بشیم. ?ابتدا نیاز بود یه ماژول ساخته بشه که دیپندنسی داره با ماژول widgets (که گفتیم تمام آیتم های design system رو اونجا پیاده سازی کردیم). کار خیلی ساده است. اسم ماژولمون شد app-view-catalog و کتابخونه های مرتبط با compose هم داخلش اد شد.برای اینکه به اندروید استودیو هم بگیم که قرار هست اینجا ما از ماژول widget استفاده کنیم کافی بود داخل build.gradle ماژول app-view-catalog این خط رو داشته باشیم:dependencies { implementation project(':widgets') // add other dependencies like compose }برای قرار دادن ویوهای جدید اول داخل ماژولمون فایلی به نام catalog ساخته شد. داخل این فایل یه LazyColumn انداختیم تا بعدا با اسکرول کردن روی گوشی های ضعیف تر به صورت چشمی تا حدی متوجه جاهایی که لگ داره بشیم. از ابتدای widget شروع کردیم و ویوهارو با حالت های مختلف استفاده کردیم. از ویوهای خیلی کوچکتر گرفته (مثل دکمه ها) تا چیزهای پیچیده تر (مشابه bottom sheet)حالا وقت استفاده از این فایل بود! برای همین اول باید ماژولمون رو وارد لیست وابستگی های ماژول app کنیم. مشابه قسمت قبل داخل بلاک dependencies در build.src ماژول app خواهیم داشت:implementation project(':app-view-catalog')حالا کافیه از فایل catalog تو برنامه استفاده کنیم مشابه اینجا:Scaffold { ApplicationTheme { Surface { Catalog() } } }درنهایت نتیجه همچین چیزی شد:شرط نمایش با توجه به build variantاحتمالا تصمیم داشته باشید شرط نمایش ویوی کامپوز ساخته شده صرفا در حالتی که قراره توسط تیم تست، تست بشه نمایش داده بشه نه برای کاربرها.برای این کار کافیه داخل ماژول اپتون productFlavor تعریف کنید:productFlavors { flavorDimensions 'releasee' production { dimension 'releases' versionNameSuffix '-prod' } test { dimension 'releases' versionNameSuffix '-test' } }حالا که flavorهای مختلف داریم و میتونیم در حالت های مختلف تست بگیریم میتونیم یه پارامتر هم داخل flavor قرار بدیم تا با چک کردن اون بررسی کنیم آیا قرار هست ویوی مربوطه رو نشون بدیم یا نه. برای این کار خط زیر رو داخل حالتی که قرار هست catalog نشون بدیم میذاریم resValue 'bool', 'show_app_catalog', 'true'و داخل بقیه اونها: resValue 'bool', 'show_app_catalog', 'false'درواقع در مثال بالا حالا همچین کدی خواهیم داشت:productFlavors { flavorDimensions 'releases' production { dimension 'releases' versionNameSuffix '-prod' resValue 'bool','show_app_catalog', 'false' } releaseTest { dimension 'releases' versionNameSuffix '-test' resValue 'bool', 'show_app_catalog', 'true' } }این تیکه کد براتون یه boolean میسازه که با استفاده از اون چه داخل xml و چه داخل compose میتونین برای چک کردن شرطتون از کد زیر استفاده کنین.روش استفاده در کد کامپوز:val showAppCatalog = booleanResource(R.bool.show_app_catalog) if (showAppCatalog) { // show view } else { // do sth }و داخل فایل xml هم میتونین به کمک ویوبایندینگ از این روش استفاده کنین:android:visibility='@{@bool/show_app_catalog ? View.VISIBLE : View.GONE}'فقط یادتون باشه باید View رو import کنین داخل xml: ... درنهایت ممنون از اینکه وقت گذاشتین و تا انتها خوندین. از اونجایی که این اولین مطلب من در حوزه تخصصی بود ممنون میشم ازتون اگه پیشنهاد یا نقدی دارین بگین که در آینده بتونم مطالبم رو بهتر کنم. ?