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