تعد MVC معيارًا قديمًا في أنماط التصميم المستخدمة لكتابة تطبيقات iOS. استندت بنية تطبيقات iOS التي تم إنشاؤها مسبقًا إلى مكون أساسي واحد ، موجود في كل مكان ، ويسمى "
المراقب المالي" .
تم تقديم SwiftUI ، الذي لا يحتوي على مثل هذا المكون ، في
WWDC19 .
يجب أن يتم حل المشكلة مع ما يسمى
وحدات تحكم العرض الهائل في SwiftUI. لذلك ، تحتاج إلى العثور على طريقة جديدة لتحليل الرمز بشكل صحيح. دعونا نلقي نظرة على الوضع الحالي للمنصة ونفكر في النماذج التي يمكننا استخدامها عند تطوير iOS13 والإصدارات الأحدث.
بنيات أحادية الاتجاه وثنائية الاتجاه
معظم الحلول المعمارية التي تستخدمها الشركات الكبرى هي ثنائية الاتجاه. هذا يعني أنه بإمكانك التفكير فيها كطبقات فوق بعضها البعض ويمكنهم التواصل مع بعضهم البعض بنقل البيانات لأعلى ولأسفل. أنماط مثل MVC و Model-View-ViewModel ، وحتى العديد من تطبيقات نمط MVVM مع المنسقين هي أيضًا هياكل ثنائية الاتجاه.
مثال على تدفق البيانات أحادي الاتجاه المستخدم حاليًا على نظام iOS هو حلقة VIP (العرض التقديمي التفاعلي) في تصميم Clean Swift أو Viper. هذه البنى ليست أحادية الاتجاه. يتصل الموجّه والتنفيذي بحلقة VIP في كلا الاتجاهين.
شيء آخر يمكننا ملاحظته هو أن نمط MVC والأنماط الأخرى المبنية على أساسه تعتمد بشكل أكبر على شاشة واحدة. عادةً لا يوجد هيكل واضح لخدمات الكتابة ، الوحدات النمطية ، وما إلى ذلك ، التي تتفاعل مع أجزاء مختلفة من التطبيق.
تدفق البيانات في SwiftUI
وفقًا للعرض التقديمي الخاص بـ WWDC ، كان العنصر الذي يربط طريقة العرض والطراز / الحالة في SwiftUI فئة تخزين معينة ، متوافقة مع بروتوكول
BindableObject . لا يمكننا إلا أن نأمل ألا يكون لدينا تطبيقات بها متجر ضخم يحتوي على كل منطق التطبيق مع جميع الولايات دون أي بنية واضحة. أعتقد أن مجتمع iOS متطور جدًا ويمكنه أن يحقق أداءً أفضل في هذا الاتجاه.
إذا وضعنا MVC و SwiftUI في طريقة العرض والتخزين بجانب بعضنا البعض ، فيمكننا أن نرى نفس القالب تقريبًا ، مما قد يؤدي إلى مشاكل مماثلة التي واجهناها مع وحدة تحكم العرض ، ولكن بدون أي رمز قياسي يفيد VC لديه في الطبيعة.
إذا وضعت MVC وقمت بتخزينه في مخطط ، فقد يبدو الأمر كهذا.للوهلة الأولى ، قد يبدو أن الجمع بين النموذج المعماري المستخدم في SwiftUI. لكن الجمع هو مجرد أداة لمعالجة القيم مع مرور الوقت. وبالمثل ، لا يزال MVVM باستخدام RxSwift هو MVVM ، مجرد رابط بين الطبقات ، والذي يتم تنفيذه بعدة طرق.
التصميم التعريفي لواجهات المستخدم التعريفي
يمكن تلخيص SwiftUI في بضع كلمات ، مثل
واجهة المستخدم التعريفي . أعتقد أنه يمكن تحقيق المزيد إذا كنت تفكر خارج الصندوق وتركز على كلمة "
إعلاني ". يمكن العثور على الأمثلة المعمارية التصميمية الأكثر تقدمًا في تطوير التطبيقات الأمامية. مفاهيم مثل ELM و Redux و Flux يمكن استخدامها بسهولة مع SwiftUI و Combine. كان لدى Swift بالفعل العديد من عمليات إعادة التنفيذ مثل
ReSwift ، ولكن سيكون من الضروري دمج هذه التطبيقات في
Combine .
معدل تدفق البيانات المعدل قليلاً في SwiftUI من WWDC19أرغب في اللعب مع SwiftUI منذ البداية دون أي تبعيات ، وأنا أجرب حاليًا في Swift بتطبيق بسيط لبنية ELM. تتوافق هذه البنية بشكل أفضل مع المخططات التي أظهرتها Apple في WWDC.
يمكننا وصف التطبيق من خلال هذه الأنماط المعمارية:
- الإجراء هو نوع يصف جميع الأحداث التي يمكن أن تحدث في تطبيق ما. (في تطبيق بسيط ، قد يكون هذا بمثابة تعداد مع بعض القيمة المرتبطة ؛ في تطبيق واسع النطاق ، يمكنك استخدام العديد من الهياكل التي تتوافق مع بروتوكول الإجراء.)
- التحديث (أو المخفض في Redux) هو وظيفة نظيفة بسيطة تأخذ الحالة الحالية والإجراء المقدم وتعيد الحالة الجديدة المتغيرة. (هذه الميزات لا تنشئ آثارًا جانبية ويمكن دمجها بسهولة.)
- الحالة هي نوع يصف حالة التطبيق. (قد تستخدم قائمة بسيطة من المهام صفيفًا.)
كل هذه العناصر الثلاثة معلن عنها ، وكل منها جزء صغير قابل للاختبار وقابل لإعادة الاستخدام من اللغز ، والذي يتكون معًا من التطبيق بالكامل. يتم تخزين الحالة في المتجر ، ويمكن حساب طريقة العرض منها.
الدولة والإجراءات والتحديث لتطبيق سويفت بسيط.بالنسبة للعمليات غير المتزامنة ، يمكننا تقديم شيء مثل كائن الوسيطة في Redux أو أوامر في ELM.
استنتاج
يمكننا إما استخدام أي بنى معروفة لنا ، وعندما نضيف SwiftUI تدريجياً إلى التطبيقات الحالية ، سيكون هذا أسلوبًا موثوقًا وآمنًا. في حالة تنفيذ تطبيق جديد باستخدام SwiftUI فقط ، يمكنك استخدام نهج أكثر انفتاحًا وتجربة شيء آخر.
إذا كنت تفكر في تطوير تطبيق ما باستخدام SwiftUI في المستقبل القريب ، فإنني أوصي بالاهتمام ببعض النقاط:
- لا تقدم Apple إرشادات مفصلة حول بنية التطبيق ، مما يعني أن لدينا ، كمجتمع من المبرمجين ، العديد من الفرص للابتكار وتنفيذ الأساليب الجديدة.
- سنرى بالتأكيد نطاقًا أوسع بكثير من قواعد البرمجة المختلفة ، حيث يجب ملء الفتحة المتبقية بعد وحدة تحكم العرض.
- تبقي مفتوحة ولا تخاف من البدء من نقطة الصفر.
يمكن العثور على تجاربي في
ملعب Swift (على سبيل المقارنة ، يقدم تطبيق واستخدام UIKit و SwiftUI ، نفس التطبيق).
الخطوات التالية
هناك العديد من الطرق التي يمكننا الاستفادة منها ، لكنني أميل بشدة لمحاولة أخيرًا اتباع نهج أكثر وظيفية لتطوير التطبيقات. لذلك ، يمكنك رؤية بعض الحلول المثيرة للاهتمام من المجتمع ، وما زال لدينا الكثير من الوقت عندما يمكننا استخدام SwiftUI في العمل اليومي ، لذلك لا يزال هناك وقت للتجريب ولا يوجد ضغط علينا.
أخطط لكتابة المزيد حول هذا التنفيذ للبنية أحادية الاتجاه والوظيفية. آمل أن أتمكن قريباً من استخدام هذا في بعض المشاريع الحقيقية الصغيرة ، حتى أتمكن من إخباركم أكثر عن مدى قابلية هذا النهج للتطبيق ولديه مشاكل في الأداء في المشاريع الكبيرة.