ماذا يعني التصميم القائم على العمل دون اتصال؟
يعني أن يكتب التطبيق البيانات على الجهاز أولًا ثمّ يرسلها إلى الخادم. فالمستخدم لا يفكّر في وجود الاتصال من عدمه؛ يكتمل السجلّ محلّيًا لحظة إدخاله، وتجري المزامنة في الخلفية. وبالنسبة إلى تطبيق يعمل في مستودع أو طابق سفلي أو منطقة ريفية أو مصعد، هذا ليس ميزة بل قرار تصميمي أساسي.
بنية من ثلاثة أجزاء
- قاعدة بيانات محلّية: المصدر الحقيقي للسجلّ موجود على الجهاز. والشاشة تقرأ البيانات المحلّية مباشرةً.
- طابور العمليات الصادرة: يُكتب كلّ تغيير في الطابور بترتيبه ومعرّفه الخاصّ. والطابور دائم؛ فلا يضيع حتى لو أُغلق التطبيق.
- عامل المزامنة: يرسل الطابور بالترتيب عند عودة الاتصال، ويطبّق محلّيًا التغييرات الواردة من الخادم.
أمّا أن تُجري الشاشة استدعاء الشبكة مباشرةً فليس عملًا دون اتصال؛ بل هو تطبيق «يعرض خطأً حين ينقطع الاتصال».
قرار حلّ التعارض لا يمكن تأجيله
يجب أن يُكتب في بداية المشروع ما الذي يحدث حين يعدّل جهازان السجلّ نفسه دون اتصال. وهذه ثلاث استراتيجيات شائعة:
- الدمج على مستوى الحقل: إذا تغيّرت حقول مختلفة طُبّق التغييران معًا. ويعمل هذا جيّدًا في الحقول المستقلّة مثل جرد المخزون وملاحظة العميل.
- فوز آخر من كتب: بسيط لكنّه يحمل خطر فقدان البيانات؛ استخدموه في الحقول غير الحرجة فقط.
- سلطة الخادم + سؤال المستخدم: هذا هو النهج الصحيح في الحقول ذات الأثر المالي (السعر، والخصم، ومبلغ التحصيل).
ويجب اتخاذ القرار على مستوى كلّ حقل. أمّا اختيار استراتيجية واحدة للجدول كلّه فيُنتج إمّا فقدان بيانات وإمّا سؤالًا لا لزوم له للمستخدم.
امنعوا نشوء السجلّ نفسه مرّتين
عند ضعف الاتصال يُرسل الطلب لكنّ الردّ يضيع؛ فيعيد التطبيق المحاولة وينشأ طلبان على الخادم. والحلّ هو إرسال كلّ عملية بمعرّف فريد يُولَّد على الجهاز، وأن يعيد الخادم النتيجة الأولى بدل فتح سجلّ جديد حين يرى المعرّف نفسه مرّة ثانية. ونفصّل مقابل هذا السلوك في جانب واجهات API في دليل تكامل واجهات API.
حقائق الأجهزة والمتاجر
- البطارية: تتبّع الموقع المتواصل يستهلك البطارية بسرعة. وجمع الموقع على أساس الأحداث (بداية الزيارة ونهايتها) يكفي في معظم السيناريوهات.
- التخزين: لا يمكن أن تكبر البيانات المحلّية بلا حدّ؛ فتلزم سياسة تؤرشف الحركات القديمة وتنظّفها من الجهاز.
- الأذونات: تطلب سياسات المتاجر مبرّرًا لأذونات الموقع والكاميرا والإشعارات؛ فاربطوا لحظة طلب الإذن بخطوة ذات معنى لدى المستخدم.
- فرض تحديث الإصدار: يجب تعريف ما يفعله العميل القديم حين يتغيّر إصدار واجهة الخادم؛ فاعرضوا تنبيه تحديث بدل خطأ صامت.
بيانات الموقع والمسؤولية عن البيانات الشخصية
موقع الموظّف بيانات شخصية. فيجب تقليل البيانات المجموعة إلى أدنى حدّ، وكتابة غرض الجمع ومدّة الحفظ، وإبلاغ الموظّف. أمّا نهج «تسجيل الموقع باستمرار تحسّبًا لكلّ احتمال» فيُنتج خطرًا قانونيًا وحملَ بيانات لا لزوم له معًا.
الأسئلة الشائعة
أنختار التطوير الأصلي أم متعدّد المنصّات؟
يتفوّق التطوير الأصلي في السيناريوهات التي تستخدم عتاد الجهاز بكثافة (قراءة الباركود المتواصلة، وتتبّع الموقع في الخلفية، والكاميرا منخفضة زمن الاستجابة). أمّا في تطبيقات الميدان التي تغلب عليها النماذج والقوائم، فيتيح التطوير متعدّد المنصّات النشر في المتجرين بقاعدة شيفرة واحدة. ويُتّخذ القرار بحسب كثافة استخدام العتاد.
هل يلزم تشفير البيانات المحلّية؟
يلزم إذا كان الجهاز يحتفظ ببيانات العملاء أو الأسعار أو التحصيل. كما ينبغي التخطيط لقدرة إنهاء الجلسة عن بُعد ومسح البيانات المحلّية عند فقدان الجهاز.
كيف يُعرَض للمستخدم اكتمال المزامنة؟
عرض الحالة على مستوى كلّ سجلّ هو الأسلوب الأوثق: قيد الانتظار، أُرسل، اعتُمد. أمّا مؤشّر «تمّت المزامنة» العام الواحد فيُخفي حالات الفشل الجزئي.