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

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

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

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

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

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

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

عند تشغيل التطبيقات في وضع النوافذ المتعددة أو "نافذة ضمن النافذة" أو النوافذ الحرة، مثل ChromeOS، قد يتم تغيير حجم النوافذ في التطبيقات. يمكن أن يكون هناك أكثر من شاشة مادية واحدة، كجهاز قابل للطي أو جهاز به شاشات متعددة. في كل هذه الحالات، لا يكون حجم الشاشة الفعلي ذا صلة بتحديد كيفية عرض المحتوى.

الشكل 1. يمكن أن تختلف أحجام النوافذ عن حجم الجهاز أو حجم الشاشة.

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

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

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

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

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

عند التصميم لعوامل شكل متعددة، ابحث عن قيم الحد التي تتفرع فيها هذه القرارات عالية المستوى في اتجاهات مختلفة. وتحقيقًا لهذه الغاية، توفر شبكة التخطيط سريع الاستجابة في تصميم 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 عندما لا يكون العرض مكثفًا.

الشكل 2. مدراء تنسيق مختلفون لفئات مختلفة من أحجام النوافذ.

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

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

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

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

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

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

الشكل 3. تم تحويل مربع حوار بملء الشاشة إلى مربع حوار عادي بعرض متوسط وموسّع.

إضافة محتوى

التنسيقات الأساسية: جزء الدعم، عرض تفاصيل القائمة

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

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

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

الشكل 4. يمكنك استخدام طرق بديلة لتقديم محتوى إضافي في لوحة الدعم.

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

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

الشكل 5. تطبيق SlidingPaneLayout يعرض جزأين بعرض موسّع وجزء واحد بعرض مضغوط.

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

مصادر إضافية

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