نقل واجهة المستخدم إلى التنسيقات المتجاوبة

تحتاج تطبيقات Android إلى دعم منظومة متكاملة آخذة في التوسّع لعوامل أشكال الأجهزة. يجب أن تكون واجهة المستخدم الخاصة بالتطبيق سريعة الاستجابة لتناسب مجموعة واسعة من أحجام الشاشات بالإضافة إلى الاتجاهات وحالات الجهاز المختلفة.

تركز واجهة المستخدم سريعة الاستجابة على مبادئ المرونة والاستمرارية.

تشير المرونة إلى التخطيطات التي تستفيد على النحو الأمثل من المساحة المتوفرة ويتم ضبطها عند تغيير المساحة المتاحة. يمكن أن تتخذ التعديلات أشكالاً متعددة: مجرد زيادة حجم عرض واحد، أو إعادة تحديد مكانة المشاهدات بحيث تكون في مواقع يسهل الوصول إليها، أو إظهار أو إخفاء طرق عرض إضافية، أو مزيج من ذلك.

تشير الاستمرارية إلى توفير تجربة مستخدم سلسة أثناء الانتقال من حجم نافذة إلى آخر. مهما كانت التجربة التي يشارك فيها المستخدم، يجب أن تستمر دون انقطاع. نظرًا لأن التغيير في الحجم قد يكون مصاحبًا لتدمير وإعادة إنشاء التسلسل الهرمي لطريقة العرض بالكامل، فمن المهم ألا يفقد المستخدم مكانه أو بياناته.

أمور يجب تجنّبها

تجنب استخدام قيم الأجهزة المادية لاتخاذ قرارات التصميم. قد يكون من المغري اتخاذ قرارات بناءً على قيمة ثابتة، ولكن في كثير من الحالات لا تكون هذه القيم مفيدة لتحديد المساحة التي يمكن أن تعمل بها واجهة المستخدم.

على الأجهزة اللوحية، قد يتم تشغيل تطبيق في وضع النوافذ المتعددة، ما يعني أنّ التطبيق يشارك الشاشة مع تطبيق آخر. على نظام التشغيل ChromeOS، قد يكون التطبيق في نافذة يمكن تغيير حجمها. يمكن أن يكون هناك أكثر من شاشة مادية، مثل جهاز قابل للطي أو جهاز يحتوي على شاشات متعددة. في كل هذه الحالات، لا يكون حجم الشاشة المادي مناسبًا لتحديد كيفية عرض المحتوى.

وللسبب نفسه، تجنَّب قفل التطبيق باتجاه معين أو نسبة عرض إلى ارتفاع معينة. على الرغم من أن الجهاز نفسه قد يكون في اتجاه معين، قد يكون اتجاه التطبيق في اتجاه مختلف استنادًا إلى حجم النافذة فقط. على سبيل المثال، في الجهاز اللوحي الذي يستخدم الوضع الأفقي أثناء استخدام وضع النوافذ المتعددة، يمكن أن يكون التطبيق في الوضع العمودي لأنه أطول من عرضه.

وتجنَّب أيضًا محاولة تحديد ما إذا كان الجهاز هاتفًا أو جهازًا لوحيًا. ما الذي يتأهل تحديدًا ليكون جهازًا لوحيًا ذاتيًا إلى حد ما: هل يعتمد على وجود حجم معين أو نسبة عرض إلى ارتفاع معينة، أم مزيج من الحجم ونسبة العرض إلى الارتفاع؟ مع ظهور أشكال جديدة، يمكن أن تتغير هذه الافتراضات، ويفقد التمييز أهميته.

بدلاً من تجربة أي من الاستراتيجيات السابقة، استخدم نقاط التوقف وفئات حجم النوافذ.

فئات نقاط الإيقاف وفئات حجم النوافذ

الجزء الفعلي من الشاشة المخصص لتطبيقك هو نافذة التطبيق. قد يشغل هذا التطبيق وضع ملء الشاشة أو جزءًا منه، لذا استخدِم حجم النافذة عند اتخاذ قرارات عالية المستوى بشأن تنسيق التطبيق.

عند التصميم لعوامل شكل متعددة، ابحث عن قيم الحدود حيث تتفرع هذه القرارات عالية المستوى في اتجاهات مختلفة. تحقيقًا لهذه الغاية، توفر شبكة التخطيط سريعة الاستجابة في Material Design نقاط توقف للعرض والارتفاع، ما يتيح لك تعيين الأحجام الأولية في مجموعات منفصلة وموحدة يشار إليها باسم فئات حجم النوافذ. نظرًا لانتشار التمرير العمودي في كل مكان، تهتم معظم التطبيقات بشكل أساسي بفئات حجم العرض، لذلك يمكن تحسين معظم التطبيقات لتتوافق مع جميع أحجام الشاشات من خلال التعامل مع بضع نقاط توقف فقط. (لمزيد من المعلومات حول فئات حجم النوافذ، يُرجى الاطّلاع على إتاحة أحجام الشاشات المختلفة.)

عناصر واجهة المستخدم الثابتة

