قبل بضعة أسابيع ، تم عقد حدث خاص لمجتمع CocoaHeads في مكتب Yandex - أكبر من اللوحات التقليدية. تحدث المطور أنطون سيرجييف في هذا الاجتماع وتحدث عن نموذج التفاعل الصغير الذي يستخدمه مصممو UX عادة ، بالإضافة إلى كيفية وضع الأفكار فيه موضع التنفيذ. أعطى أنتون أكبر قدر من الاهتمام للرسوم المتحركة.
- من المهم جدًا بالنسبة لي أن أتشرف بمقابلة الضيوف. أرى هنا أولئك الذين عرفتهم منذ فترة طويلة جدًا ، وأولئك الذين عرفتهم مؤخرًا ، والذين لم ألتق بهم بعد. مرحبًا بك في CocoaHeads.
سأخبرك عن التفاعلات الدقيقة. هذا قليل من clickbait - نحن مهندسون ، مطورون ، سنتحدث أكثر عن جزء البرنامج ، لكننا سنبدأ بموضوع إنساني للغاية ، مثل التفاعلات الدقيقة. ونتيجة لذلك ، سنطبق هذا الموضوع الإنساني في الجزء التقني لتعلم كيفية تصميم المكونات المرئية الصغيرة جدًا بشكل أكثر كفاءة وببساطة ، مثل الأزرار ، واللوادر الصغيرة ، والأشرطة. إنها مشبعة بالرسوم المتحركة ، ويمكن أن تبدو شفرة الرسوم المتحركة المتفرعة معقدة للغاية ، فمن الصعب للغاية الحفاظ عليها.
لكن أولاً ، القليل من الإلهاء. فكر في الأمر ، هل تتذكر متى قررت أن تصبح مطورًا؟ أتذكر ذلك بوضوح. بدأ كل شيء بجدول. بمجرد أن قررت تعلم ObjC. لغة عصرية ، ممتعة ، تمامًا ، بدون خطط بعيدة المدى. لقد وجدت كتابًا ، يبدو ، Big Nerd Ranch ، وبدأت في القراءة فصلاً فصلاً ، وأقوم بكل تمرين ، وفحص ، وقراءة ، حتى وصلت إلى الطاولة. ثم تعرفت أولاً على نمط المفوض ، وبشكل أكثر دقة مع سلالاته الفرعية "مصدر البيانات" ، مصدر البيانات. يبدو لي هذا النموذج بسيطًا جدًا الآن: هناك مصدر بيانات ، مندوب ، كل شيء بسيط. ولكن بعد ذلك أذهلني: كيف يمكنني فصل جدول من بيانات مختلفة تمامًا؟ رأيت ذات مرة جدولًا على قطعة من الورق حيث يمكنك وضع عدد لا نهائي من الصفوف ، بيانات مجردة تمامًا. لقد أثرت علي كثيرا. أدركت أن البرمجة والتطوير لديها فرص هائلة ، وسيكون من المثير للاهتمام تطبيقها. منذ ذلك الحين ، قررت أن أصبح مطورًا.
خلال التطوير ، تمت مواجهة أنماط مختلفة. ضخمة ، والتي تسمى معماريات تصف التطبيق بأكمله. الصغيرة التي تتناسب مع العشرات في زر صغير. من المهم أن نفهم أن كل هذه الأنماط لم تأت من الجو ، ولكن من القطاع الإنساني. نفس نمط المندوب. ظهر التفويض قبل وقت طويل من البرمجة ، وتتولى البرمجة جميع هذه الأشياء الإنسانية من أجل عمل أكثر كفاءة.
اليوم سأتحدث عن نهج آخر يتولى أمر إنساني آخر. على وجه الخصوص ، حول التفاعلات الدقيقة.
بدأ كل شيء مع محمل. في العمل السابق ، قبل Yandex ، كانت لدي مهمة تكرار محمل تصميم المواد من Google. هناك اثنان منهم ، واحد غير محدد ، والآخر محدد. كانت لدي مهمة دمجها في واحد ، كان عليه أن يكون قادرًا على التأكد من وجود غير محدد ، ولكن كانت هناك متطلبات صارمة - بحيث تكون سلسة للغاية. في أي لحظة ، يمكننا الانتقال من حالة إلى أخرى ، ويجب أن يكون كل شيء متحركًا بسلاسة ودقة.
أنا مطور ذكي ، فعلت كل شيء. حصلت على أكثر من 1000 سطر من كود المعكرونة غير المفهومة. نجحت ، لكنني تلقيت تعليقًا رائعًا على مراجعة الكود: "آمل حقًا ألا يقوم أحد بتحرير هذا الكود." وبالنسبة لي فهي غير مناسبة عمليًا. لقد كتبت رمز فظيع. لقد عملت بشكل رائع ، كانت واحدة من أفضل الرسوم المتحركة الخاصة بي ، لكن الرمز كان مروعًا.
سأحاول اليوم وصف النهج الذي وجدته بعد أن تركت تلك الوظيفة.
لنبدأ بالموضوع الأكثر إنسانية - نماذج التفاعل الصغير. كيف يتم تضمينها وعمومًا أين تكون مخفية في تطبيقاتنا؟ دعونا نواصل استخدام هذا النموذج في عالمنا التقني. فكر في كيفية عمل UIView ، الذي يتعامل مع العرض والرسوم المتحركة ، وكيف يعمل هذا. على وجه الخصوص ، سنتحدث كثيرًا عن آلية CAAction ، التي تتكامل بشكل وثيق مع UIView ، CALayer وتعمل معها. ثم ضع في اعتبارك أمثلة صغيرة.
التعريف أولاً. على ما يبدو ، أحب المؤلف حقًا البادئة "micro" ، ولكن لا توجد تفاعلات كلية أو نانو ، الحجم لا يهم. من أجل البساطة ، سوف نسميها ببساطة تفاعلات. هذا نموذج مناسب يسمح لك بوصف أي تفاعل مع التطبيق ، من البداية إلى النهاية. وتتكون من أربع نقاط: الزناد ومنطق الأعمال الذي يجب تنفيذه في هذا التفاعل ، وردود الفعل لنقل شيء ما إلى المستخدم ، وتغيير في حالة التطبيق.
سأروي قصة واحدة بثلاثة أدوار مختلفة. سأبدأ بالمستخدم باعتباره أهم شيء في التطوير. عندما كنت أستعد للتقرير ، مرضت. كنت بحاجة إلى إيجاد صيدلية ، وفتحت Yandex.Map. فتحت التطبيق ، نظرت إليه ، نظرت لي ، لكن لم يحدث شيء. ثم أدركت أنني المستخدم ، وأنا المسؤول الرئيسي ، وأعطي تعليمات حول ما يجب فعله للتطبيق. قمت بالتوجيه والنقر على زر "بحث" ودخلت "الصيدلة" والنقر على "موافق" وقام التطبيق بالعمل الداخلي والعثور على الصيدليات الضرورية التي كانت بجانبي وعرضتها على الشاشة.
لقد بحثت عن الخيار الصحيح ووجدت أنه بالإضافة إلى الصيدليات ، ظهر زر خاص على الشاشة - لبناء مسار. وهكذا ، انتقل التطبيق إلى حالة جديدة. نقرت عليه ، وذهبت إلى الصيدلية. ذهبت إلى هذا التطبيق لسبب ما - لإيجاد صيدلية. وصلت إليها. انا مستخدم سعيد
قبل ظهور هذا التطبيق ، وتمكنت من البحث عن شيء فيه ، تم تطويره لأول مرة. ماذا اعتقد مصمم UX عندما توصل إلى هذه العملية؟ بدأ كل شيء بحقيقة أنه كان من الضروري الخروج من مشهد كتم الصوت عندما ينظر المستخدم والتطبيق إلى بعضهما البعض ، ولا يحدث أي شيء. لهذا ، كانت هناك حاجة إلى نوع من الزناد. كل شيء له بداية ، وهنا أيضًا ، كان من الضروري البدء في مكان ما.
تم اختيار الزناد - زر البحث. عند النقر عليه ، كان من الضروري حل المشكلة من وجهة نظر فنية. طلب بيانات على الخادم ، تحليل الاستجابة ، تحديث النموذج بطريقة أو بأخرى ، تحليل. طلب الوضع الحالي للمستخدمين وأكثر من ذلك. وهكذا حصلنا على هذه البيانات ونعرف بالضبط أين توجد جميع الصيدليات.
يبدو أنه كان من الممكن إنهاء هذا. بعد كل شيء ، قمنا بحل المشكلة ، وجدنا جميع الصيدليات. هناك مشكلة واحدة فقط: لا يزال المستخدم لا يعرف أي شيء عن هذه الصيدليات. إنه يحتاج إلى توصيلها.
بطريقة ما نحزم حلنا لهذه المشكلة ونقدمها له في حزمة جميلة حتى يفهمها. حدث أن المستخدمين هم الناس ، يتفاعلون مع العالم الخارجي من خلال الحواس. الوضع الحالي للتكنولوجيا هو أننا كمطورين لتطبيقات الهاتف المحمول ، لدينا ثلاثة حواس فقط: الرؤية - يمكننا عرض شيء ما على الشاشة ، والسمع - يمكننا التكاثر في السماعات ، والإحساس اللمسي ، يمكننا دفع المستخدم في اليد.
لكن الإنسان أكثر وظيفية. لكن الوضع الحالي للتكنولوجيا لدرجة أنه في الوقت الحالي لا يمكننا الاعتماد إلا على هؤلاء الثلاثة. وفي هذه الحالة ، نختار شاشة ، ونظهر على الخريطة أقرب الصيدليات ، ومع قائمة بمعلومات أكثر تفصيلاً عن هذه الصيدليات. ويبدو أن هذا هو كل شيء بالضبط ، وجد المستخدم الصيدليات وكل شيء على ما يرام.
لكن هناك مشكلة عندما دخل المستخدم التطبيق ، كان في سياق لا يعرف فيه مكان الصيدليات. وكانت مهماته العثور عليها. ولكن الآن تغير السياق ، فهو يعرف مكان الصيدليات ، ولم يعد بحاجة إلى البحث عنها. كانت لديه المهمة التالية - للحصول على الاتجاهات إلى الصيدلية التالية. هذا هو السبب في أننا نحتاج إلى عرض عناصر تحكم إضافية على الشاشة ، على وجه الخصوص ، هذا زر لإنشاء مسار ، أي نقل التطبيق إلى حالة أخرى يكون جاهزًا لقبول مشغلات جديدة للتفاعلات التالية مرة أخرى.
تخيل أن مصمم UX قد توصل إلى كل هذا ، ويأتي إلى المطور ويبدأ في وصف الألوان كيف ينقر المستخدم على الزر ، وكيف وماذا يحدث ، وكيف يتم البحث عنه ، وكيف يرضي المستخدم ، وكيف نزيد DAU وما إلى ذلك. تكدس مجموعة الأسئلة التي لم يتم حلها من المطور في مكان آخر في الجملة الأولى ، عندما ذكرنا الزر لأول مرة.
يستمع بصبر إلى كل شيء ، وفي النهاية ، عندما ينتهي ، يقول أنه بخير ، هذا رائع ، لكن دعنا نناقش الزر. هذا عنصر مهم.
أثناء المناقشة ، اتضح أن الزر هو بطبيعته مشغل ، فهو يحتوي على منطق داخله ، والذي يمكنه من خلاله تلقي رسائل من النظام ، على وجه الخصوص ، حول نقرات المستخدم على الشاشة. بناءً على هذه النقرة ، يمكن أن تبدأ سلسلة من الأحداث ، والتي تبدأ بحقيقة أن الزر نفسه يرسل رسائل إلى كائنات مختلفة حول الحاجة إلى بدء عمليات مختلفة ، وفي هذه الحالة ، يطلب معلومات على الخادم ، والمزيد.
عند الضغط عليه ، يغير الزر حالته ، يصبح مضغوطًا. عندما يفرج المستخدم ، يتوقف عن الضغط عليه. أي أنه يعطي ملاحظات للمستخدم حتى يفهم ما يمكن توقعه من هذا الزر. ويمكن الضغط على الزر أو إلغاء ضغطه أو تنشيطه أو عدم نشاطه في حالات مختلفة ، والانتقال وفقًا لمنطق مختلف من حالة إلى أخرى.
وهكذا ، رأينا أن نفس نموذج التفاعل الصغير ، الذي يتكون من محفز ومنطق الأعمال والتغذية المرتدة وتغييرات الحالة ، يمكن أن يصف تطبيقنا على نطاقات مختلفة ، كما هو الحال في حجم حالة المستخدم بالكامل ، بحث ضخم عن أقرب صيدلية ، لذلك من حيث زر صغير.
وهذا نموذج ملائم للغاية يسمح لك بتبسيط التفاعل داخل الفريق ووصف برمجيا ، وفصل أربعة كيانات: الزناد ، ومنطق الأعمال ، والتعليقات ، وتغيير الحالة. دعونا نرى ما يوفره لنا UIKit لاستخدامه. ولا يوفر فقط ، بل يستخدم. عند تنفيذ العديد من الرسوم المتحركة ، والمكونات الصغيرة للفئات الفرعية UIView ، فإنه يستخدم هذه الآلية فقط ، ولا يذهب بطريقة مختلفة.
لنبدأ مع UIView ، كيف يتناسب مع هذا النموذج. ثم سننظر في CALayer التي يوفرها لنا لدعم هذه الدول ، وسننظر في آلية الإجراءات ، اللحظة الأكثر إثارة للاهتمام.
لنبدأ مع UIView. نستخدمه لعرض بعض المستطيلات على الشاشة. ولكن في الواقع ، UIView لا تعرف كيف ترسم نفسها ، فهي تستخدم كائن CALayer آخر لهذا الغرض. في الواقع ، تلتزم UIView بتلقي رسائل حول لمس النظام ، وكذلك حول المكالمات الأخرى ، حول واجهة برمجة التطبيقات التي حددناها في الفئات الفرعية لدينا من UIView. وبالتالي ، يطبق UIView نفسه منطق الزناد ، أي إطلاق بعض العمليات ، وتلقي هذه الرسائل من النظام.
يمكن لـ UIView أيضًا إخطار مندوبيها بالأحداث التي حدثت ، وكذلك إرسال رسائل إلى المشتركين ، على سبيل المثال ، جعل UIControl فئات فرعية فرعية أحداثًا مختلفة. بهذه الطريقة ، يتم تنفيذ منطق الأعمال هذا UIView. ليس كلهم لديهم منطق عمل ، فالكثير منهم مجرد عناصر عرض وليس لديهم ملاحظات بمعنى منطق الأعمال.
نظرنا إلى نقطتين ، منطق الزناد والمنطق التجاري. وأين يتم إخفاء التعليقات وتغيير الحالة في UIView؟ لفهم هذا ، يجب أن نتذكر أن UIView غير موجود بمفرده. عند إنشائه ، فإنه ينشئ طبقة خلفية ، فئة فرعية من CALayer.
ويعين نفسه مندوبه. لفهم كيفية استخدام UIView CALayer ، يمكن أن توجد في حالات مختلفة.
كيف تميز دولة عن دولة أخرى؟ وهي تختلف في مجموعة البيانات التي يجب تخزينها في مكان ما. سننظر في الميزات التي توفرها CALayer لـ UIView ، بحيث تقوم بتخزين الحالة.
تتوسع واجهتنا قليلاً ، والتفاعل بين UIView و CALayer ، لدى UIView مهمة إضافية - لتحديث المستودع داخل CALayer.
حقيقة غير معروفة أن القليل من الناس يستخدمون: يمكن أن تتصرف CALayer كمصفوفة ترابطية ، مما يعني أنه يمكننا كتابة بيانات عشوائية على أي مفتاح على النحو التالي: setValue (_: forKey :).
هذه الطريقة موجودة في جميع الفئات الفرعية لـ NSObject ، ولكن على عكس العديد من الفئات الأخرى ، عندما يتم استلام مفتاح لا يتم تجاوزه به ، فإنه لا يتلف. ويكتبها بشكل صحيح ، وبعد ذلك يمكننا قراءتها. هذا شيء مريح للغاية ، والذي يسمح ، دون إنشاء فئات فرعية لـ CALayer ، بكتابة أي بيانات هناك ثم قراءتها والتشاور معها. لكن هذا مستودع بسيط بدائي للغاية ، في الواقع ، قاموس واحد. CALayer أكثر تقدمية. يدعم الأنماط.
يتم تنفيذ ذلك بواسطة خاصية النمط التي يمتلكها أي CALayer. بشكل افتراضي ، لا شيء ، ولكن يمكننا إعادة تعريفه واستخدامه.
بشكل عام ، هذا قاموس عادي وليس أكثر ، ولكن له خصوصية حول كيفية عمل CALayer معه ، إذا طلبنا قيمة forKey ، وهي طريقة أخرى لدى NSObject. إنه يعمل بشكل مثير للاهتمام للغاية ، فهو يبحث عن القيم الضرورية في قاموس النمط بشكل متكرر. إذا وضعنا نمطًا موجودًا في نمط جديد باستخدام مفتاح النمط وكتبنا بعض المفاتيح هناك ، لكنه سيبدو بالطريقة التالية.
أولاً ، انظر إلى الجذر ، ثم إلى الداخل وما إلى ذلك ، حتى يصبح ذلك منطقيًا. عندما يصبح الأسلوب صفرًا ، فلا معنى للنظر إلى أبعد من ذلك.
بهذه الطريقة ، يمكن لـ UIView ، باستخدام البنية التحتية التي توفرها CALayer ، تنظيم تغييرات الحالة ، تحديث مستودع CALayer الداخلي ، إما باستخدام النمط ، أو مستودع قوي جدًا يمكنه محاكاة المكدس ، أو استخدام مجموعة ارتباطية عادية ، والتي هي أيضًا فعالة للغاية ومفيدة جدًا .
مع الانتهاء من التخزين ، ابدأ بـ CAAction. سأخبركم المزيد عنه.
هناك مهمة جديدة لـ UIView - لطلب إجراءات من CALayer. ما هي الأفعال؟
CAAction هو مجرد بروتوكول له طريقة واحدة فقط - تشغيل. تحب شركة آبل بشكل عام موضوعات السينما ، والعمل هنا "كاميرا ، محرك!". هذا "المحرك" هو مجرد عمل ، ولم يتم استخدام هذا الاسم فقط. تعني طريقة التشغيل بدء إجراء يمكن أن يبدأ وينفذ وينتهي ، وهو الأهم. هذه الطريقة عامة جدًا ، ولديها فقط سلسلة حدث ، وكل شيء آخر يمكن أن يكون من أي نوع. في ObjC ، هذا كله معرف و NSDictionary.
هناك فئات داخل UIKit تفي ببروتوكول CAAction. الأول هو الرسوم المتحركة. أولاً ، نعلم أن الرسوم المتحركة يمكن إضافتها إلى طبقة ، ولكن هذا شيء منخفض المستوى للغاية. تجريد عالي المستوى فوقه هو تشغيل إجراء مع المعلمات الضرورية مع طبقة.
الاستثناء المهم الثاني هو NSNull. نحن نعلم أنه لا يمكن استدعاؤه بأي طريقة ، ولكنه يفي ببروتوكول CAAction ، ويتم ذلك من أجل البحث الملائم عن CAAction في الطبقات.
كما قلنا من قبل ، UIView هو مفوض إلى CALayer ، وإحدى طرق التفويض هي العمل (لـ: forKey :). تحتوي الطبقة على طريقة وعمل لـ المفتاح.
يمكننا تسميته في أي وقت على الطبقة ، وفي أي وقت سيعطي الإجراء الصحيح أو لا شيء ، لأنه يمكن أيضًا أن يعطي. الخوارزمية بحث غير عادي للغاية. الرمز الزائف مكتوب هنا ، لنلقي نظرة على السطور. عند استلام هذه الرسالة ، يتشاور أولاً مع المندوب. يمكن للمفوض إما إرجاع لا شيء ، مما يعني أن البحث يجب أن يستمر في مكان آخر ، أو قد يرجع إجراءً صالحًا ، وهو كائن صالح يفي ببروتوكول CAAction. ولكن هناك قاعدة منطقية: إذا أعادت NSNull ، التي تفي بهذا البروتوكول ، فسيتم تحويلها لاحقًا إلى لا شيء. أي إذا أعيدنا Null ، فهذا يعني في الواقع "توقف عن البحث". لا يوجد عمل وليس ضروريا.
ولكن هناك ما يلي. بعد التشاور مع المندوب وعاد المندوب لا شيء ، واصل البحث. أولاً ، في قاموس الإجراءات ، الذي تحتوي عليه الطبقة ، وبعد ذلك ستبحث بشكل متكرر في قاموس النمط ، حيث يمكن أيضًا أن يكون هناك قاموس بمفتاح الإجراءات ، حيث يمكن كتابة العديد من الإجراءات ، وستتمكن أيضًا من البحث عنها بشكل متكرر. إذا لم يعمل هناك ، فسوف يطلب من الفصل الإجراء الافتراضي لطريقة المفتاح ، والذي تم تعريفه بواسطة CALayer وحتى إرجاع شيء ما مؤخرًا ، ولكنه في الآونة الأخيرة يرجع دائمًا إلى الصفر في الإصدارات الأخيرة من iOS.
فهمت النظرية. دعونا نرى كيف يتم تطبيق كل شيء في الممارسة العملية.
هناك أحداث ، ولديهم مفاتيح ، وبعض الإجراءات تتم على هذه الأحداث. بشكل أساسي ، يمكن تمييز نوعين مختلفين من الأحداث. الأول هو الرسوم المتحركة للخصائص المخزنة. لنفترض أنه عندما نسمي Viewcolor = أحمر في View ، فمن الممكن نظريًا تحريكه.
ما تقرير عن الأنماط بدون دائرة؟ وجهت زوجين. لدى UIView نوع من الواجهة التي قمنا بتعريفها للفئات الفرعية أو تلك التي يتم تلقيها من النظام مع الأحداث. تتمثل مهمة UIView في طلب الإجراء المطلوب وتحديث المخزن الداخلي وتشغيل الإجراء الذي حدث. الطلب مهم جدًا فيما يتعلق بالطلب: الإجراء ، ثم فقط قم بتحديث الإجراء ، وبعد ذلك فقط قم بتحديث المتجر والإجراء.
ماذا يحدث إذا قمنا في UIView بتحديث backgroundColor. نحن نعلم أنه في UIView لا يزال كل ما يتعلق بالعرض على الشاشة وكيلًا لـ CALayer. يقوم بتخزين كل ما يتلقاه في ذاكرة التخزين المؤقت ، فقط في حالة ، ولكن في نفس الوقت كل شيء يبث CALayer ، ويتعامل مع كل المنطق بشكل أكبر على CALayer. ماذا يحدث داخل CALayer عندما يتلقى مهمة لتغيير الخلفية؟ كل شيء أكثر تعقيدًا هنا.
بالنسبة للمبتدئين ، سوف يطلب العمل. ومن المهم أن نفهم أنه سيتم طلب الإجراء أولاً. سيسمح لك هذا بسؤال CALayer عن قيمه الحالية ، بما في ذلك backgroundColor ، في وقت إنشاء الإجراء ، عندها فقط سيتم تحديث المتجر ، وعندما يتلقى الإجراء المستلم أمر التشغيل ، سيكون قادرًا على استشارة CALayer والحصول على قيم جديدة. وبالتالي ، سيحصل على كل من القديم والجديد ، وهذا سيسمح له بإنشاء رسوم متحركة ، إذا لزم الأمر.
ولكن هناك ميزة واحدة في UIView ، إذا قمنا بتغيير الخلفية Color في UIView ، إذا قمنا بذلك في كتلة الرسوم المتحركة ، فسيكون متحركًا ، وإذا كان خارج كتلة الرسوم المتحركة ، فلن يكون متحركًا.
كل شيء بسيط للغاية ، لا يوجد سحر. ولكن فقط تذكر أن UIView هو مندوب لـ CALayer ، لديه مثل هذه الطريقة. كل شيء بسيط للغاية.
إذا تم تشغيل هذه الطريقة في كتلة الرسوم المتحركة ، فسوف تُرجع نوعًا من الإجراءات. إذا كانت خارج كتلة الرسوم المتحركة ، فستعيد هذه الطريقة NSNull ، مما يعني أنه لا يوجد شيء بحاجة إلى الرسوم المتحركة. , CALayer .
, UIView , . . ?
, . UIView , read only, , inheritedAnimationDuration. . , . .
? duration, . , run, , .
, CAAction, backgroundcolor opacity, UIView . , , , , . . setValue forKey , , , , , , .
, , , , .
— . , «» «» . .
.
. , , , . UIView CALayer, , , CAAction, , , .
, , , . , . .
. - .
CAAction, , . , , , .
, , , home, . , . , .
. - .
, - , - . , , . , .
, , .
, CAAction , . , UIControl, - , - , , , - .
, . , UIView -, , - , , , .
— . .
? . , . — . activating, inactive active. , , .
. , onOrderIn onOrderOut. , UIKit, .
, -, — , .
. UIView , : isActive progress. . CAAction, .
, . , , 30 CAACtion, . , 30 , NSNull. 15 15 . . — . , — .
, . .
. , , : , -, .
من خلال تفكيك جميع التفاعلات في هذه القطع الأربع ، لا يمكننا التدخل في منطق واحد مع الآخر ، تبسيط. لذلك ، حاول تحليل التطبيقات والمهام المختلفة باستخدام هذه التفاعلات الدقيقة. تذكر أن UIKit يوفر بنية تحتية ضخمة للقيام بذلك بشكل مريح وجميل. لا تهملها. غالبًا ما تكون هناك طرق قديمة جدًا ، نادرًا ما يتم استخدامها ، ولكنها مهمة جدًا وستساعدك على إدراك عناصرك بشكل جميل وبسيط وسريع. شكرا لكم على اهتمامكم.