واجهات مستخدم iOS: القصص المصورة مقابل NIBs مقابل الكود المخصص

كثيرًا ما أسمع مطوري iOS يسألون بعض المتغيرات عن نفس السؤال الأساسي:

ما هي أفضل طريقة لتطوير واجهة المستخدم في iOS: من خلال Storyboards أو NIBs أو Code؟

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

أنا من رأيي أن الإجابة يجب أن تأخذ شكل سؤال مضاد واحد أو أكثر.

ما هي أفضل سيارة؟

اسمحوا لي أن أشرح بمثال خارج الموضوع. لنفترض أنني أريد شراء سيارة وأسألك سؤالًا واحدًا بسيطًا: "ما هو الخيار الأفضل؟"

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

• ما هي ميزانيتك؟
• كم عدد المقاعد التي تحتاجها؟
• هل تهتم باستهلاك الوقود؟
• ما هو شعورك تجاه السيارات الرياضية؟

من الواضح أنه لا يوجد شيء مثل سيارة جيدة أو سيئة ما لم يتم وضعها في سياق مناسب - هناك فقط سيارة جيدة أو سيئة بناءً على احتياجات معينة.

العودة إلى تصميم واجهة مستخدم iOS

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

بشكل عام ، هناك ثلاثة أنواع من أساليب تصميم واجهة المستخدم التي يمكنك اتباعها ، ولكل منها إيجابياته وسلبياته ، ومعجبيه وكارهيه:

• iOS Storyboards : أداة مرئية لتخطيط طرق عرض متعددة للتطبيق والانتقالات بينها.
• NIBs (أو XIBs) : يتوافق كل ملف NIB مع عنصر عرض واحد ويمكن وضعه في Interface Builder ، مما يجعله أداة مرئية أيضًا. لاحظ أن الاسم "NIB" مشتق من امتداد الملف (سابقًا .nib والآن .xib ، على الرغم من استمرار النطق القديم).
• كود مخصص : على سبيل المثال ، لا توجد أدوات واجهة المستخدم الرسومية ، ولكن بدلاً من ذلك ، التعامل مع جميع المواقع المخصصة والرسوم المتحركة وما إلى ذلك برمجيًا.

لا يعد أي من هذه الخيارات أفضل بشكل عام من أي خيار آخر (على الرغم مما قد تسمعه).

القصص المصورة ، على سبيل المثال ، هي أحدث إضافة إلى مجموعة أدوات iOS UI. لقد قيل لي إنهم المستقبل ، وأنهم سيحلون محل NIBs و UIs البرمجية المخصصة. أرى القصص المصورة كأداة مفيدة ، ولكن ليس بديلاً بقدر ما هو مكمل لـ NIBs والرمز المخصص. القصص المصورة هي الاختيار الصحيح في بعض المواقف وليس جميعها.

علاوة على ذلك ، لماذا يجب أن تلتزم بشكل ثابت بخيار واحد بينما يمكنك استخدامها جميعًا (في نفس المشروع) ، واختيار الآلية التي تناسب المشكلة المحددة المطروحة على أفضل وجه؟

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

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

iOS القصص المصورة

خطأ كلاسيكي للمبتدئين هو إنشاء Storyboard لنظام iOS واحد ضخم على مستوى المشروع. لقد ارتكبت هذا الخطأ أيضًا عندما بدأت العمل لأول مرة مع Storyboards (ربما لأنه طريق مغري لاتخاذه).

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

على سبيل المثال ، من المنطقي استخدام القصص المصورة عند التعامل مع:

• مجموعة من المشاهدات للمصادقة والتسجيل.
• تدفق إدخال أمر متعدد الخطوات.
• تدفق يشبه المعالج (أي برنامج تعليمي).
• مجموعة من طرق العرض الرئيسية التفصيلية (على سبيل المثال ، قوائم الملفات الشخصية وتفاصيل الملف الشخصي).

وفي الوقت نفسه ، يجب تجنب القصص المصورة الكبيرة ، بما في ذلك القصص المصورة على مستوى التطبيق الواحد (ما لم يكن التطبيق بسيطًا نسبيًا). قبل أن نتعمق أكثر ، دعونا نرى السبب.

حماقة القصص المصورة iOS الكبيرة

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

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

لنأخذ مثالًا بسيطًا للغاية: لنفترض أن مطورين مختلفين غيرا موضع UILabel (باستخدام تخطيط تلقائي) ، وهذا الأخير يدفع بتغييره ، مما ينتج عنه تعارض مثل هذا (لاحظ سمات id المتضاربة):

 <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/> </layoutGuides> <layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/> </layoutGuides>

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

للتخفيف من مشاكل تصميم واجهة iOS هذه ، فإن استخدام العديد من القصص المصورة في نفس المشروع هو النهج الموصى به.

متى تستخدم القصص المصورة

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

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

أخيرًا ، بينما تُستخدم القصص المصورة بشكل أفضل للسيناريوهات التي تتضمن وحدات تحكم متعددة في العرض ، فإنه من الممكن أيضًا استخدام Storyboard عند العمل مع وحدة تحكم عرض جدول واحدة لثلاثة أسباب:

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

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

