التعامل مع `CancellationTokenSource` في كود Unity غير المتزامن قد يكون صعباً، مما يؤدي غالباً إلى أخطاء إذا لم تتم إدارة وظيفتي `Cancel()` و `Dispose()` بشكل صحيح. يقدم فئة مساعدة جديدة طريقة آمنة للتعامل مع هذه المشاكل الشائعة، وتجنب أخطاء مثل `ObjectDisposedException`.
إذا كنت تكتب كوداً غير متزامن في Unity، خاصة لتحميل البيانات، الاتصال بالشبكة، أو الانتقالات بين الشاشات، فمن المحتمل أنك استخدمت `CancellationTokenSource`. لكن إدارة وظيفتي `Cancel()` و `Dispose()` يمكن أن تكون معقدة بشكل مدهش، وقد تؤدي إلى أخطاء غير متوقعة. هذا يعني أن لعبتك أو تطبيقك قد يتعرض للأعطال أو يتصرف بطريقة غير متوقعة. يعتقد العديد من المطورين أن كتابة `_cts?.Cancel(); _cts?.Dispose();` آمنة وفعالة، لكن للأسف، هذا ليس هو الحال دائماً. المشكلة الرئيسية هي أن `Dispose()` لا يقوم بتعيين الكائن إلى `null`، مما يعني أن استدعاء `Cancel()` مرة أخرى على كائن تم التخلص منه بالفعل يمكن أن يتسبب في خطأ `ObjectDisposedException` الفادح. يمكن أن تحدث هذه المشكلة إذا تم تشغيل منطق الإلغاء عدة مرات، مما يعرض استقرار تطبيقك للخطر. من المهم أن نفهم الفرق الأساسي بين `Cancel()` و `Dispose()`. وظيفة `Cancel()` ترسل فقط *طلباً* للإلغاء إلى الكود الذي تلقى `CancellationToken`. لا توقف أي عملية قيد التشغيل فوراً؛ بل يجب على الكود المستدعى أن يتحقق بنشاط من الرمز الملغي أو يمرره إلى واجهة برمجة تطبيقات تدعم الإلغاء. على الجانب الآخر، `Dispose()` ليس طلباً للإلغاء على الإطلاق. بدلاً من ذلك، هو يحرر الموارد الداخلية التي يحتفظ بها `CancellationTokenSource`، وهو أمر حيوي لمنع تسرب الذاكرة. كلاهما ضروريان، ولكن استخدامهما بشكل أعمى يمكن أن يؤدي إلى مشاكل. الخبر السار هو أن هناك طريقة أفضل للتعامل مع هذا التحدي. يسلط مقال حديث الضوء على فئة مساعدة صغيرة مصممة لإدارة `CancellationTokenSource` بأمان. تضمن هذه الفئة المساعدة تحرير الموارد بشكل صحيح ومنع الأخطاء الشائعة، خاصة عند استخدام طرق مثل `CancelAfter()` أو `CreateLinkedTokenSource()`. باستخدام مثل هذه الفئة، يمكنك كتابة كود غير متزامن في Unity أكثر قوة واستقراراً، وتجنب الأعطال وجعل عملية التطوير الخاصة بك أكثر سلاسة وأماناً.
