فرادرسقابلیت های مدرن اپلیکیشن های اندرویدی – راهنمای کاربردی
ما به عنوان توسعه‌دهنده گاهی اوقات باید مسیر خود را مورد بازنگری قرار دهیم. پلتفرم موبایل شاهد یکی از سریع‌ترین تحول‌ها در صنعت IT است. از این رو از منظر فنی شاید بتوان فرد را به خاطر چسبیدن به روش‌های قدیمی و مطمئن حل برخی مسائل به جای پریدن از این شاخه به آن شاخه و امتحان کردن همه کتابخانه‌ها و معماری‌ها جدید یا تجربه‌های درخشان، مورد بخشش قرار داد. در این مقاله در مورد برخی از قابلیت های مدرن اپلیکیشن های اندرویدی صحبت می‌کنیم که در برابر چشم کاربر قرار دارند و مورد بی‌توجهی قرار گرفته‌اند یا از سوی توسعه‌دهندگان به درستی مورد استفاده قرار نگرفته‌اند.
با این که کاربران هیچ روشی برای درک این که برخی راه‌حل‌ها در پس‌زمینه چه مقدار تاریخ‌گذشته هستند، در اختیار ندارند، اما می‌توانند متوجه شوند که حس و ظاهر یک نرم‌افزار چه مقدار مدرن به نظر می‌رسد و آیا اپلیکیشن مورد نظر به خوبی با سیستمی که اجرا می‌کنند هماهنگی دارد یا نه. به کار گرفتن روندهای جدید UX گامی اساسی در مسیر تکامل پلتفرم محسوب می‌شود و باید به صورت جمعی تلاش کنیم تا در این زمینه بهتر عمل کنیم و بتوانیم تجربه کاربری نو و منسجم‌تری به کاربران خود ارائه کنیم.
UI مقیاس‌پذیر
با توجه به یک دهه تجربه در زمینه پشتیبانی از صفحه‌ها با هر نوع نسبت ابعادی ممکن، به نظر می‌رسد دیگر نباید شاهد مشکلاتی در زمینه حالت چند پنجره‌ای به شکل آزاد در اندروید باشیم. اما هم چنان اغلب اپلیکیشن‌ها در مدیریت صحیح این موضوع مشکل دارند.
امروزه شاهد کروم‌بوک‌هایی هستیم که اپلیکیشن‌های اندرویدی را در پنجره‌های با قابلیت تغییر اندازه اجرا می‌کنند. Samsung DEX نیز کار مشابهی انجام می‌دهد. به طور خاص One UI قابلیتی به نام pop-up view دارد که حتی نیازمند نمایشگر اکسترنال نیز نیست. حتی ادیتور لی‌آوت اندروید استودیو امکان کشیدن گوشه پنجره پیش‌نمایش و بررسی شیوه نمایش پنجره در هر نسبت ابعادی ممکن را فراهم ساخته است. با توجه به همه این موارد دیگر زمان استفاده از دستورهایی مانند زیر پایان یافته است:
android:screenOrientation="portrait"
android:resizableActivity="false"
اینک ما به UI-هایی نیاز داریم که به سرعت و سهولت در هر زمان با هر اندازه صفحه‌ای تطبیق یافته و حالت (State) را نیز از دست ندهند.
بسیاری از کتابخانه‌های جتپک باعث شده‌اند دستیابی به چنین وضعیتی بسیار آسان‌تر از آن چه به نظر می‌رسد شود. یکی از ساده‌ترین روش‌ها برای نیل به این مقصود، جدا نگه‌داشتن کامل لایه داده از نما است و ViewModel به طور خاص به این منظور خلق شده است. صرف کمی زمان بیشتر برای تأمل در مورد مدیریت رویدادهای چرخه عمری نیز می‌تواند به حل این مشکل‌های بالقوه کمک کند. نکته دیگری که می‌تواند بازیابی حالت را با مشکل مواجه سازد، پشته‌سازی نادرست فرگمان است که با بهره‌گیری از کامپوننت Navigation (+) می‌توان از آن اجتناب کرد.
در زمان پیاده‌سازی UI واقعی، می‌توانیم در اغلب موارد حاد بیشترین کمک را از ConstraintLayout به همراه resource qualifiers بگیریم. در صفحه‌هایی که لیست را نمایش می‌دهند، یک GridLayoutManager با تعداد span دینامیک نیز می‌تواند ابزار مفیدی محسوب شود.
با در نظر گرفتن همه موارد، پشتیبانی از حالت چند پنجره‌ای به شکل آزاد، بیشتر چالش تیم طراحی محسوب می‌شود تا تیم توسعه، چون اگر معماری کاملاً به دقت طراحی شده باشد، امکان ذخیره‌سازی و بازیابی صحیح حالت پس از تغییرات پیکربندی وجود خواهد داشت.
مدیریت حفره‌های پنجره
ناچ‌های نمایشگر و دوربین‌هایی که در حفره‌های روی نمایشگر جاسازی شده‌اند، فضای متغیری از صفحه را اشغال می‌کنند و به مشکل جدیدی تبدیل شده‌اند. اما در این مورد API-های جدید امکان رسم هر محتوایی را زیر نوارهای سیستمی فراهم می‌سازند و همچنین بخش‌های مهم اطلاعات را بسته به وضعیت حفره‌های نمایشگر به طرز شگفت‌انگیزی بدون نیاز به کار زیاد از حفره‌ها دور می‌سازند.
کتابخانه Insetter ساخته Chris Banes پیچیدگی باطل کردن متد ()dispatchApplyWindowInsets مربوط به ViewGroup یک root سفارشی و یا نوشتن یک OnApplyWindowInsetsListener سفارشی را رفع می‌کند. این نکته را نباید فراموش کنیم، زیرا نمی‌خواهیم اپلیکیشن را در حالت عمودی قفل کنیم. بنابراین نه تنها باید با inset-های بالا و پایین بلکه باید به هر چهار جهت توجه کنیم.
همچنین باید به تنظیم خصوصیت android:windowLayoutInDisplayCutoutMode قالب اپلیکیشن روی shortEdges توجه داشته باشیم، زیرا این کار موجب می‌شود که UI در حالت افقی زیر حفره‌های نمایشگر نیز کشیده شود. این وضعیت مخالف حالت پیش‌فرض است که در آن این کار صرفاً در حالت عمودی انجام می‌یابد.
نتیجه این تلاش اندک برای طراحی صحیح، یک اپلیکیشن عالی خواهد بود که از مزیت نمایش روی کل صفحه به جای محدود شدن به نواحی خارج از نوارهای مشکی سیستمی بهره‌مند می‌شود.
پشتیبانی از حالت تیره
اگر اپلیکیشنی که طراحی می‌کنیم صرفاً از پس‌زمینه روشن پشتیبانی کند بسیاری از کاربران تلاش خواهند کرد پس از غروب آفتاب و در مناطق تاریک از آن استفاده نکنند. امروزه اغلب اپلیکیشن‌ها از طراحی متریال تیره بهره می‌گیرند و اگر اپلیکیشن شما چنین حالتی نداشته باشد، عقب مانده به نظر می‌رسد.
همین حرف را می‌توان در مورد سمت دیگر نیز گفت. برخی کاربران تم روشن را ترجیح می‌دهند که در زیر نور مستقیم آفتاب بهتر دیده می‌شود. راه‌حل این مشکل واضح است. کاربران به حق انتخاب نیاز دارند و ما باید از نخستین مراحل طراحی اپلیکیشن از هر دو گزینه تیره و روشن پشتیبانی کنیم.
اما می‌دانیم که به هر حال دیر رسیدن بهتر از هرگز نرسیدن است. حالت شب دیگر در بخش گزینه‌های توسعه‌دهنده گوشی پنهان نشده است. امروزه هر کس می‌تواند ترجیح خود را بین قالب‌های تیره و روشن در هر زمان انتخاب کند، اما ممکن است نتایج این کار مطابق انتظار آن‌ها نباشد. iOS در این زمینه بسیار پیشروتر است. یک کلید اصلی می‌تواند در مورد سوئیچ بین قالب تیره و روشن برای هر اپلیکیشن منفرد استفاده شود، اما در اندروید، پیاده‌سازی‌های منفرد بسیار نامنسجم هستند.
در این زمینه با همان مشکلی مواجه هستیم که در زمان کدنویسی در مورد تنظیم زبان در سطح سیستمی از سوی کاربر مواجه می‌شویم. هر اپلیکیشن از انتخابگر قالب سفارشی خاص خود بهره می‌گیرد. این که این وضعیت یک مشکل محسوب می‌شود یا نه قابل بحث است، اما دست کم موافق هستیم که باید یک گزینه پیش‌فرض برای پیگیری ترجیح سراسری سیستمی وجود داشته باشد.
پیاده‌سازی عملی پشتیبانی از قالب دوگانه برای یک پروژه جدید کار چندان دشواری محسوب نمی‌شود، اما در مورد اپلیکیشن‌های قدیمی ممکن است کار کاملاً سختی باشد. Qualifier-های منبع night و notnight احتمالاً بهترین محل برای شروع کار هستند، اما استفاده از خصوصیت‌های سفارشی به جای ترجیح‌های مستقیم رنگی نیز گزینه‌ای است که می‌توان مورد بررسی قرار داد.
صفحه اسپلش
صفحه آغازین یا splash screen به هیچ وجه مفهوم جدیدی محسوب نمی‌شود، اما به عنوان نخستین چیزی که کاربران در اپلیکیشن ما می‌بینند، اگر به درستی پیاده‌سازی نشده باشد، به طرزی بدیهی زشت خواهد بود.
مثلاً ممکن است از یک انیمیشن ورودی 5 ثانیه‌ای زیبا استفاده کرده باشید که هر بار کاربر اپلیکیشن را باز می‌کند به وی نمایش داده می‌شود. همچنین ممکن است لازم باشد پیش از آن که بتوان چیز معناداری به کاربر نمایش داد، برخی داده‌ها وجود داشته باشند که باید دانلود شوند. اما اگر تاکنون صفحه‌ای به اپلیکیشن اضافه کرده باشید که تنها وظیفه آن مسدودسازی کاربر از دستیابی سریع به صفحه اصلی اپلیکیشن بوده است، بهتر است در رویه‌های خود تجدیدنظر کنید، چون امروزه روش‌های بهتری هم برای حل این مشکل‌ها وجود دارند.
اپلیکیشن‌های اندرویدی پیش از آن که متد ()onCreate نخستین اکتیویتی فراخوانی شود، به مدت زمانی برای بارگذاری نیاز دارند. در طی این مدت قالب windowBackground اپلیکیشن روی صفحه رسم می‌شود. بهترین صفحه اسپلش صرفاً یک پس‌زمینه سفارشی drawable برای قالب است که در لحظه ایجاد نخستین اکتیویتی override می‌شود.
سخن پایانی
با این که اپلیکیشن‌های موفق مدرن جنبه‌های مختلفی دارند، اما در این مقاله به بررسی چهار مورد از مواردی که احتمالاً می‌توان در مورد هر اپلیکیشن اندرویدی اعمال کرد پرداختیم. آن‌ها را می‌توان به صورت یک الزام مقدماتی برای یکپارچه‌سازی تجربه کاربری اپلیکیشن در حس و حال کلی اندروید در نظر گرفت. با این که پیاده‌سازی برخی از این موارد نیازمند برنامه‌ریزی و تلاش طراحی بیشتری است، اما مطمئن باشید این موضوعی نیست که بتوان در مورد آن محافظه‌کاری به خرج داد. نتیجه ایجاد اپلیکیشن‌هایی که بخشی طبیعی از سیستم عامل به نظر می‌رسند، پدید آمدن یک اکوسیستم بالغ‌تر است و همگی ما باید به آن سمت حرکت کنیم.
اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:
- مجموعه آموزش‌های برنامهنویسی اندروید
- مجموعه آموزش‌های برنامهنویسی
- گنجینه برنامهنویسی اندروید (Android)
- پروفایل کردن اپلیکیشن ها با اندروید استودیو — به زبان ساده
- ساخت کتابخانه اندروید و انتشار آن — به زبان ساده
==
