تجربة الجوال بنهج Offline-First: منتج موثوق على الشبكات الضعيفة

1. حدّد نطاق العمل دون اتصال وفق المهمة الحرجة للمستخدم

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

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

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

2. اجعل البيانات المحلية مصدر القراءة، والمزامنة عملية منفصلة

يوصي دليل بنية offline-first الرسمي من Android بأن يمتلك المستودع الذي يستخدم الشبكة مصدرَي بيانات: محليًا وشبكيًا، وبأن يكون المصدر المرجعي الذي تقرأ منه الطبقات العليا هو البيانات المحلية. فالتغييرات التي تُكتب محليًا أولًا يمكنها تحديث الواجهة فورًا، بينما تُبلّغ قائمة انتظار الشبكة الخادمَ لاحقًا. ويؤكد الدليل كذلك أن الكتابة دون اتصال تتطلب استراتيجية واضحة للتعارضات والأخطاء.Android Developers — Build an offline-first app

في هذا النموذج لا ترسم الواجهة استجابة الشبكة مباشرة. فالبيانات القادمة من الخادم تُتحقَّق أولًا ثم تُكتب في المخزن المحلي، والشاشة تراقب المصدر نفسه. وبذلك لا تنشأ حقيقتان مختلفتان على الشاشة مع تغيّر حالة الاتصال. ومع ذلك لا تعدّ المصدر المحلي صحيحًا على نحو مطلق؛ إذ ينبغي أن تحمل السجلات حالات مثل `pending` أو `synced` أو `failed` أو `conflicted` أو `stale`.

افصل عمل المزامنة عن دورة حياة التطبيق. فقد يغلق نظام التشغيل التطبيق، وقد يؤجّل توفير البطارية العمل في الخلفية، وقد تُنفَّذ قائمة الانتظار نفسها مرة أخرى. لذلك يجب أن تكون العمليات آمنة عند التكرار؛ ويساعد معرّف العملية الفريد ودعم الإجراء المتكرر (idempotency) في الخادم على منع إنشاء السجل نفسه مرتين.

3. صمّم قواعد المزامنة وإعادة المحاولة ومعالجة التعارض

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

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

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

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

4. سيناريو افتراضي: نموذج تفتيش ميداني على شبكة ضعيفة

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

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

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

5. اشرح حالة الاتصال بالفعل الممكن لا بالمصطلحات التقنية

لا يكفي عرض شريط «دون اتصال» بشكل دائم. فما يهم المستخدم هو ما يستطيع إنجازه وأين توجد بياناته. عبارات مثل «المسوّدة محفوظة على هذا الجهاز» و«3 صور بانتظار الإرسال» و«يلزم اتصال لتأكيد هذا السعر» تشرح الفعل ونتيجته. ولا تجعل اللون الإشارة الوحيدة؛ استخدم الأيقونة والنص والإعلان المتاح لقارئ الشاشة معًا.

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

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

6. خطة تنفيذ من ثمانية أسابيع واختبارات إفساد الشبكة

يذكر التوثيق الرسمي لـ Cloud Firestore أن البيانات المستخدمة يمكن الاحتفاظ بها في ذاكرة مؤقتة عند تفعيل الاستمرارية دون اتصال، وأن التغييرات المحلية تُزامَن عند عودة الاتصال، وأن الكتابة الأخيرة تفوز عند تعدد التغييرات على المستند نفسه. وقد يكفي هذا السلوك الجاهز بعض المنتجات، لكن في التحرير المشترك الحرج اختبر صراحةً مدى توافقه مع قاعدة عملك. وتحقق من التوثيق المحدَّث، إذ قد تختلف القيم الافتراضية ونطاق الدعم بين المنصات.Firebase Documentation — Access data offline with Cloud Firestore

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

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

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

7. الحدود وأنماط الإخفاق: نهج offline-first ليس بلا كلفة

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

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

أخيرًا، المزامنة ليست خفية ولا مثالية في أي وقت. فمخطط الخادم يتغيّر، وصلاحية الحساب تُسحب، ومساحة التخزين تمتلئ، وقائمة الانتظار قد تتلف. ولذلك يشكّل الاسترجاع والتصدير وأدوات تشخيص الدعم والشرح المقدَّم للمستخدم جزءًا من التصميم. فهدف offline-first ليس الوعد بالنجاح في كل الظروف، بل تقليل فقدان البيانات والثقة الزائفة في ظروف الشبكة غير المستقرة.