مقالات طراحی اپ موبایل

قابلیت و امکان های مدرن اپلیکیشن های اندرویدی – راهنمای کاربردی
ما به عنوان توسعه‌دهنده بعضی اوقات بایستی مسیر خود را آیتم بازنگری قرار دهیم. پلتفرم موبایل شاهد یکی سریع‌ترین تحول‌ها در صنعت 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-های تازه قابلیت و امکان رسم هر محتوایی را زیر نوارهای سیستمی مهیا می‌سازند و همچنین بخش‌های مهم اطلاعات را بسته به وضعیت حفره‌های نمایشگر به شیوه شگفت‌انگیزی بدون نیاز به فعالیت زیاد از حفره‌ها بدور میسازند.

با این که محتوا روی تک تک سطح برگه رسم میگردد، اما دوربین 3 بعدی روی مرکز حوزه‌ قابل استفاده تمرکز دارد. این نقطه تمرکز در محل تقاطع دو قطر قابل شناسایی می باشد. این نقطه به صورت دینامیک بر پایه ی نواحی غیر قابل استفاده نمایشگر تعریف شده است.
کتابخانه Insetter ساخته Chris Banes پیچیدگی باطل کردن متد ()dispatchApplyWindowInsets مربوط به ViewGroup یک root سفارشی و یا نوشتن یک OnApplyWindowInsetsListener سفارشی را رفع می‌کند. این نکته را نباید فراموش کنیم، زیرا نمی‌خواهیم اپلیکیشن را در موقعیت عمودی قفل کنیم. براین اساس نه تنها می بایست با inset-های بالا و پایین بلکه باید به هر چهار جهت اعتنا کنیم.

همچنین بایستی به تهیه خصوصیت android:windowLayoutInDisplayCutoutMode قالب اپلیکیشن روی shortEdges دقت داشته باشیم، زیرا این کار موجب می شود که UI در شرایط افقی تحت حفره‌های نمایشگر نیز کشیده شود. این وضعیت مخالف وضعیت پیش‌فرض می‌باشد که در آن این کار صرفاً در حالت عمودی جاری ساختن می‌یابد.

فایده این عملکرد اندک برای طراحی صحیح، یک نرم‌افزار خوب خواهد بود که از مزیت نمایش روی کل ورقه به جای محدود شدن به نواحی خارج از نوارهای مشکی سیستمی منفعت‌مند می‌گردد.

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

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

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

پیاده‌سازی عملی حفاظت از پوسته دوگانه برای یک پروژه نو فعالیت چندان دشواری محسوب نمیشود، البته در امر نرم افزار‌های کهن ممکن میباشد شغل تماماً مشقت باشد. Qualifier-های منبع night و notnight احتمالاً شایسته ترین محل برای آغاز عمل می باشند، البته به کار گیری از ویژگی‌های سفارشی به مکان ترجیح‌های بدون واسطه رنگی نیز آیتم‌ای میباشد که می‌قدرت آیتم رسیدگی قرار بخشید.

قابلیت و امکان های مدرن اپلیکیشن های اندرویدی – راهنمای کاربردی
ما به عنوان توسعه‌دهنده بعضی اوقات بایستی مسیر خود را آیتم بازنگری قرار دهیم. پلتفرم موبایل شاهد یکی سریع‌ترین تحول‌ها در صنعت 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-های تازه قابلیت و امکان رسم هر محتوایی را زیر نوارهای سیستمی مهیا می‌سازند و همچنین بخش‌های مهم اطلاعات را بسته به وضعیت حفره‌های نمایشگر به شیوه شگفت‌انگیزی بدون نیاز به فعالیت زیاد از حفره‌ها بدور میسازند.

با این که محتوا روی تک تک سطح برگه رسم میگردد، اما دوربین 3 بعدی روی مرکز حوزه‌ قابل استفاده تمرکز دارد. این نقطه تمرکز در محل تقاطع دو قطر قابل شناسایی می باشد. این نقطه به صورت دینامیک بر پایه ی نواحی غیر قابل استفاده نمایشگر تعریف شده است.
کتابخانه Insetter ساخته Chris Banes پیچیدگی باطل کردن متد ()dispatchApplyWindowInsets مربوط به ViewGroup یک root سفارشی و یا نوشتن یک OnApplyWindowInsetsListener سفارشی را رفع می‌کند. این نکته را نباید فراموش کنیم، زیرا نمی‌خواهیم اپلیکیشن را در موقعیت عمودی قفل کنیم. براین اساس نه تنها می بایست با inset-های بالا و پایین بلکه باید به هر چهار جهت اعتنا کنیم.

همچنین بایستی به تهیه خصوصیت android:windowLayoutInDisplayCutoutMode قالب اپلیکیشن روی shortEdges دقت داشته باشیم، زیرا این کار موجب می شود که UI در شرایط افقی تحت حفره‌های نمایشگر نیز کشیده شود. این وضعیت مخالف وضعیت پیش‌فرض می‌باشد که در آن این کار صرفاً در حالت عمودی جاری ساختن می‌یابد.

فایده این عملکرد اندک برای طراحی صحیح، یک نرم‌افزار خوب خواهد بود که از مزیت نمایش روی کل ورقه به جای محدود شدن به نواحی خارج از نوارهای مشکی سیستمی منفعت‌مند می‌گردد.

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

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

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

پیاده‌سازی عملی حفاظت از پوسته دوگانه برای یک پروژه نو فعالیت چندان دشواری محسوب نمیشود، البته در امر نرم افزار‌های کهن ممکن میباشد شغل تماماً مشقت باشد. Qualifier-های منبع night و notnight احتمالاً شایسته ترین محل برای آغاز عمل می باشند، البته به کار گیری از ویژگی‌های سفارشی به مکان ترجیح‌های بدون واسطه رنگی نیز آیتم‌ای میباشد که می‌قدرت آیتم رسیدگی قرار بخشید.