تحدد إرشادات التنسيق للتصميم متعدد الأبعاد مناطق أشرطة التطبيقات والتنقل والمحتوى. عادةً ما يكون العنصران الأولان ثابتان في واجهة المستخدم (أو قريبًا جدًا) من جذر العرض الهرمي للعرض. يُرجى العِلم أنّ كلمة "مستمرة" لا تعني بالضرورة أنّ العرض مرئي دائمًا، بل هو تبقى في مكانها بينما قد تتغيّر طرق عرض المحتوى الأخرى أو تتغير. على سبيل المثال، يمكن أن يكون عنصر التنقل في درج مجرد خارج الشاشة، لكن اللائحة موجودة دائمًا.

يمكن أن تكون العناصر الثابتة سريعة الاستجابة، وعادةً ما تشغل إما العرض الكامل أو ارتفاع النافذة بالكامل، لذلك ننصحك باستخدام فئات الحجم لتحديد مكانها. يحدد هذا المساحة المتبقية للمحتوى. في المقتطف التالي، يستخدم النشاط شريطًا سفليًا للشاشات المضغوطة وشريط تطبيق علوي للشاشات الأكبر حجمًا. تستخدم التخطيطات المؤهلة نقاط توقف للعرض كما هو موضح سابقًا.

<!-- res/layout/main_activity.xml -->

<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <!-- content view(s) -->

    <com.google.android.material.bottomappbar.BottomAppBar
        android:layout_width="wrap_content"
        android:layout_height="0dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent"
        ... />
</androidx.constraintlayout.widget.ConstraintLayout>


<!-- res/layout-w600dp/main_activity.xml -->
<androidx.constraintlayout.widget.ConstraintLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <com.google.android.material.appbar.AppBarLayout
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintEnd_toEndOf="parent"
        ... />

    <!-- content view(s) -->
</androidx.constraintlayout.widget.ConstraintLayout>

المحتوى

بعد تحديد موضع عناصر واجهة المستخدم الثابتة، استفِد من المساحة المتبقية للمحتوى، مثل استخدام علامة NavHostFragment مع الرسم البياني للتنقّل في تطبيقك. راجع التنقل إلى واجهات المستخدم سريعة الاستجابة لمعرفة المزيد من الاعتبارات.

التأكد من توفر جميع البيانات لأحجام مختلفة

تستفيد معظم أطر عمل التطبيقات اليوم من نموذج بيانات منفصل عن مكوّنات Android التي تساهم في واجهة المستخدم (الأنشطة وأجزاء وطرق العرض). باستخدام Jetpack، يتم عادةً تنفيذ هذا الدور من خلال ViewModels، والتي لها فائدة إضافية تتمثل في مواجهة تغييرات الإعدادات (يُرجى الاطّلاع على نظرة عامة على ViewModel للحصول على مزيد من المعلومات).

عند تنفيذ تخطيط يتكيف مع الأحجام المختلفة، قد يكون من المغري استخدام نموذج بيانات مختلف بناءً على الحجم الحالي. ومع ذلك، فإن هذا يتعارض مع مبدأ تدفق البيانات أحادي الاتجاه. ينبغي أن تتدفق البيانات لأسفل إلى المشاهدات، ويجب أن تتدفق أحداث مثل تفاعلات المستخدم إلى أعلى. يؤدي إنشاء تبعية في الاتجاه الآخر، حيث يعتمد نموذج البيانات على تكوين طبقة واجهة المستخدم، إلى تعقيد ذلك بشكل كبير. عندما يتغير حجم التطبيق، يجب عليك بعد ذلك حساب التحويل من نموذج بيانات إلى آخر.

وبدلاً من ذلك، اسمح لنموذج البيانات الخاص بك باستيعاب أكبر فئة حجم، وبعد ذلك يمكنك عرض المحتوى أو إخفاؤه أو تغيير موضعه بشكل انتقائي في واجهة المستخدم للتكيّف مع فئة الحجم الحالية. فيما يلي بعض الاستراتيجيات التي يمكنك استخدامها عند تحديد كيف يجب أن يتصرف التخطيط عند الانتقال بين فئات الحجم.

توسيع المحتوى

التنسيقات الأساسية: الخلاصة

يمكن أن تمثل المساحة الموسعة فرصة ببساطة لتكبير الأشياء وإعادة تنسيق المحتوى الخاص بك بحيث يسهل الوصول إليه.

جعل المجموعات أكبر: يعرض العديد من التطبيقات مجموعة من العناصر في حاوية قابلة للتمرير، مثل RecyclerView أو ScrollView. يعني تمكين الحاوية أن تصبح أكبر تلقائيًا أنه يمكن عرض المزيد من المحتوى. ومع ذلك، يجب الحرص على ألّا يصبح المحتوى داخل الحاوية موسَّعًا أو مشوّهًا بشكل مفرط. على سبيل المثال، عند استخدام RecyclerView، ننصحك باستخدام مدير تنسيق مختلف، مثل GridLayoutManager أوStaggeredGridLayoutManager أو FlexboxLayout عندما لا يكون العرض مكثّفًا.

يمكن للعناصر الفردية أيضًا استخدام حجم أو شكل مختلف لعرض المزيد من المحتوى وتمييز حدود العناصر بسهولة أكبر.

