واجهات API والشبكة

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

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

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

لماذا يجمّد الاستدعاء الحاجب الشاشة

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