طبیعتا همه کسایی که میخوان برنامه نویسی فلاتر رو شروع کنن، یکی از مهمترین فاکتور هایی که بخاطر اون فلاتر رو انتخاب میکنن خروجی گرفتن در چند پلتفرم هستش. یک Codebase واحد که برای ما خروجی اندروید، iOS، ویندوز، وب و … رو میده؛ خیلی قابلیت خوبیه!
ولی چیزی که امروز میخوام راجع بهش صحبت کنم، اینه که چرا از این قابلیت خفن استفاده نکنیم!
احتمالا با Design System ها آشنایی دارین، اصول طراحی ای که هر پلتفرم توی طراحی رابط کاربریش رعات میکنه. مثلا اندروید از Material Design استفاده میکنه، iOS از Apple Human Interface، ویندوز از Fluent Design System و …
طبیعتا شما وقتی که داری یه اپلیکیشن اندروید توسعه میدی بهتره که از material design استفاده کنی تا تجربه کاربری بهتری واسه کاربرها فراهم کنی. همچنین توی iOS و ویندوز هم بهتره که از دیزاین سیستم خود اون پلتفرم های استفاده کنیم.
نکته مثبت داستان اینه که فلاتر از این دیزاین سیستم ها پشتیبانی میکنه، اگه بخوای از استایل های متریال استفاده کنی فقط لازمه که material.dart رو ایمپورت کنی، اگه بخوای از استایل های iOS استفاده کنی فقط لازمه cupertino.dart رو ایمپورت کنی.
کلی ویجت با استایل های استاندارد سیستم عامل در اختیارت میزاره، به همین سادگی!
(البته fluent design هنوز پشتیبانی رسمی نداره)
خب حالا مشکل چیه؟
شما وقتی اپلیکیشن خودت رو داری توسعه میدی، یا از ویجت های متریال استفاده میکنی یا از ویجت های کوپرتینو. (فعلا همین دوتا روبحث میکنم)
اگه بخوای توی اندروید از دکمه استایل اندروید استفاده کنی باید ElevatedButton استفاده کنی، و برای دکمه با استایل iOS بجای اون باید از CupertinoButton استفاده کنی.
حالا چجوری توی هرکدوم از این سیستم عامل ها دکمه (یا هر ویجتی) با استایل خود اون سیستم عامل رو نشون بدیم؟ با شرط چک کردن سیستم عامل!
Platform.isAndroid ? ElevatedButton() : CupertinoButton()
این به مثال ساده بود، حالا فرض کنین برای نصف ویجت های اپلیکیشن مجبور شیم شرط چک کردن سیستم عامل بنویسیم. یا حتی بدتراز اون، کارفرما بخواد پشتیبانی از ویندوز رو هم اضافه کنه! باید if else یا switch case بنویسیم واسه ویجت هایی که استایل متفاوتی توی دیزاین سیستم این پلتفرم ها دارن.
(البته راه های ساده تری هم واسه این کار وجود داره ولی اون چیزی که ما میخوایم شاید در نیاد)
مشکل از اینها بزرگتر هم میشه، اون هم جاهایی که دیزاین سیستم اندروید و iOS از اساس متقاوت میشه. فرض کنین طراح UI اپلیکیشن شما، تصمیم میگیره UI اپلیکیشن شما توی iOS رو بر اساس BottomNavigation طراحی کنه ولی دیزاین Android رو بر اساس TabBar! که دوتا ساختار کاملا متفاوت هستن.
چیزی که شما در نهایت باهاش مواجه میشین به احتمال زیاد یه کد به هم ریخته، پر از شرط های تکراری، با خوانش پایین هستش.
چیزی که میخوام مطرح کنم اینه که بیخیال نوشتن یه codebase واحد و انتشار اون روی همه پلتفرم ها بشیم.
جای اون تمرکز خودمون رو روی جداکردن Business Logic از Presentation Layer بزاریم. به عنوان مثال برای یه اپ موبایل دو پروژه داشته باشیم که از logic مشترکی استفاده میکنن، ولی UI اپلیکیشن و تجربه کاربری اون بر اساس همون پلتفرم طراحی شده.
بنظرم ایده خوبی میتونه باشه مخصوصا برای پروژه های بزرگ. مشکلی از بابت Scale پذیری پروژه نخواهیم داشت توی بحث Flutter UI. اگه کارفرما تصمیم به اضافه کردن ساپورت وب یا ویندوز بگیره، ما میتونیم یه پروژه مخصوص وب ایجاد کنیم که لاجیکش هیچ تفاوتی با اپلیکیشن های ما نداره (State Management، ارتباط با سرور، ارتباط با دیتابیس یا هرچیز مشابه این رو نیاز نیست از اول پیاده سازی کنیم) فقط تنها کاری که باید بکنیم پیاده کردن UI مناسب یک وبسایت هستش. طبیعتا کار جالبی نیست که ما دقیقن همون استایل اپلیکیشن اندروید رو بیاریم و به عنوان یک وبسایت ارائه بدیم :)
به عنوان مثال توی یه اپلیکیشن فروشگاهی، لاجیک سبد خرید رو میتونیم تبدیل کنیم به یه پکیج لوکال. این پکیج لوکال ما قراره که همه عملیات ارتباط با سرور جهت ذخیره سازی سبد خرید و پرداخت رو توی خودش داشته باشه و هندل کنه. بعد از اون میتونیم هر چند تا پروژه که بخوایم برای سیستم عامل های متفاوت ایجاد کنیم و از این لاجیک استفاده کنیم.
از اینجا به بعد هر پروژه مخصوص یه سیستم عامل هستش و مشکل شرط های تکراری برای UI، پکیج های بی استفاده توی بعضی سیستم عامل ها، مقیاس پذیری پایین بعد توسعه توی چند سیستم عامل و خوانایی پایین کد بعد بزرگ شدن پروژه رو تا حدودی میتونیم برطرف کنیم.
اگه تجربه ای توی این زمینه دارین خوشحال میشم توی کامنت ها مطرح کنین.