ركِّز على أحد عناصر الجزء الرئيسي. إذا كان التخطيط يحتوي على نقطة محورية معينة، مثل صورة أو فيديو، فيمكنك توسيعه عندما تكبر نافذة التطبيق للحفاظ على انتباه المستخدم. يمكن إعادة ترتيب العناصر الداعمة الأخرى حول طريقة عرض الجزء الرئيسي أو أسفلها.

هناك عدة طرق لإنشاء مثل هذا التنسيق، لكن السمة ConstraintLayout مناسبة بشكل خاص لهذا الغرض لأنّها توفّر العديد من الطرق لتقييد حجم طريقة العرض الفرعية، بما في ذلك النسبة المئوية أو فرض نسبة العرض إلى الارتفاع ووضع عناصرها الثانوية بالنسبة إلى نفسها أو مع الأطفال الآخرين. تعرَّف على المزيد من المعلومات عن كل هذه الإمكانات في إنشاء واجهة مستخدم سريعة الاستجابة باستخدام ConstraintLayout.

عرض المحتوى القابل للتصغير تلقائيًا: عندما تكون هناك مساحة متاحة، اعرض المحتوى الذي لا يمكن الوصول إليه إلا من خلال تفاعل إضافي للمستخدم مثل النقر أو التمرير أو الإيماءات. على سبيل المثال، المحتوى الذي يظهر في واجهة ذات علامات تبويب عند ضغطه يمكن إعادة ترتيبه إلى أعمدة أو قائمة عندما تتوفر مساحة أكبر.

توسيع الهوامش إذا كانت المساحة كبيرة جدًا بحيث لا يمكنك العثور على ملاءمة جذابة حتى بعد استخدام كل المحتوى الخاص بك، فقم بتوسيع هوامش التخطيط حتى يظل المحتوى في الوسط ولتكون طرق العرض الفردية أحجام طبيعية ومسافات بينها.

بدلاً من ذلك، يمكن تحويل مكون ملء الشاشة إلى واجهة مستخدم مربع حوار عائم. هذا مناسب تمامًا عندما يتطلب هذا المكون تركيزًا حصريًا لإنجاز مهمة المستخدم الفورية، مثل إنشاء رسالة بريد إلكتروني أو إنشاء حدث تقويم.

إضافة محتوى

التنسيقات الأساسية: لوحة الدعم، عرض على شكل قائمة بالتفاصيل

استخدِم لوحة داعمة. تعرض لوحة الدعم محتوى إضافيًا أو إجراءات سياقية ذات صلة بالمحتوى الأساسي، مثل التعليقات في إحدى المستندات أو العناصر في قائمة تشغيل. عادةً ما تستخدم هذه الثلث السفلي من الشاشة للارتفاع الموسع أو الثلث اللاحق للعرض الموسع.

أحد الاعتبارات المهمة هو مكان وضع هذا المحتوى عندما لا توجد مساحة كافية لعرض الجزء. فيما يلي بعض البدائل لاستكشافها:

• الدرج الجانبي عند الحافة اللاحقة باستخدام DrawerLayout
• الدرج السفلي باستخدام BottomSheetBehavior
• الوصول إلى القائمة أو النافذة المنبثقة بالنقر على رمز القائمة

إنشاء تنسيق من لوحتين: قد تعرض الشاشات الكبيرة مجموعة من الميزات التي تظهر عادةً بشكل منفصل على الشاشات الأصغر. ومن أنماط التفاعل الشائعة في العديد من التطبيقات عرض قائمة بالعناصر، مثل جهات الاتصال أو نتائج البحث، والتبديل إلى تفاصيل العنصر عند تحديد العنصر. بدلاً من تكبير القائمة للشاشات الأكبر حجمًا، استخدم عرض تفاصيل القائمة لإظهار كلتا الميزتين جنبًا إلى جنب في تخطيط من لوحتين. على عكس الجزء الداعم، يعد جزء التفاصيل لعرض تفاصيل القائمة عنصرًا مستقلاً يمكن عرضه بشكل مستقل على الشاشات الأصغر.

استخدِم تطبيق SlidingPaneLayout المصغّر المخصَّص لتنفيذ عرض على شكل قائمة. تحتسب هذه الأداة تلقائيًا ما إذا كانت هناك مساحة كافية لعرض كلا اللوحتين معًا بناءً على قيمة layout_width المحددة للجزءين، ويمكن توزيع أي مساحة متبقية باستخدام layout_weight. عندما لا تكون هناك مساحة كافية، فإن كل جزء يستخدم العرض الكامل للتخطيط، وجزء التفاصيل إما أن ينزلق خارج الشاشة أو فوق جزء القائمة.

يحتوي إنشاء تخطيط من لوحتين على مزيد من التفاصيل حول استخدام SlidingPaneLayout. لاحظ أيضًا أن هذا النمط قد يؤثر في كيفية هيكلة الرسم البياني للتنقل (راجع التنقل لواجهات المستخدم سريعة الاستجابة).

مراجع إضافية

• التصميم المتعدد الأبعاد - تطبيق التنسيق