يجب أن تتوافق تطبيقات Android مع منظومة متكاملة ومتوسّعة باستمرار من أشكال الأجهزة. يجب أن يكون واجهة مستخدم التطبيق سريعة الاستجابة ليلائم مجموعة كبيرة من أحجام الشاشات، بالإضافة إلى الاتجاهات المختلفة وحالات الجهاز.
تركّز واجهة المستخدم سريعة الاستجابة على مبادئ المرونة والاستمرارية.
تشير المرونة إلى التنسيقات التي تستفيد إلى أقصى حد من المساحة المتاحة وتتكيف عند تغيُّر المساحة المتاحة. يمكن أن تتّخذ التعديلات أشكالًا متعددة، مثل زيادة حجم عرض واحد أو إعادة وضع العروض بحيث تكون في مواضع يسهل الوصول إليها أو عرض عروض إضافية أو إخفاؤها أو مزيج من هذه الإجراءات.
يشير التسلسل إلى توفير تجربة مستخدم سلسة أثناء الانتقال من حجم نافذة إلى آخر. يجب أن تستمر أي تجربة ينخرط فيها المستخدم بدون انقطاع. ولأنّ تغيير الحجم قد يؤدي إلى تدمير التسلسل الهرمي الكامل للعرض وإعادة إنشائه، من المهم أن لا يفقد المستخدم مكانه أو بياناته.
أمور يجب تجنّبها
تجنَّب استخدام القيم المادية للأجهزة عند اتّخاذ قرارات بشأن التنسيق. قد يكون من المغري اتّخاذ قرارات استنادًا إلى قيمة ثابتة، ولكن في العديد من الحالات، لا تكون هذه القيم مفيدة لتحديد المساحة التي يمكن أن يعمل بها واجهة المستخدم.
قد تواجه التطبيقات تغييرًا في حجم النوافذ عند تشغيلها في وضع "نوافذ متعددة" أو "نافذة ضمن نافذة" أو النوافذ ذات الشكل الحر، مثل ChromeOS. ويمكن أن يكون هناك أكثر من شاشة واحدة، مثل جهاز قابل للطي أو جهاز يحتوي على شاشات متعددة. وفي كل هذه الحالات، لا يُعدّ حجم الشاشة المادي مهمًا لتحديد كيفية عرض المحتوى.
وللسبب نفسه، تجنَّب قفل تطبيقك على اتجاه أو نسبته عرض إلى ارتفاع معيّنة. على الرغم من أنّ الجهاز نفسه قد يكون في اتجاه معيّن، قد يكون تطبيقك في اتجاه مختلف استنادًا إلى حجم نافذته فقط. على سبيل المثال، على جهاز لوحي في الوضع الأفقي أثناء استخدام وضع "نوافذ متعدّدة"، يمكن أن يكون التطبيق في الوضع العمودي لأنّه أطول من عرضه.
تجنَّب أيضًا محاولة تحديد ما إذا كان الجهاز هاتفًا أو جهازًا لوحيًا. إنّ تحديد الأجهزة التي تندرج ضمن فئة الأجهزة اللوحية هو أمر ذاتي إلى حدّ ما: هل يستند إلى امتلاك حجم معيّن أو نسبة عرض إلى ارتفاع معيّنة أو مزيج من حجم ونسب العرض إلى الارتفاع؟ مع ظهور أشكال جديدة للأجهزة، يمكن أن تتغيّر هذه الافتراضات، ويفقد التمييز أهميته.
بدلاً من تجربة أيّ من الاستراتيجيات السابقة، استخدِم نقاط الاستراحة وفئات حجم النافذة.
نقاط التوقف وفئات أحجام النوافذ
الجزء الفعلي من الشاشة المخصّص لتطبيقك هو نافذة التطبيق. وقد يشغل العنصر الشاشة بالكامل أو جزءًا منها، لذا استخدِم حجم النافذة عند اتخاذ قرارات عالية المستوى بشأن تنسيق تطبيقك.
عند التصميم لأشكال أجهزة متعددة، ابحث عن قيم الحدّ الأدنى التي تتفرع فيها هذه القرارات العالية المستوى في اتجاهات مختلفة. لتحقيق هذا الهدف، يوفّر شبكة التنسيق المتجاوب في Material Design نقاط توقّف للعرض والارتفاع، ما يتيح لك ربط الأحجام الأولية بمجموعات منتظمة ومفصّلة تُعرف باسم فئات أحجام النوافذ. بسبب استخدام التمرير العمودي بشكلٍ شائع، تهتم معظم التطبيقات في المقام الأول بفئات حجم العرض، لذا يمكن تحسين معظم التطبيقات لجميع أحجام الشاشات من خلال التعامل مع بضع نقاط توقّف فقط. (لمزيد من المعلومات عن فئات أحجام النوافذ، يُرجى الاطّلاع على استخدام فئات أحجام النوافذ.)
عناصر واجهة المستخدم الثابتة
تحدِّد إرشادات تنسيق 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، تُنفّذ فئات ViewModel هذا الدور عادةً، وهي توفّر ميزة إضافية تتمثل في استمرارها في العمل على الرغم من تغييرات الإعدادات (اطّلِع على نظرة عامة على فئة ViewModel للحصول على مزيد من المعلومات).
عند تنفيذ تنسيق يتكيّف مع أحجام مختلفة، قد يكون من المغري استخدام نموذج بيانات مختلف استنادًا إلى الحجم الحالي. ومع ذلك، فإنّ هذا يتعارض مع مبدأ تدفق البيانات أحادي الاتجاه. يجب أن تتدفق البيانات للأسفل إلى "المشاهدات"، ويجب أن تتدفق الأحداث، مثل تفاعلات المستخدِمين، للأعلى. يؤدي إنشاء تبعية في الاتجاه الآخر، حيث يعتمد نموذج البيانات على إعدادات طبقة واجهة المستخدم، إلى تعقيد هذا الأمر بشكل كبير. عندما يتغيّر حجم التطبيق، عليك مراعاة عملية التحويل من نموذج بيانات إلى آخر.
بدلاً من ذلك، يمكنك السماح لنموذج البيانات بتضمين أكبر فئة حجم، ثم يمكنك عرض المحتوى أو إخفائه أو تغيير موضعه في واجهة المستخدم بشكل انتقائي للتكيّف مع فئة الحجم الحالية. في ما يلي بعض الاستراتيجيات التي يمكنك استخدامها عند تحديد كيفية تصرف التنسيق عند الانتقال بين فئات الحجم.
توسيع المحتوى
التنسيقات الأساسية: خلاصة
يمكن أن تكون المساحة الموسّعة فرصة لتوسيع العناصر وإعادة تنسيق المحتوى لتسهيل الوصول إليه.
زيادة حجم المجموعات: تعرض العديد من التطبيقات مجموعة من العناصر في ملف شخصي
متحرك، مثل RecyclerView
أو ScrollView
. يتيح تفعيل ميزة "تكبير الحاوية تلقائيًا" عرض المزيد من المحتوى.
ومع ذلك، يجب الحرص على عدم التمدد المفرط للمحتوى داخل الحاوية أو تشويهه. على سبيل المثال، مع RecyclerView
، ننصحك باستخدام
مدير تنسيق مختلف مثل
GridLayoutManager
أو
StaggeredGridLayoutManager
أو
FlexboxLayout
عندما
يكون العرض غير مكثّف.
يمكن أيضًا أن تستخدم العناصر الفردية حجمًا أو شكلاً مختلفًا لعرض المزيد من المحتوى وتمييز حدود العناصر بسهولة أكبر.
إبراز عنصر رئيسي: إذا كان التنسيق يتضمّن نقطة تركيز معيّنة، مثل صورة أو فيديو، وسِّعه عند توسيع نافذة التطبيق للحفاظ على انتباه المستخدم. يمكن إعادة ترتيب العناصر الداعمة الأخرى حول عرض العنصر الرئيسي أو تحته.
هناك العديد من الطرق لإنشاء تنسيق مماثل، ولكن ConstraintLayout
هو
مناسب بشكل خاص لهذا الغرض لأنّه يوفّر العديد من الطرق لتحديد
حجم العرض الفرعي، بما في ذلك النسبة المئوية أو فرض نسبة قياس، ولتحديد مواضع العناصر الفرعية بالنسبة إلى بعضها أو إلى عناصر
أخرى. يمكنك الاطّلاع على مزيد من المعلومات حول كل هذه الإمكانات في مقالة
إنشاء واجهة مستخدم سريعة الاستجابة باستخدام ConstraintLayout.
عرض المحتوى القابل للطي تلقائيًا: عندما يكون هناك مساحة متاحة، اعرض المحتوى الذي لا يمكن الوصول إليه إلا من خلال تفاعل إضافي من العميل، مثل النقر أو الانتقال للأعلى أو للأسفل أو الإيماءات. على سبيل المثال، يمكن إعادة ترتيب المحتوى الذي يظهر في واجهة علامات تبويب عند تصغير الشاشة إلى عمودين أو قائمة عندما تتوفّر مساحة أكبر.
توسيع الهوامش: إذا كانت المساحة كبيرة جدًا ولا يمكنك العثور على تنسيق جذاب حتى بعد استخدام كل المحتوى، وسِّع هوامش التنسيق كي يظل المحتوى في المنتصف وتكون للعروض الفردية أحجام ومقاسات طبيعية وتكون المسافة بينها مناسبة.
بدلاً من ذلك، يمكن تحويل مكوّن ملء الشاشة إلى واجهة مستخدم حوار دوار. يكون هذا مناسبًا بشكل خاص عندما يتطلّب هذا المكوّن التركيز الحصري لإكمال مهمة فورية للمستخدم، مثل كتابة رسالة إلكترونية أو إنشاء حدث في التقويم.
إضافة محتوى
التنسيقات الأساسية: اللوحة الداعمة، عرض تفاصيل القائمة
استخدام لوحة داعمة: تعرِض اللوحة الداعمة محتوى إضافيًا أو إجراءات سياقية مرتبطة بالمحتوى الأساسي، مثل التعليقات في مستند أو العناصر في قائمة تشغيل. وعادةً ما تستخدم هذه الإعلانات الثلث السفلي من الشاشة للارتفاع الموسّع أو الثلث الأخير للعرض الموسّع.
من المهم تحديد مكان وضع هذا المحتوى عندما لا تكون هناك مساحة كافية لعرض اللوحة. في ما يلي بعض البدائل التي يمكنك استكشافها:
- الدرج الجانبي على الحافة الخلفية باستخدام
DrawerLayout
- الدرج السفلي باستخدام
BottomSheetBehavior
- قائمة أو نافذة منبثقة يمكن الوصول إليها من خلال النقر على رمز قائمة
إنشاء تنسيق ذي لوحتَين قد تعرض الشاشات الكبيرة مجموعة من الميزات التي تظهر عادةً بشكل منفصل على الشاشات الأصغر حجمًا. إنّ أحد أنماط التفاعل المشترَكة في العديد من التطبيقات هو عرض قائمة بالعناصر، مثل جهات الاتصال أو نتائج البحث، والتبديل إلى تفاصيل العنصر عند اختياره. بدلاً من تكبير القائمة على الشاشات الأكبر حجمًا، استخدِم عرض تفاصيل القائمة لعرض كلتا الميزتين جنبًا إلى جنب في تنسيق ذي لوحتَين. على عكس الشاشة الداعمة، فإنّ لوحة التفاصيل في عرض تفاصيل القائمة هي عنصر مستقل يمكن عرضه بشكل مستقل على الشاشات الأصغر حجمًا.
استخدِم أداة التنسيق المخصّصة
SlidingPaneLayout
لتطبيق عرض تفاصيل القائمة. يحتسِب هذا ال widget تلقائيًا ما إذا كانت هناك مساحة كافية لعرض كلا اللوحةَين معًا استنادًا إلى قيمة layout_width
المحدّدة لللوحتين،
ويمكن توزيع أي مساحة متبقية باستخدام layout_weight
. عندما لا يكون هناك
مساحة كافية، تستخدم كل لوحة العرض الكامل للتخطيط، ويتم إما تمرير لوحة التفصيل خارج الشاشة أو فوق لوحة القائمة.
يحتوي القسم إنشاء تخطيط ذي مربّعَين على المزيد من
التفاصيل حول استخدام SlidingPaneLayout
. يُرجى العلم أيضًا أنّ هذا النمط قد يؤدي إلى
التأثير في طريقة تنظيم الرسم البياني للتنقّل (اطّلِع على
التنقّل في واجهات المستخدم المتجاوبة).
مصادر إضافية
- التصميم المتعدد الأبعاد: تطبيق التنسيق
أفلام مُقترَحة لك
- ملاحظة: يتم عرض نص الرابط عندما تكون لغة JavaScript غير مفعّلة.
- إنشاء تنسيق ذي مربّعَين
- تصميم سريع الاستجابة/التكيُّف مع طرق العرض
- التنسيقات الأساسية