سلسلة SwiftUI 09｜مقدمة إلى الرسوم المتحركة SwiftUI: استخدام الرسوم المتحركة ومع الرسوم المتحركة

من المرجح أن تمنح الرسوم المتحركة لـ SwiftUI الأشخاص شعورًا “يبدو بسيطًا”:

• إضافة .animation
• أو حزمة withAnimation

تبدأ الصفحة في التحرك.

لكن في المشاريع الحقيقية، المشكلة الأكثر شيوعًا في الرسوم المتحركة هي هنا بالضبط:

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

وهذا يدل على أننا في كثير من الأحيان لا نكتشف الأمر أولاً:

هل يجب ربط هذه الرسوم المتحركة بتغيير حالة معين، أم أنها يجب أن تنتهي فقط من عملية تغيير معينة؟

1. جوهر الرسوم المتحركة لـ SwiftUI هو “السماح بإدخال تغييرات الحالة وعرضها”

وهذا مهم بشكل خاص.

إذا كنت لا تزال تستخدم أفكار UIKit لفهم الرسوم المتحركة، فمن السهل أن يكون الإعداد الافتراضي هو:

• أريد أن أقوم بحركة تحكم معينة

SwiftUI يشبه إلى حد كبير القيام بما يلي:

• عندما تتغير الحالة من A إلى B، استخدم الرسوم المتحركة للتعبير عن عملية التغيير

وهذا يعني أن الرسوم المتحركة تعتمد بشكل طبيعي على تغييرات الحالة. إذن ما يجب الحكم عليه حقًا هو:

• ما هي تغييرات الحالة التي تستحق الرسوم المتحركة؟
• ما الحجم الذي يجب أن يكون عليه نطاق الرسوم المتحركة؟

2. لا يقتصر الفرق بين .animation وwithAnimation على طريقة الكتابة فحسب، بل على دقة التحكم.

الفهم العملي أكثر هو:

• يشبه .animation إرفاق الرسوم المتحركة بأنواع معينة من تغييرات الحالة.
• withAnimation أشبه بتغليف تعديل حالة محدد بشكل صريح

لذا، عند استخدام .animation، يكون الأمر أشبه بقول:

يجب أن يحتوي هذا العرض على تفاعلات متحركة بشكل افتراضي لتغييرات معينة في الحالة.

و withAnimation أشبه بالقول:

سأقوم بتغيير هذه الحالة الآن، وأريد أن يكون هذا التغيير متحركًا.

يعد هذا التمييز أمرًا بالغ الأهمية لأنه يؤثر بشكل مباشر على إمكانية التحكم في الرسوم المتحركة.

3. العديد من الرسوم المتحركة للصفحة سوف “تتحرك معًا بشكل غير مفهوم”

السبب الأكثر شيوعًا هو أن نطاق العمل غير مغلق.

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

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

يحدث هذا عادةً عندما يتم إرفاق الرسوم المتحركة بتغيير الحالة أو عرض التسلسل الهرمي الكبير جدًا.

لذلك عندما يتم العبث بالرسوم المتحركة، فإن ما أعود إليه غالبًا للتحقق هو:

• ما هي التغييرات المسؤولة عنها هذه الطبقة حاليًا؟
• هل الرسوم المتحركة مرتبطة بطريقة عرض كبيرة جدًا؟
• هل يؤثر تغيير الحالة على عدد كبير جدًا من نتائج التخطيط في نفس الوقت؟

4. العديد من “الرسوم المتحركة ليست جيدة المظهر” لأن نموذج الحالة غير واضح.

تبدو بعض الرسوم المتحركة غريبة وهي:

• الدولة نفسها ليست مصممة بشكل واضح
• تغيير واحد يغير الكثير من القيم في نفس الوقت
• مستوى تخطيط الصفحة غير مستقر

على سبيل المثال، يتم تشغيل النقرة في نفس الوقت:

• توسيع
• تبديل كتابة الإعلانات
• تغيرات الارتفاع
• إعادة ترتيب القائمة

وينتهي الأمر بأن يبدو الأمر فوضويًا، وغالبًا ما يتم ضغط العديد من التغييرات الدلالية المختلفة في نفس الحالة الانتقالية.

5. متى يكون استخدام withAnimation أكثر ملاءمة

أفضل استخدامه في هذه السيناريوهات:

• يؤدي إجراء المستخدم إلى تشغيل تبديل حالة صريح
• أريد فقط أن يكون تغيير الحالة متحركًا هذه المرة
• أريد التحكم بشكل صريح في “ما إذا كان يجب نقل هذا التغيير أم لا”

على سبيل المثال:

• توسيع/انهيار
• إدراج/حذف كتلة جزئية
• تبديل حالة العرض التقديمي معينة بعد النقر

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

6. متى يكون .animation أكثر خطورة؟

من السهل بشكل خاص أن يتسبب .animation في “تحرك الصفحة قليلاً في كل مكان” عندما لا يتم التفكير بوضوح في نطاق تأثير الحالة أولاً.

خاصة في التخطيطات المعقدة، إذا كان تغيير الحالة يؤثر على:

• الأبعاد
• المحاذاة
• كتابة الإعلانات
• التسلسل الهرمي للحاويات

يمكن أن يؤدي تعليق الرسوم المتحركة مباشرة عليها إلى انتقال المنطقة بأكملها بسهولة.

لذا فإن .animation أكثر ملاءمة لهؤلاء:

• نطاق التأثير واضح نسبيا
• دلالات بسيطة لتغيرات الحالة
• استقرار المنطقة المحلية

المشهد.

7. حكم أكثر عملية: هل هذه الرسوم المتحركة تعبر عن “إجراء” أم تعدل “نوع من التغيير” بشكل افتراضي؟

إذا كنت تعبر عن إجراء صريح:

• انقر لفتح
• قريب
• أدخل
• حذف

ثم عادةً ما أفكر في withAnimation أولاً.

إذا كنت تقوم بتعديل تغيير الحالة المحلية المستقر، فمن الأسهل مراعاة .animation.

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

8. الخلاصة: ما يجب تمييزه حقًا في الرسوم المتحركة لـ SwiftUI هو حدود تغييرات الحالة وحدود تأثيرات الرسوم المتحركة.

ولكي أختصر الأمر أقول:

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

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