قوانین UX در اندروید

همه برنامه های مدرن اندروید از معماری تک اکتیویتی یا Single-Activity-Principle پیروی میکنن، که موجب میشه هر Activity که در برنامه شما ایجاد میشه به اجزای مهم مثل Toolbar(بالایی و پایینی)، Drawer،BottomSheetDialog، و یا حتی BottomNavigationView رو شامل بشه، و همه ی اونا اطراف یک container قرار میگیرن که همه Fragmentها رو با یک نمودار جهت یابی navigation-graph میزبانی میکنه.طراحی UX بنظر خیلی ساده میاد، اما وقتی که میخوایم ماژول ها توسط الگو های UX رو تعریف کنیم کار یخورده پیچیده میشه:ترتیب صفحاتی که Back-Gesture نیاز دارنصفحاتی که به طراحی متفاوت برای (Toolbar) نیاز دارندر بعضی صفحات نباید از Drawer (در صورتی که پشتیبانی میشه) استفاده کردمنو باید با توجه به محتوای صفحه تغییر کنهآیکون نوار ابزار باید به عملکرد های بین Back-Gesture و Expand-Drawer رسیدگی کنهدکمه شناور(Floating Action Button) فقط برای تعدادی از صفحه ها استفاده بشهعنوان نوار ابزار باید با صفحه ها همگام یا همون sync باشهو خیلی نیازهای دیگه برای UX که باعث میشه کد های بیشتر و بیشتری به برنامه تون اضافه کنید، و از همه بدتر: بعضی وقتا موقع تغییرات کد شاهد باگ هایی هم میشین.کابوس UXبا توجه به اینکه توی چه مدت زمانی میخواین برنامه تون رو منتشر کنید، باید یه سری فداکاری هایی رو انجام بدین و از برخی کار ها بگذرین:روی متریال های الگوی UX تمرکز کنین: بسیاری از جعبه ابزار های UX اندروید از کامپوننت های آماده سایت material.io استفاده میکنن.با طراح های UXتون هماهنگی های لازم رو انجام بدین و مطمئن شین که متوجه بشن که بهتر کردن UI رو در مرحله های بعدی انجام میدین، یا رفتار های دیگه ای که قراره بعد از تموم شدن کارمون با عملکرد های هسته تموم شد اضافه بشن(مثل ترانزیشن ها و یا انیمیشن ها). به طور کلی میشه UX(که میشه UI+رفتار ها) رو خیلی زیاد بهتر کرد.روی "ضروریات" بیشتر تمرکز کنین، در غیر اینصورت هیچ وقت برنامه تون رو منتشر نمیکنید.ظاهرسازی و طراحی تم هم اهمیت بسزایی داره، ولی حواستون باشه طراحی الگو های تازه برای UX چندان هم آسون نیست. باید نشون دادن هر یک از کنترل های UI رو تعریف کنید، به علاوه اینکه بقیه کامپوننت ها هنگام فعال شدن، غیرفعال شدن، کلیک،کلیک بلند، ترانزیشن ها/انیمیشن ها و... چه رفتاری نشون بدن رو تعریف کنید.توی خیلی از برنامه های اندروید فقط رنگ بندی ها رو تغییر میدن و از کامپوننت های پیشفرض استفاده میکنن، چون وقت طلاست! و هر چقدر زودتر برنامه رو منتشر کنین برای همه بهتره! بعدا میتونین رو ظاهر برنامه تون بیشتر کار کنین تا "جذابترش" کنین!خب حالا که همه رو قانع کردین که از کامپوننت های آماده استفاده کنن. حالا چی؟ باید چیزی که قولش رو دادین زودتر به دست مشتری برسونین:مدیریت بهینه منابع (رم، سی پی یو و حافظه مصرفی)عملکرد هسته برای همه ماژول ها (لیست ها، صفحه بندی ها،API، مکانیزم کش، پشتیبانی آفلاین، سایز صفحات، گرایش های مختلف و ...)رسیدگی به بعضی از edge-case ها (مورد های لبه ای) که صفحه در سایز بندی های مختلف میتونه داشته باشهطراحی یکپارچه و استوار جهت ها(Navigation) بین صفحاتنوع اعلان های مختلف که کاربر به یک صفحه خاص انتقال پیدا میکنهپیشتیبانی از لینک عمیق (Deep Link) و یکپارچه سازی وبآنالیزکردن فعالیت های کاربر (صفحات بازدید شده، رویداد های UI)اینا چالش ها و مشکلاتیه هر پروژه اندروید داره، و بسته به نوع کارِتون، یکی از اتفاقای زیر میفته:موفق میشید، یعنی معماری که روی برنامه توی انجام دادین ساختاری قوی داره، که باعث میشه سال ها روی برنامه تون با لذت بیشتری کار کنینیا روی هر مرحله به مشکل میخورین،کد های بیشتری اضافه میکنین فقط برای اینکه کار کنه، که باعث میشه ماه ها بعد هنگام استفاده از کد دچار سردرگمی بیشتری بشین، آخر سر هم یک برنامه "نیاز به ریفکتور" دارین که باید یکی یکی همه کد های درهمی که نوشتین رو اصلاح کنین.خب حالا برنامه شما با توجه به نیاز هاتون یه ساختار استاندارد داره. اگه با این الگو ها و کامپوننت ها آشنایی دارین، به خوندن ادامه بدین! بهتون نشون میدم که استراتژی برای فراهم سازی ساختار برای پروژه تون چه شکلی خواهد بود.اول از همه، 5 نکته خیلی مهم هست که باید بهشون توجه کنید:1. کامپوننت های Drawer و BottomSheetDialog شامل یک NavigationViewمیشن.2. آیتم های NavigationViewبه عنوان آیتم منو تعریف میشن.3. کامپوننت BottomNavigationView و NavigationView میتونن منوی خودشون رو داشته باشن، البته این به این بستگی داره که چطوری میخواین مسیر هاتون یا همون destinationsرو سازماندهی کنین.4.میشه Toolbarهای برنامه تون (چه بالایی و چه پایینی) و Drawer برای کارکردن با هم هماهنگ بشن، برای صفحه اصلی ها Toolbar سه آیکون نشون میده، ولی برای فرعی ها آیکون عقب برگشتن رو نشون میده.5. نمودار جهت یابی (Navigation-graph) باید منبع اصلی نیازمندی های جهت یابی باشه، و این یعنی که دیگه نباید راه حل های خودسرانه و قطعه های دیگه برای ساخت جهت یابی جدید استفاده کنین. برنامه تون باید از مسیر یا destination برای حرکت بین صفحه ها استفاده بکنهرابطه کامپوننت های UIاین ساختار به شما این اجازه رو میده ماژول های تازه رو بدون هیچ زحمتی اضافه کنین چون همه کامپوننت ها با هم هماهنگ شدن و نیاز به کد اضافه ای ندارین. نکات زیر باید استراتژی بلند مدت شما برای اضافه کردن امکانات تازه باشه:ماژولی تازه (قطعه ها، ماژول های view و ...) برای گروه بندی کلاس های مربوط به هم تعریف کنید – فقط روی امکانات ماژول تمرکز کنیدمسیر ها رو به نمودار جهت یابی اضافه کنیدورودی های تازه به Menu اضافه کنیددوما، الگو های تازه برای UX برنامه تون تعریف کنید. میتونین از کامپوننت های آماده برای ساده تر شدن کار استفاده کنین، و بعدا که بیشتر با معماریش آشنا شدین میتونین کامل ترش کنین.در زیر به 6 تا از پر استفاده ترین الگو های UX (تا آوریل 2021) که میشه با کامپوننت Material درست بشه اشاره شده:الگوی Toolbar+drawer: روش سنتی، فقط toolbar بالایی با Drawerسمت چپ (یا راست) که شامل جهت ها میشه. این الگو هیچ مشکلی نداره، فقط یه مقدار قدیمیه، توی صفحه های بزرگ کلیک کردن روی دکمه drawer یه مقدار سخته، یا برای بیرون کشیدن Drawer باید دستتون رو عوض کنید، که این یعنی زیاد مناسب نیست.الگوی Toolbar و Drawerالگوی Bottom-Navigation-View: روش تازه تر، ولی فقط برای مواقعی که کمتر از 5 مسیر داشته باشین. برای قرار دادن بقیه مسیر ها باید یک Toolbar هم تعریف کنید. فقط زمانی از این الگو استفاده کنین که 100 درصد مطمئنین که میشه همه مسیر ها رو در زیر قرار بدین – بعضی ها این باور رو دارن که در BottomNavigationView فقط باید اصلی ترین مسیر ها رو قرار داد، و بقیه مسیر ها رو با استفاده از روش های دیگه مثل منو ها به کاربر نشون داد.الگوی Bottom-Navigation-Viewالگوی Toolbar+Drawer+Bottom-Navigation-View: ترکیبی از دو الگوی قبلی. یه جورایی مشکل استفاده از فقط BottomNavigationViewرو حل میکنه، چون Drawer میتونه مسیر های اضافه رو نشون بده. بعضی اوقات شاید بهتر باشه که همه مسیر ها رو در Drawer نشون بدید.الگوی Toolbar و Drawer و Bottom-Navigation-Viewالگوی Bottom-App-Bar+Drawer: الگویی که در سال های گذشته خیلی پر استفاده تر شده. خیلی راحت تر میشه با برنامه تعامل داشت، چون همه چی با یه دست قابل استفاده ست، مخصوصا توی صفحه های بزرگ. تو این الگو معمولا از Drawer استفاده میشه، و معمولا سمت چپ قرار میگیره، که برای راست دست ها کار رو یخورده سخت میکنه، ولی میشه با android:layoutDirection این مشکل رو برطرف کرد، ولی حواستون باشه چون باید این ویژگی ها رو دستی روی کامپوننت Childتعریف کنید، که اگه کاربر صفحه ش راست به چپ باشه (مثلا تو ایران) کار خراب میشه. خوبی استفاده از BottomAppBar اینه که FloatingActionButton خیلی خوب در گوشه جا میشه، و البته مکان این رو هم میشه به راست تغییر داد.الگوی Bottom-App-Bar و Drawerالگوی Bottom-App-Bar + Bottom-Sheet-Dialog: درست مثل قبلی، فقط با این تفاوت که به جای Drawer از BottomSheetDialogFragment استفاده شده. در تصویر زیر میتونین ببینید که Bottomsheetمون هدر هم داره، که شاید بهتر باشه توی برنامه تون ازش استفاده نکنین.الگوی Bottom-App-Bar و Bottom-Sheet-Dialogالگوی Toolbar + Drawer + Bottom-App-Bar + Bottom-Navigation-View: میشه گفت که این الگو یه جورایی استاندارد نیست. چون ترکیبی از همه الگو های قبلیه (غیر از Bottom-Sheet). هدف اینه که کاربر بتونه سریعا به همه ماژول ها دسترسی داشته باشه. اگه قرار باشه بین 3 یا 5 مسیر داشته باشین از این الگو استفاده نکنین، چون یکی از مسیر ها بخاطر FloatingActionButtonی که در وسط داریم، جلوش گرفته میشه. میتونین توی تصویر زیر نگاه کنین. اگه دقت کنید وقتی صفحه پایین کشیده میشه FloatingActionButton چند dip پایین تر میاد تا جلوی آیتم هایی که در حال نمایش هستند گرفته نشه. فقط زمانی از این الگو استفاده کنین که واقعا FloatingActionButton نیازه.الگوی Toolbar و Drawer و Bottom-App-Bar و Bottom-Navigation-Viewمسلما برنامه ما نیازی به این همه پیچیدگی نداره، شما قراره فقط یکی از استایل ها رو انتخاب کنین. همونطور که دیدید ساخت معماری هر چند ساده اما موثر برای اندروید خیلی آسونه.سورس پارت 1سورس پارت 2