تصميم تطبيق أعمال يعمل دون إنترنت: الحفظ والمزامنة بلا وعود مضللة

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

حدد وعدًا صغيرًا يمكن اختباره

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

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

قسم المهام حسب أثرها، لا حسب الشاشة

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

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

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

اجعل حالة الحفظ واضحة لكل تقرير

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

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

منع التكرار مسؤولية مشتركة مع الخادم

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

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

اتفق على سياسة التعارض قبل التنفيذ

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

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

الجهاز المشترك ليس مكانًا محايدًا للبيانات

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

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

اختبر يوم عمل سيئًا، لا وضع الطيران فقط

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

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

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