البحث في الموقع

تتكوّن تطبيقات الأجهزة المحمولة عادةً من صفحات منفصلة يتنقّل بينها المستخدم لاستفادة من الإمكانيات التي يقدمها التطبيق. بالنسبة لتطبيقات أندرويد فإنّ زر الرجوع إلى الخلف يُعتبر أساسيًا في عمليّة التنقّل هذه. سنتعرّف في هذا الدرس من سلسلة تعلّم برمجة تطبيقات أندرويد باستخدام Xamarin.Forms على كيفيّة التنقّل بين صفحات التطبيق. سنتحدّث أولًا عن مفهوم التنقّل بين الصفحات في التطبيق الواحد، ثمّ سنتحدّث عن أنواع صفحات المحتوى المستخدمة في التنقّل وذلك عن طريق مثال عملي بسيط. مفهوم التنقّل بين صفحات التطبيق يشبه التنقّل بين صفحات التطبيق مبدأ عمل المكدّس Stack إلى حدّ كبير. والمكدّس كما هو معلوم هو بنية معطيات تدعم مفهوم LIFO (الذي يدخل أخيرًا يخرج أولًا). فعند الانتقال من الصفحة A إلى الصفحة B، تُدفع pushed الصفحة B إلى أعلى المكدّس مما يؤدّي إلى ظهورها أمام المستخدم. وكذلك الأمر عند الانتقال من الصفحة B إلى الصفحة C يتم دفع الصفحة C إلى المكدّس ليتم إظهارها إلى المستخدم. أمّا عندما نريد العودة إلى الصفحة A الأصلية فيجب عندها أن تُخرج popped الصفحة C من المكدّس فتصبح الصفحة B أعلى المكدّس (أي تظهر للمستخدم) ثم تُخرج الصفحة B من المكدّس فتصبح الصفحة A أعلى المكدّس (أي تظهر للمستخدم). انظر الشكل التالي لتوضيح هذه الفكرة: صفحات Modal و Modeless يحتوي على كل تطبيق على صفحة رئيسيّة main page (ستكون من الصنف NavigationPage) تُعتبر العقدة الرئيسيّة التي يمكن الوصول من خلالها إلى جميع الصفحات الأخرى مهما كان عددها ومستواها. كما تميّز Xamarin بين نوعين من صفحات المحتوى التي تُستَخدم ضمن بنية التنقّل هذه وهي: الصفحات الجامدة Modal Pages والصفحات غير الجامدة Modeless Pages. الفرق بين هذين النوعين بالنسبة لتطبيقات أندرويد بسيط. وهو أنّه في الصفحات من النوع Modal لن يتم عرض عنوان الصفحة في الأعلى كما سنرى في المثال بعد قليل. أمّا في الصفحة من النوع Modeless فسيتم عنوان الصفحة في الأعلى في حال تمّ تحديده باستخدام الخاصيّة Title لصفحة المحتوى. لمعاينة الفرق بين هذه الأنواع لننشئ تطبيق عملي بسيط يوضّح هذا الأمر. ابدأ بإنشاء مشروع جديد من النوع Blank App (Xamarin.Forms Portable) وسمّه ModelessAndModal، ثم أبق فقط على المشروعين ModelessAndModal (Portable) و ModelessAndModal.Droid كما وسبق أن فعلنا في هذا الدرس. بعد ذلك سنضيف ثلاث صفحات محتوى عادية (Forms ContentPage) وهي: MainPage و ModalPage و ModelessPage. عدّل محتويات الملف MainPage ليكون مماثلًا لما يلي: 1 using Xamarin.Forms; 2 3 namespace ModelessAndModal 4 { 5 public class MainPage : ContentPage 6 { 7 public MainPage() 8 { 9 Title = "Main Page"; 10 11 Button gotoModelessButton = new Button 12 { 13 Text = "Go to Modeless Page", 14 HorizontalOptions = LayoutOptions.Center, 15 VerticalOptions = LayoutOptions.CenterAndExpand 16 }; 17 18 gotoModelessButton.Clicked += async (sender, args) => 19 { 20 await Navigation.PushAsync(new ModelessPage()); 21 }; 22 23 Button gotoModalButton = new Button 24 { 25 Text = "Go to Modal Page", 26 HorizontalOptions = LayoutOptions.Center, 27 VerticalOptions = LayoutOptions.CenterAndExpand 28 }; 29 30 gotoModalButton.Clicked += async (sender, args) => 31 { 32 await Navigation.PushModalAsync(new ModalPage()); 33 }; 34 35 Content = new StackLayout 36 { 37 Children = { gotoModelessButton, gotoModalButton } 38 }; 39 } 40 } 41 } ستعرض الصفحة الرئيسية MainPage زرّين فقط. الزر الأوًل هو gotoModelessButton ووظيفته إنشاء صفحة غير جامدة modeless والانتقال اليها. أمّا الزر الثاني فهو gotoModalButton ووظيفته إنشاء صفحة جامدة modal والانتقال إليها. بالنسبة للزر الأوّل gotoModelessButton انظر إلى الأسطر من 11 حتى 21: Button gotoModelessButton = new Button { Text = "Go to Modeless Page", HorizontalOptions = LayoutOptions.Center, VerticalOptions = LayoutOptions.CenterAndExpand }; gotoModelessButton.Clicked += async (sender, args) => { await Navigation.PushAsync(new ModelessPage()); }; ننشئ في البداية كائنًا من النوع Button ونسنده إلى المتغيّر gotoModelessButton ثمّ نعيّن معالج لحدث النقر Clicked وهو عبارة عن تعبير lambda بسيط يمثّل تابع يحتاج إلى وسيطين sender و e وهو مسبوق بالكلمة المحجوزة async كما هو واضح من الشيفرة السابقة. سبب وجود الكلمة async هو أنّنا سنستخدم استدعاءً غير متزامنًا ضمن معالج الحدث هذا وهو: await Navigation.PushAsync(new ModelessPage()); يعمل التابع PushAsync المُستدعى من الخاصيّة Navigation للصفحة الحالية على دفع صفحة جديدة ضمن المكدّس الخاص بالتنقّل بين الصفحات، بمعنى آخر، سيعمل هذا التابع على إظهار صفحة جديدة من النمط modeless. في السطر السابق سيتم إنشاء صفحة جديدة من النوع ModelessPage ومن ثمّ تمريرها إلى التابع PushAsync. أنصحك بمراجعة هذا الدرس لكي تنعش ذاكرتك حول موضوع الاستدعاءات غير المتزامنة. نفس الأمر سيجري تمامًا بالنسبة للزر الخاص بالانتقال إلى الصفحة الجامدة مع فارق بسيط. وهو أنّ الاستدعاء هذه المرة سيكون من خلال التابع PushModalAsync (السطر 32) وذلك للانتقال إلى صفحة جامدة (ستكون من الصنف ModalPage). في كلّ من الحالتين السابقتين كان من الممكن أن نجعل معالجي حدثي النقر ضمن تابعين مستقلين وليس كما هو الحال من خلال تعبيري Lambda. الأمر الجدير بالملاحظة بالنسبة للصنف MainPage أيضًا هو تعيين الخاصيّة Title (السطر 9). في الحقيقة لم يكن لهذه الخاصيّة أي معنى في جميع البرامج التي أنشأناها في هذه السلسلة حتى الآن. إذ تعيين هذه الخاصيّة من عدمه لن يُحدث أيّ فرق! الجديد هنا هو في كيفيّة إنشاء الصفحة MainPage بحد ذاتها، والتي سننشئها كم جرت العادة ضمن الصنف App. انتقل إلى الملف App.cs واحرص على أن تكون بانيته مطابقة لما يلي: public App() { // The root page of your application MainPage = new NavigationPage(new MainPage()); } لاحظ معي الأمر الجديد هنا. نحن لا ننشئ صفحة محتوى ونسندها للخاصيّة MainPage مباشرةً كما كنّا نفعل من قبل. إنّما ننشئ صفحة محتوى (في مثالنا هي من الصنف MainPage) ثم نمرّر هذه الصفحة كوسيط إلى بانية الصنف NavigationPage. أي أنّنا في الواقع ننشئ صفحة محتوى تدعم التنقّل navigation. وهذا ما سيجعل عنوان الصفحة الرئيسيّة المُعيّن باستخدام الخاصيّة Title يظهر أعلى الصفحة كما سنرى بعد قليل. يمكننا الآن أن نجرّب هذا التطبيق. نفّذ التطبيق لتحصل على شكل شبيه بما يلي: أوقف تنفيذ البرنامج لنبدأ بالمرحلة الأخيرة وهي تجهيز صفحتي المحتوى ModalPage و ModelessPage. انتقل إلى الملف ModalPage.cs واحرص على أن تكون محتوياته مطابقة لما يلي: using Xamarin.Forms; namespace ModelessAndModal { public class ModalPage : ContentPage { public ModalPage() { Title = "Modal Page"; Button goBackButton = new Button { Text = "Back to Main", HorizontalOptions = LayoutOptions.Center, VerticalOptions = LayoutOptions.Center }; goBackButton.Clicked += async (sender, args) => { await Navigation.PopModalAsync(); }; Content = goBackButton; } } } ثمّ انتقل إلى الملف ModelessPage.cs واحرص على أن تكون محتوياته كما يلي: using Xamarin.Forms; namespace ModelessAndModal { public class ModelessPage : ContentPage { public ModelessPage() { Title = "Modeless Page"; Button goBackButton = new Button { Text = "Back to Main", HorizontalOptions = LayoutOptions.Center, VerticalOptions = LayoutOptions.Center }; goBackButton.Clicked += async (sender, args) => { await Navigation.PopAsync(); }; Content = goBackButton; } } } محتويات كلّ من الصفحتين السابقتين متطابقة. فكل منهما يحتوي على زر اسمه goBackButton هدفه العودة إلى الصفحة السابقة (التي سببت ظهور الصفحة الحالية). هناك فرق بسيط وحيد بين معالجي حدثي النقر للزرين في الصفحتين السابقتين. بالنسبة للصفحة من النمط الجامد modal تم استخدام الاستدعاء غير المتزامن Navigation.PopModalAsync للعودة إلى الصفحة السابقة. أمّا في حالة الصفحة ذات النمط غير الجامد modeless فقد تمّ استخدام الاستدعاء غير المتزامن Navigation.PopAsync للعودة إلى الصفحة السابقة. ثمة فرق آخر عند تنفيذ البرنامج، وهو أنّه في حالة الانتقال من الصفحة الرئيسية إلى الصفحة ModelessPage (الصفحة غير الجامدة) سيظهر عنوان الصفحة في الأعلى مع سهم صغير يسمح لنا بالعودة إلى الصفحة السابقة. أمّا عند الانتقال من الصفحة الرئيسية إلى الصفحة ModePage (الصفحة الجامدة) فلن يظهر عنوان الصفحة أبدًا (رغم تعيين الخاصيّة Title لها)، والوسيلة الوحيدة للرجوع إلى الصفحة السابقة هي بنقر زر الرجوع الموجود ضمن الصفحة أو بنقر زر العودة إلى الوراء الذي يزوّدنا به نظام التشغيل. أجرِ بعض التجارب على التطبيق ولاحظ الفرق بين الصفحتين. الخلاصة تناولنا في هذا الدرس آلية التنقّل بين الصفحات في تطبيقات أندرويد، وهو موضوع مهمّ بالطبع. حيث تعرّفنا إلى الفرق بين الصفحات من النمط modal والنمط modeless. كما تعلّمنا كيفية إنشاء الصفحة الرئيسيّة التي تُعتبر حجر البناء الأساسي في عمليّة الانتقال بين الصفحات، وذلك من خلال إنشاء الصفحة الرئيسيّة لتكون من النوع NavigationPage.

صناديق التغشية Overlays، صناديق المحادثة Dialog boxes نوافذ منبثقة Modal windows، سمّها ما شئت، تلك النّوافذ الصغيرة التي تنبثق في منتصف الشاشة وتشدّ انتباهك قد استخدمت كثيرًا (وأحيانًا بشكل خاطئ) في عالم التّصميم. تزايد استخدام النوافذ المنبثقة في التطبيقات، الويب وحتى على الهواتف لجذب انتباه المستخدم إلى مهمة فرعية دون أخذه إلى شاشة مختلفة. يمكن للنوافذ المنبثقة أن تُستعمل على نحو مساعد ومؤثر في التصميم، لكنّك إذا استعملتها كثيرًا ستُزعج المستخدم حتمًا. تأكد من عدم تنفير/إزعاج مستخدميك بالنوافذ المنبثقة عبر أخذ القوانين العشرة التالية بعين الاعتبار. 1. قلل من استخدام النوافذ المنبثقة قدر الإمكان ستحاول النوافذ المنبثقة دائمًا جذب انتباهك إليها. سيضطر المستخدمون إلى التعامل مع النافذة المنبثقة قبل إكمال مهماتهم الأصلية وسيمنعهم ذلك من الوصول إلى الصفحة المغطاة بالنافذة. قد يبدو هذا أمرًا جيّدًا، كأن يتوجب على المستخدم إعطاء موافقته على فعلٍ مهم، لكن استخدام النوافذ المنبثقة يكون في أغلب الوقت غير ضروري ومزعجًا إلى حد لا يطاق. بدلًا من استخدام نافذة منبثقة، من الأفضل غالبًا أن تظهر المحتوى الذي كنت ستضعه داخل النافذة المنبثقة ضمن سياق الصفحة. يمكنك فعل ذلك عبر توسعة جزء من الصفحة على سبيل المثال، عبر استخدام Static Popover أو بتبديل عناصر الواجهة. تستخدم شبكة "LinkedIn" بديلًا جيّدًا للنوافذ المنبثة في صفحات الأعضاء لديهم (انظر أدناه). فبدلًا من استخدام طريقة التصميم المعتادة وإظهار نافذة منبثقة ليتمكن المستخدم من تعديل حقل إدخال، يستطيع المستخدم الضغط على حقلٍ وتعديله بينما يكون في نفس الصفحة. تسمح شبكة "LinkedIn" لمستخدميها بأن يعدّلوا حقلًا داخل الصفحة مباشرة بدلًا من استخدام نافذةٍ للتعديل. في حين أن تويتر تستخدم نافذة منبثقة لكتابة تغريدة جديدة على نحوٍ غريب، فإنّها تمكّن المستخدمين أيضًا من إدخال تغريدتهم على الصفحة الرئيسية (انظر الصورة أدناه). إنها تجربة استخدام أفضل بكثير لأن المستخدم ما زال قادرًا على استخدام الصفحة (كأن ينسخ ويلصق نصًّا على سبيل المثال) وما زال غير مقيّد بنافذة منبثقة. بدلًا من فتح نافذة منبثقة أظن بأن من الأفضل لهم توسعة شريط التصفح في الأعلى (انظر المثال أدناه) بحيث يتمكن المستخدم دائمًا من إدخال تغريدته ضمن الصفحة. تستخدم شبكة Twitter نافذة منبثقة لكي يتمكن المستخدم من كتابة تغريدة جديدة. من الأفضل لـ Twitter أن يسمح للمستخدم بكتابة تغريدته داخل الصفحة. من المنطقي جدًا أن تستخدم النوافذ المنبثقة في حالات تحتاج خلالها من المستخدم أن يقوم بفعل ما قبل الاستمرار، أو حين تكون تكلفة الخطأ في العملية الجارية مرتفعة. وكمثال على هذه الحالات: إظهار نافذة منبثقة عند التأكيد على حذف شيء، أو عند إدخال البريد الإلكتروني لتحميل كتاب إلكتروني. 2. لا تظهر النوافذ المنبثقة فجأة إظهار نافذة منبثقة قبل أن يفعل المستخدم أي شيء ليس بفعلٍ حسن ولا ذكي، والواجب عليك هو ألّا تفعله، يجب أن تظهر النوافذ المنبثقة دائمًا بناءً على فعلٍ صدر عن المستخدم. قد يكون هذا الفعل ضغط زر، اتباع رابط أو تحديد خيار. ينطبق هذا أيضًا على نوافذ الدعوات لملء الاستبيانات. لا تظهر هذه النوافذ فحسب، بل اعرض الدعوة أثناء تحميل صفحة جديدة، أو افعل ما هو أفضل من ذاك، كأن تضمّن الدعوة داخل الصفحة. 3. أضف تغشية سوداء على الصفحة خلف النافذة المنبثقة من المهم حين تنبثق نافذة ما أن تسودّ الصفحة الخلفية قليلًا، لهذا الأمر فائدتان. الأولى هو أنه يصرف الانتباه إلى النافذة المنبثقة، والثاني هو أنه يعلم المستخدم بكون الصفحة حاليًا غير قابلةٍ للاستخدام. مع ذلك، كن حذرًا حيال إضافة هذه التغشية. فإن كانت شديدة السواد لن يعرف المستخدم في أي صفحةٍ هو. وإن كانت شديدة البياض فسيظن المستخدم أن الصفحة ما زالت قابلةً للاستخدام وقد لا ينتبهون إلى النافذة المنبثقة أصلًا. 4. دع المستخدم يغلق النافذة بالنقر (اللمس) خارجها تأتي النوافذ المنبثقة بنوعين. الأول هو النوافذ المنبثقة التي تشدّ الانتباه وترغم المستخدم على التفاعل معها قبل الإكمال. والثاني هو النوافذ التي تسمح للمستخدم بالضغط أو اللمس خارجها لإخفائها. كقاعدةٍ عامة يجب عليك استخدام النوافذ المنبثقة (من النوع الأول) للتفاعلات بالغة الأهمية، كمثال، حين تطلب من المستخدم أن يؤكد على طلبه لحذف حسابه، أو أنّه يوافق على سياسة الاستخدام والخصوصية التي يسجّل من أجلها. من الأفضل في أغلب الأحيان أن تستعمل نوافذ تسمح للمستخدمين بالضغط (أو اللمس) خارجها لإخفائها أو إلغائها. 5. وفر دائما زر إغلاق واضح إكمالًا للنقطة السابقة، ليس على المستخدم أن يضغط (أو يلمس) خارج النّافذة لإغلاقها، بل يجب عليك أيضًا أن توفّر خيار إغلاقٍ في الزاوية العلوية اليمنى (أو اليُسرى، إن كانت لغة الموقع تُكتب من اليمين إلى اليسار)، ومن الأفكار الجيّدة أيضًا أن تضمّن خيار إلغاءٍ أو إغلاقٍ إضافي داخل النافذة المنبثقة، في العادة كرابطٍ أو زر. يوفّر متجر "John Lewis" زر إغلاقٍ واضح في أعلى يمين نوافذ الانبثاق خاصتهم. 6. لا تضمن أكثر من خطوة في نفس النافذة إذا كان التفاعل المطلوب معقدًًا بما فيه الكفاية ليتطلّب أكثر من خطوة، فسيكون هذا التفاعل معقّدًا بما فيه الكفاية ليحصل على صفحته الخاصة، ولكي تحصل على المساحة والمرونة التي توفّرها الصفحة أكثر من النافذة المنبثقة، حاول تجنّب استعمال النوافذ التي تتضمّن أكثر من خطوةٍ داخلها كالنافذة الظاهرة أدناه من Barclays Bank، لعل تحليل مهمّة معقّدة إلى خطواتٍ مبسّطة فكرةٌ مذهلة، لكنها أيضًا علامة على أن هذه المهمة أعقد من أن تطلب من المستخدمين إكمالها داخل نافذةٍ منبثقة. حاول تجنّب النوافذ المنبثقة العملاقة كهذه النافذة من Braclays Bank. 7. لا تحشر الكثير داخل النافذة المنبثقة من الواجب عليك ألّا تحاول ملء النافذة المنبثقة بالكثير من العناصر، أبقِ النوافذ المنبثقة التي تصنعها نظيفة وبسيطة، إذا لاحظت أنك تحاول ملء النافذة المنبثقة بالكثير من العناصر فهذا سيعني عمومًا بأن النافذة المنبثقة ليست الخيار الأفضل. 8. ضمن المعلومات المهمة من المهم أن لا تخفي نافذة منبثقة المعلومات المهمة والتي قد تكون مفيدة للمستخدمين، كالأسعار مثلًا. في الواقع، من الواجب أن تتضمن النافذة المنبثقة أي معلومات مهمة. فكمثالٍ على ذلك، إذا ظهرت نافذة منبثقة تطلب من المستخدم تأكيد حذف بعض العناصر، سيكون من المفيد أن تسرد النافذة تلك العناصر التي ستحذف. 9. تجنب استخدام النوافذ المنبثقة على الهواتف من الجيّد عمومًا أن تتجنّب استخدام النوافذ المنبثقة على الهواتف. على شاشات الهواتف الصغيرة لا بد أن تأخذ النافذة المنبثقة كامل عرض الشاشة (فآخر أمر ترغب حدوثه هو أن يكون لديك نافذة منبثقة بالغة الصغر على الهاتف)، فلماذا لا تستخدم صفحةً بدلًا من ذلك؟ إذا استخدمت النوافذ المنبثقة في تصميمٍ متجاوب فسيكون من السهل غالبًا الحفاظ على نفس السلوك عبر مختلف الأجهزة. لذلك، من المهم التأكد أن أي نافذة منبثقة تستخدمها تناسب الهاتف. وكمثالٍ على ذلك، نوافذ Bootstrap المنبثقة (انظر الصورةَ أدناه) تعمل على نحوٍ متساوٍ بطريقة جيّدة في الأجهزة المحمولة -سطح المكتب- والهاتف معًا. بما أن النوافذ المنبثقة على الهاتف ستتطلّب غالبًا النزول والصعود بالشاشة، ستكون إضافة زر إغلاق أو إلغاء في الأعلى والأسفل فكرةً جيّدة. تأكّد من أن أي نافذة منبثقة تستعملها هي نافذة مناسبة للهاتف، كما هي نوافذ Bootstrap المنبثقة. 10. تحقق من قابلية وصول النوافذ المنبثقة من الواضح أن أخذ القابلية للوصول Accessibility بعين الاعتبار أمرٌ مهم لأي تصميم، ولذلك من المهم التأكد من كون أي نافذة منبثقة تُراعي قابلية الوصول. وكمثال، تأكد من أن التركيز focus موجّه إلى النافذة المنبثقة عند فتحها (بدلًا من البقاء في الصفحة الحالية) بحيث يتمكّن المستخدم من التصفّح باستعمال لوحة مفاتيحه. تأكد أيضًا من كون زر الإغلاق يمتلك لصيقة label تعريفيًّة مناسبًة لمستخدمي أدوات قراءة الشاشة. ترجمة -وبتصرف- للمقال: guidelines to consider when using overlays / modals لصاحبه Neil Turner.