عندما لا تستخدم لوحات عمل iOS

حالات قليلة:

• يحتوي العرض على تخطيط معقد أو ديناميكي ، وأفضل تطبيق مع الكود.
• تم تنفيذ العرض بالفعل باستخدام NIBs أو التعليمات البرمجية.

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

إيجابيات وسلبيات عامة

الآن بعد أن أصبح لدينا فكرة عن الوقت الذي تكون فيه القصص المصورة مفيدة في تصميم واجهة مستخدم iOS ، وقبل أن ننتقل إلى NIBs في هذا البرنامج التعليمي ، دعنا نستعرض مزاياها وعيوبها العامة.

المؤيد: الأداء

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

المؤيد: النماذج الأولية

تعمل القصص المصورة على تبسيط النماذج الأولية والاستنباط لواجهات المستخدم والتدفق . في الواقع ، يمكن تنفيذ تطبيق نموذج أولي كامل يعمل مع طرق العرض والتنقل بسهولة باستخدام Storyboards وقليل من أسطر التعليمات البرمجية.

السلبيات: قابلية إعادة الاستخدام

عندما يتعلق الأمر بالنقل أو النسخ ، فإن وضع لوحات العمل لنظام iOS ضعيف. يجب نقل Storyboard مع جميع وحدات التحكم في العرض التابعة لها. بمعنى آخر ، لا يمكن استخراج وحدة تحكم عرض واحدة بشكل فردي وإعادة استخدامها في مكان آخر ككيان مستقل واحد ؛ تعتمد على بقية لوحة العمل لتعمل.

يخدع: تدفق البيانات

غالبًا ما يلزم تمرير البيانات بين وحدات التحكم في العرض عند انتقال التطبيق. ومع ذلك ، يتم كسر التدفق المرئي لـ Storyboard في هذه الحالة نظرًا لعدم وجود أي أثر لهذا الحدوث في Interface Builder. تهتم القصص المصورة بمعالجة التدفق بين وحدات التحكم في العرض ، ولكن ليس تدفق البيانات. لذلك ، يجب تكوين وحدة التحكم في الوجهة برمز ، مما يتجاوز التجربة المرئية.

في مثل هذه الحالات ، يتعين علينا الاعتماد على prepareForSegue:sender ، بهيكل if / else-if مثل هذا:

 - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier isEqualToString@"segue_name_1"]) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier isEqualToString@"segue_name_2"]) { ... } else if ... }

أجد أن هذا الأسلوب عرضة للخطأ ومطول دون داع.

بنك الاستثمار القومي

NIBs هي الطريقة القديمة (إيه) لتنفيذ تصميم واجهة iOS.

في هذه الحالة ، لا تعني كلمة "قديم" "سيئ" أو "قديم" أو "مهمل". في الواقع ، من المهم أن نفهم أن القصص المصورة لنظام iOS ليست بديلاً عالميًا عن NIBs ؛ يقومون فقط بتبسيط تنفيذ واجهة المستخدم في بعض الحالات.

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

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

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

متى تستخدم NIBs لتصميم واجهة مستخدم iOS

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

• آراء مشروطة
• طرق عرض تسجيل الدخول والتسجيل البسيطة
• إعدادات
• النوافذ المنبثقة
• قوالب عرض قابلة لإعادة الاستخدام
• قوالب خلايا الجدول القابلة لإعادة الاستخدام

وفى الوقت نفسه…

عندما لا تستخدم NIBs

يجب تجنب استخدام NIBs من أجل:

• طرق العرض ذات المحتوى الديناميكي ، حيث يتغير التخطيط بشكل كبير اعتمادًا على المحتوى.
• طرق العرض التي بطبيعتها لا يمكن تصميمها بسهولة في Interface Builder.
• عرض وحدات التحكم ذات التحولات المعقدة التي يمكن تبسيطها باستخدام Storyboarding.

إيجابيات وسلبيات عامة

بشكل عام ، دعنا نتعرف على إيجابيات وسلبيات استخدام NIBs.

المؤيد: قابلية إعادة الاستخدام

تصبح بطاقات NIB مفيدة عند مشاركة نفس التخطيط عبر فئات متعددة.

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

Pro & Con: الأداء

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

كود iOS المخصص (واجهات مستخدم برمجية)

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

ربما الأهم من ذلك ، ما لا يمكن فعله مع NIBs و Storyboard يمكن دائمًا تنفيذه باستخدام كود - بشرط ، بالطبع ، أنه ممكن تقنيًا. هناك طريقة أخرى للنظر إليها وهي أن NIBs و Storyboards مطبقة برمز ، لذا فإن وظائفها ستكون بطبيعة الحال مجموعة فرعية. دعنا نقفز مباشرة إلى الإيجابيات والسلبيات.

المؤيد: تحت غطاء محرك السيارة

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

لإجراء مقارنة: الآلة الحاسبة هي أداة مفيدة. لكن معرفة كيفية إجراء العمليات الحسابية يدويًا ليس بالأمر السيئ.

