مشروع متكامل

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

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

يتركز الاهتمام على البنية المعمارية، أي على الحدود الفاصلة بين الطبقات. تصبح شيفرة Flutter عصية على الإدارة لسبب يكاد يتكرر دائمًا: ينتهي المنطق التجاري داخل دوال build، وتنتهي استدعاءات الشبكة داخل onPressed، وتنتهي استعلامات SQL داخل الـ widgets. والفصل بين الطبقات يكلّف بضعة ملفات إضافية في البداية، لكنه يتيح الاختبار والتعديل والفهم لاحقًا.

لذلك لا يعيد هذا الدرس نسخ الدروس السابقة. فعمليات CRUD الخاصة بـ sqflite من الدرس 10 وعميل http من الدرس 9 يُعاد استخدامهما كما هما؛ ولن نفصّل إلا ما هو جديد لأنه ينشأ من عملية التجميع: الهوية المزدوجة المحلية/البعيدة، وطابور المزامنة، والمفاضلة بين الذاكرة المؤقتة والشبكة، والتنسيق الذي يقوم به المتحكّم.