هذا لا يقتصر على iOS ، ولكن على أي أداة RAD مرئية (على سبيل المثال ، Visual Studio و Delphi ، على سبيل المثال لا الحصر). تمثل بيئات HTML RAD المرئية حالة حدية نموذجية: يتم استخدامها لإنشاء كود (غالبًا ما يكون مكتوبًا بشكل سيئ) ، مدعيًا أنه لا توجد حاجة إلى معرفة HTML ، وأن كل شيء يمكن القيام به بشكل مرئي. لكن لن يقوم أي مطور ويب بتنفيذ صفحة ويب دون أن تتسخ يديه: فهم يعلمون أن التعامل يدويًا مع HTML و CSS الخام سيؤدي إلى كود أكثر نمطية وأكثر كفاءة.

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

المؤيد: عندما يكون الرمز هو الخيار الوحيد

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

المؤيد: دمج التعارضات

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

يخدع: النماذج الأولية

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

يخدع: إعادة بناء ديون

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

المؤيد: الأداء

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

المؤيد: قابلية إعادة الاستخدام

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

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

ستكون عملية تصميم واجهة المستخدم نفسها أكثر تعقيدًا مع NIBs و Storyboard. لا تسمح ملفات القوالب بالوراثة ، وتقتصر الحلول الممكنة على ما يلي:

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

متى تستخدم الكود

غالبًا ما تكون مكالمة جيدة لاستخدام رمز مخصص لتصميم واجهة مستخدم iOS عندما يكون لديك:

• تخطيطات ديناميكية.
• العروض ذات التأثيرات ، مثل الزوايا الدائرية والظلال وما إلى ذلك.
• أي حالة يكون فيها استخدام NIBs و Storyboard معقدًا أو غير عملي.

عندما لا تستخدم الكود

بشكل عام ، يمكن دائمًا استخدام واجهات المستخدم البرمجية. نادرًا ما تكون فكرة سيئة ، لذلك أضع ملف هنا.

على الرغم من أن NIBs و Storyboards تجلب بعض المزايا إلى الطاولة ، إلا أنني أشعر أنه لا يوجد جانب سلبي معقول أود وضعه في قائمة لتثبيط استخدام الكود (باستثناء ، ربما ، الكسل).

مشروع واحد ، أدوات متعددة

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

كيف تسأل؟ كيفما تشاء. فيما يلي بعض الطرق الممكنة:

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

في الختام ، دعنا نلقي نظرة على مثال أخير يربط كل ذلك معًا.

حالة استخدام بسيطة

لنفترض أننا نريد تطوير تطبيق مراسلة أساسي بعدة طرق عرض مختلفة:

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

بالإضافة إلى ذلك ، نريد أن تتدفق المشاهدات على النحو التالي:

• يؤدي النقر فوق عنصر في قائمة الأصدقاء المتابعين إلى عرض تفاصيل ملف تعريف الصديق ذي الصلة.
• تُظهر تفاصيل الملف الشخصي اسم الملف الشخصي والعنوان والإحصاءات وقائمة مختصرة بأحدث الرسائل وشريط الأدوات.

لتنفيذ تطبيق iOS هذا ، ستكون أدوات واجهة المستخدم الثلاثة مفيدة ، حيث يمكننا استخدام:

• لوحة عمل بأربعة عناصر تحكم في العرض (القائمة ، والتفاصيل ، وقائمة الرسائل ، ونموذج الرسالة الجديد).
• ملف NIB منفصل لقالب خلية قائمة ملف التعريف القابل لإعادة الاستخدام.
• ثلاثة ملفات NIB منفصلة لعرض تفاصيل الملف الشخصي ، واحد لكل قسم من الأقسام المنفصلة التي يتكون منها (تفاصيل الملف الشخصي ، الإحصائيات ، الرسائل الثلاثة الأخيرة) ، للسماح بصيانة أفضل. سيتم إنشاء مثيل NIBs هذه كطرق عرض ثم إضافتها إلى وحدة التحكم في العرض.
• كود مخصص لعرض سحابة العلامات. هذا العرض هو مثال نموذجي لما لا يمكن تصميمه في Interface Builder ، لا من خلال StoryBoards أو NIBs. بدلاً من ذلك ، يتم تنفيذه بالكامل من خلال التعليمات البرمجية. من أجل الحفاظ على التدفق المرئي لـ Storyboard ، نختار إضافة وحدة تحكم عرض فارغة إلى Storyboard ، وتنفيذ طريقة عرض علامة السحاب كعرض مستقل ، وإضافة العرض برمجيًا إلى وحدة التحكم في العرض. من الواضح أنه يمكن أيضًا تنفيذ العرض داخل وحدة التحكم في العرض بدلاً من العرض المستقل ، لكننا نبقيها منفصلة لإعادة الاستخدام بشكل أفضل.

قد يبدو النموذج الأساسي حقًا كما يلي:

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

تغليف

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

إذا أثار هذا المقال فضولك ، فإنني أوصي بشدة بمشاهدة النقاش الرائع من Ray Wenderlich ، حيث قضيت 55 دقيقة جيدًا في مناقشة NIBs ، و Storyboards ، و UIS المصنوع من الكود.

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