شبكات Kotlin للاتصالات البطيئة: المهلات وإعادة المحاولة الآمنة

ماذا يتعطل على الاتصالات البطيئة والمزعجة

على المحمول، "بطيء" عادة لا يعني "لا إنترنت". غالبًا ما يعني اتصالًا يعمل لكن فقط لفترات قصيرة. قد يستغرق الطلب 8 إلى 20 ثانية، يتوقف في المنتصف، ثم يكتمل. أو قد ينجح لحظة ويفشل في اللحظة التالية لأن الهاتف غيّر من Wi‑Fi إلى LTE، دخل منطقة إشارة منخفضة، أو وضع النظام التطبيق في الخلفية.

والشبكات "المزعجة" أسوأ. تُفقد الحزم، تنتهي مهلات DNS، تفشل مصافحات TLS، وتُعاد تعيين الاتصالات عشوائيًا. يمكنك أن تفعل كل شيء "صحيحًا" في الكود ومع ذلك ترى حالات فشل في الواقع لأن الشبكة تتغير تحت قدميك.

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

المستخدمون لا يصفون "مهلات المقبس" أو "HTTP 503". إنهم يلاحظون الأعراض: دوارات تحميل بلا نهاية، أخطاء مفاجِئة بعد انتظار طويل (ثم ينجح الأمر في المحاولة التالية)، إجراءات مكررة (حجزان، طلبيتان، رسوم مضاعفة)، تحديثات مفقودة، وحالات مختلطة حيث تقول واجهة المستخدم "فشل" بينما الخادم نجح فعلاً.

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

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

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

قرر قواعدك قبل ضبط الكود

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

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

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

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

أخيرًا، قرر ما الذي ستخزنه على الجهاز ولأي مدة. التخزين المؤقت مفيد، لكن البيانات القديمة قد تؤدي إلى قرارات خاطئة (أسعار قديمة، صلاحية منتهية).

اكتب القواعد في مكان يمكن للجميع العثور عليه (README يكفي). اجعلها بسيطة:

• أي نقاط النهاية "لا يجب تكرارها" وتحتاج لمعالجة idempotency؟
• أي الشاشات يجب أن تعمل دون اتصال، وأيّها قراءة فقط عند فقدان الشبكة؟
• ما أقصى وقت انتظار لكل إجراء (تسجيل دخول، تحديث الخلاصة، رفع، الدفع)؟
• ما الذي يمكن تخزينه على الجهاز ومدة صلاحيته؟
• بعد الفشل، هل تعرض خطأ، تؤجل للعمل لاحقًا، أم تطلب إعادة المحاولة يدويًا؟

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

مهلات تناسب توقعات المستخدم الحقيقية

تفشل الشبكات البطيئة بطرق مختلفة. إعداد المهلات الجيد لا يختار رقمًا فحسب. إنه يطابق ما يحاول المستخدم فعله ويفشل بسرعة كافية ليتمكن التطبيق من التعافي.

الثلاث مهلات، ببساطة:

• مهلة الاتصال (connect timeout): كم تنتظر لإقامة الاتصال بالخادم (بحث DNS، TCP، TLS). إذا فشل هذا، الطلب لم يبدأ حقًا.
• مهلة الكتابة (write timeout): كم تنتظر أثناء إرسال جسم الطلب (رفع ملفات، JSON كبير، صعود بطيء).
• مهلة القراءة (read timeout): كم تنتظر أن يرسل الخادم البيانات بعد إرسال الطلب. يظهر هذا كثيرًا على الشبكات الخلوية المتقطعة.

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

نقطة انطلاق عملية (اضبط بعد القياس):

• تحميل القوائم (مخاطرة منخفضة): connect 5–10s، read 20–30s، write 10–15s.
• بحث أثناء الكتابة: connect 3–5s، read 5–10s، write 5–10s.
• الإجراءات الحرجة (عالية المخاطرة، مثل "ادفع" أو "أرسل طلب"): connect 5–10s، read 30–60s، write 15–30s.

الاستمرارية أهم من الكمال. إذا ضغط المستخدم "إرسال" ورأى دولابًا لمدة دقيقتين، سيضغط مرة أخرى.

تجنب "التحميل اللامتناهي" بإضافة حد أعلى واضح في واجهة المستخدم أيضًا. أظهر تقدمًا فورًا، اسمح بالإلغاء، وبعد (مثلاً) 20–30 ثانية اعرض "ما زلنا نحاول…" مع خيارات لإعادة المحاولة أو فحص الاتصال. هذا يحافظ على تجربة صادقة حتى لو كانت مكتبة الشبكة لا تزال تنتظر.

عندما تحدث مهلة، سجّل ما يكفي لتحليل الأنماط لاحقًا بدون تسريب أسرار. الحقول المفيدة تشمل مسار URL (ليس الاستعلام الكامل)، طريقة HTTP، الحالة (إن وُجدت)، تفصيل زمني (connect مقابل write مقابل read إذا توفّر)، نوع الشبكة (Wi‑Fi، خلوي، وضع الطيران)، حجم الطلب/الاستجابة التقريبي، ومعرّف الطلب لربط سجلات العميل بسجلات الخادم.

إعداد Kotlin شبكي بسيط ومتسق

عند الشبكات البطيئة، التحزّمات الصغيرة في إعداد العميل تتحول إلى مشاكل كبيرة. قاعدة نظيفة تساعدك على التصحيح أسرع وتعطي كل طلب نفس القواعد.

عميل واحد، سياسة واحدة

ابدأ بمكان واحد تبني فيه عميل HTTP (غالبًا OkHttpClient مستخدم بواسطة Retrofit). ضع الأساسيات هناك حتى يتصرف كل طلب بنفس الطريقة: رؤوس افتراضية (إصدار التطبيق، اللغة، توكن المصادقة) وUser‑Agent واضح، مهلات مضبوطة مرة واحدة (لا تُبعثر عبر النداءات)، تسجيل يمكنك تفعيله للتصحيح، وقرار سياسة إعادة المحاولة واحد (حتى لو كان "لا إعادة محاولات تلقائية").

ها هو مثال صغير يحافظ على التكوين في ملف واحد:

val okHttp = OkHttpClient.Builder()
  .connectTimeout(10, TimeUnit.SECONDS)
  .readTimeout(20, TimeUnit.SECONDS)
  .writeTimeout(20, TimeUnit.SECONDS)
  .callTimeout(30, TimeUnit.SECONDS)
  .addInterceptor { chain -\u003e
    val request = chain.request().newBuilder()
      .header("User-Agent", "MyApp/${BuildConfig.VERSION_NAME}")
      .header("Accept", "application/json")
      .build()
    chain.proceed(request)
  }
  .build()

val retrofit = Retrofit.Builder()
  .baseUrl(BASE_URL)
  .client(okHttp)
  .addConverterFactory(MoshiConverterFactory.create())
  .build()

(لا تُغير كتلة الكود أعلاه؛ إبقها كما هي.)

معالجة أخطاء مركزية تترجم إلى رسائل للمستخدم

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

أنشئ محولًا واحدًا يترجم الفشل إلى مجموعة صغيرة من النتائج المفهومة للمستخدم: لا اتصال/وضع طيران، مهلة، خطأ خادم (5xx)، خطأ تحقق/مصادقة (4xx)، وحالة غير معروفة كاحتياط.

هذا يحافظ على نسق رسائل الواجهة ثابتًا ("لا اتصال" مقابل "أعد المحاولة") دون تسريب تفاصيل فنية.

علم وإلغاء الطلبات عند غلق الشاشات

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

مع Retrofit وKotlin coroutines، إلغاء نطاق الكوروتين (مثلاً في ViewModel) يلغي نداء HTTP الأساسي. بالنسبة للنداءات غير المعتمدة على الكوروتين، احتفظ بمرجع لـ Call ونادِ cancel(). يمكنك أيضًا وسم الطلبات وإلغاء مجموعات من النداءات عند الخروج من ميزة.

العمل في الخلفية يجب ألا يعتمد على الواجهة

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

قواعد التخزين المؤقت الآمنة على الجوال

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

النهج الآمن هو تخزين ما يمكن للمستخدم تحمله أن يكون قديمًا قليلًا، وطلب تحقق جديد لأي شيء يؤثر على المال أو الأمان أو القرار النهائي.

أساسيات Cache‑Control التي يمكنك الاعتماد عليها

معظم القواعد تتلخص في رؤوس قليلة:

• max-age=60: يمكنك إعادة استخدام الاستجابة المخزّنة لمدة 60 ثانية دون سؤال الخادم.
• no-store: لا تحفظ هذه الاستجابة إطلاقًا (الأفضل للتوكنات والشاشات الحساسة).
• must-revalidate: إذا انتهت صلاحيتها، يجب التحقق من الخادم قبل استخدامها مرة أخرى.

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

تحديثات ETag: سريعة ورخيصة وموثوقة

لنقاط النهاية للقراءة، التحقق بواسطة ETag غالبًا أفضل من قيم max-age الطويلة. يرسل الخادم ETag مع الاستجابة. في المرة التالية، يرسل التطبيق If-None-Match بالقيمة. إذا لم يتغير شيء، يرد الخادم 304 Not Modified، وهي استجابة صغيرة وسريعة على الشبكات الضعيفة.

هذا يعمل جيدًا لقوائم المنتجات، تفاصيل الملف الشخصي، وشاشات الإعدادات.

قاعدة بسيطة:

• خزّن نقاط النهاية للقراءة بقيمة max-age قصيرة زائد must-revalidate، وادعم ETag حيث أمكن.
• لا تخزن نقاط النهاية الخاصة بالكتابة (POST/PUT/PATCH/DELETE). اعتبرها دائمًا معتمدة على الشبكة.
• استخدم no-store لأي شيء حساس (ردود المصادقة، خطوات الدفع، رسائل خاصة).
• خزّن الأصول الثابتة (أيقونات، إعداد عام عام) لفترة أطول لأن خطر قدومها قديمًا منخفض.

اجعل قرارات التخزين المؤقت متسقة عبر التطبيق. المستخدمون يلاحظون الاختلافات أكثر من التأخيرات الصغيرة.

إعادة المحاولة الآمنة دون زيادة الضرر

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

ابدأ بإعادة المحاولة فقط للأخطاء التي من المرجح أن تكون مؤقتة. انقطاع الاتصال، مهلة القراءة، أو انقطاع مؤقت في الخادم يمكن أن ينجح في المحاولة التالية. كلمة مرور خاطئة، حقل مفقود، أو 404 لن ينجحوا في المحاولة التالية.

قواعد عملية:

• أعد المحاولة في حالات المهلات وانقطاعات الاتصال.
• أعد المحاولة على 502، 503، وأحيانًا 504.
• لا تعيد المحاولة على 4xx (باستثناء 408 أو 429 إذا كان لديك قاعدة انتظار واضحة).
• لا تعيد المحاولة للطلبات التي وصلت بالفعل للخادم وقد تُعالج.
• اجعل عدد المحاولات قليلًا (غالبًا 1 إلى 3 محاولات).

تراجع أُسّي + jitter: تقليل موجات إعادة المحاولة

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

مثال: انتظر ~0.5 ثانية، ثم 1 ثانية، ثم 2 ثانية، مع انحراف عشوائي ±20% في كل مرة.

ضع حدًا للوقت الإجمالي لإعادة المحاولة

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

ووافق السياق. إذا كان المستخدم يرسل نموذجًا، يريد جوابًا سريعًا. إذا فشل تزامن في الخلفية، يمكنك إعادة المحاولة لاحقًا.

لا تعيد المحاولة آليًا على الأفعال غير المعاملية (مثل وضع طلب أو إرسال دفعة) ما لم تكن محميًا بمفتاح idempotency أو تحقق مكرر على الخادم. إذا لم تستطع ضمان الأمان، فافشل بوضوح ودع المستخدم يقرر الخطوة التالية.

منع التكرار للإجراءات الحرجة

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

تعني idempotency أن نفس الطلب يجب أن ينتج نفس النتيجة. إذا تكرر الطلب، يجب أن يعيد الخادم النتيجة الأولى أو يقول "مُنجز بالفعل".

استخدم مفتاح idempotency لكل محاولة حرجة

للإجراءات الحرجة، أنشئ مفتاح idempotency فريد عندما يبدأ المستخدم المحاولة، وارْسله مع الطلب (غالبًا في رأس مثل Idempotency-Key، أو حقل في الجسم).

تدفق عملي:

• أنشئ UUID كمفتاح idempotency عندما يضغط المستخدم "ادفع".
• خزّنه محليًا بسجل صغير: الحالة = pending، createdAt، هاش حمولة الطلب.
• أرسل الطلب مع المفتاح.
• عند استلام استجابة نجاح، علّم الحالة = done وخزن معرّف نتيجة الخادم.
• إذا احتجت لإعادة المحاولة، أعد استخدام نفس المفتاح لا مفتاح جديد.

قاعدة "إعادة استخدام نفس المفتاح" هي ما يوقف الشحنات المزدوجة عن طريق الخطأ.

تعامَل مع إعادة تشغيل التطبيق والفجوات دون اتصال

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

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

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

أنماط واجهة تقلل الإرسال المتكرر عن طريق الخطأ

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

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

الإعداد الافتراضي الجيد للإجراءات الحرجة هو حالة معلّقة واضحة. بعد الضغط الأول، غيّر الزر الأساسي فورًا إلى حالة "جارٍ الإرسال…"، عطله، وأظهر سطرًا قصيرًا يشرح ما يجري.

أنماط تعمل جيدًا على الشبكات المزعجة:

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

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

اجعل "أعد المحاولة" صريحًا وآمنًا. أظهره فقط عندما يمكنك تكرار الطلب باستخدام نفس معرّف الطلب من جهة العميل أو نفس مفتاح idempotency.

مثال واقعي: إرسال الدفع في بيئة متقطعة

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

تسلسل آمن:

1. ينشئ التطبيق معرّف محاولة على جهة العميل ويرسل طلب الخروج مع مفتاح idempotency (مثلاً UUID مخزون مع السلة).
2. ينتظر الطلب مهلة اتصال واضحة ثم مهلة قراءة أطول. يدخل القطار نفقًا وينتهي الطلب بمهلة.
3. يعيد التطبيق المحاولة مرة واحدة فقط، وبعد تأخير قصير وفقط إذا لم يستلم استجابة من الخادم.
4. يستقبل الخادم الطلب الثاني ويرى نفس مفتاح idempotency، فيرد بالنتيجة الأصلية بدلًا من إنشاء طلب جديد.
5. يعرض التطبيق شاشة تأكيد نهائية عند استلام استجابة النجاح، حتى لو جاءت من المحاولة الثانية.

التخزين المؤقت يتبع قواعد صارمة. قوائم المنتجات، خيارات التوصيل، وجداول الضرائب يمكن تخزينها مؤقتًا لفترة قصيرة (GET). إرسال الخروج (POST) لا يُخزن أبدًا. حتى لو استخدمت كاش HTTP، اعتبره مساعدة للعرض فقط، لا شيئًا يمكنه "تذكر" دفعة.

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

قائمة مراجعة سريعة وخطوات لاحقة

إذا كان تطبيقك "يعمل بشكل معقول" على Wi‑Fi المكتب لكنه يتعطل في القطارات أو المصاعد أو المناطق النائية، اعتبر هذا بوابة إصدار. هذا العمل أقل عن كود ذكي وأكثر عن قواعد واضحة يمكن تكرارها.

قائمة المراجعة قبل الإطلاق:

• اضبط مهلات لكل نوع نقطة نهاية (تسجيل دخول، خلاصة، رفع، دفع) واختبر على شبكات مخنوقة وذات كمون عالي.
• أعد المحاولة فقط حيثما تكون آمنة فعلاً وحددها بتراجع (محاولتان أو ثلاث للقراءات، عادة لا لمحاولات للكتابات).
• أضف مفتاح idempotency لكل كتابة حرجة (مدفوعات، طلبات، إرسال نماذج) حتى لا تخلق إعادة المحاولة أو الضغط المزدوج مكررات.
• اجعل قواعد التخزين المؤقت صريحة: ما يمكن أن يُعرض كقديم، ما يجب أن يكون طازجًا، وما لا يجب أن يُخزن أبدًا.
• اجعل الحالات مرئية: pending، failed، وcompleted يجب أن تبدو مختلفة، ويجب أن يتذكر التطبيق الأفعال المكتملة بعد إعادة التشغيل.

إذا كان أحد هذه البنود "نقرّره لاحقًا"، سينتهي بك الأمر بسلوك عشوائي عبر الشاشات.

خطوات تالية لتثبيت الأمر

اكتب سياسة شبكات في صفحة واحدة: فئات نقاط النهاية، أهداف المهلات، قواعد إعادة المحاولة، وتوقعات التخزين المؤقت. طبّقها في مكان واحد (interceptors، مصنع عميل مشترك، أو غلاف صغير) حتى يحصل كل عضو فريق على نفس السلوك افتراضيًا.

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

إذا أردت تطبيق نفس القواعد عبر الخادم والعميل دون توصيل كل شيء يدويًا، AppMaster (appmaster.io) يمكن أن يساعد في توليد باك‑إند جاهز للإنتاج وكود موبايل أصلي. حتى مع ذلك، المفتاح هو السياسة: عرّف idempotency وإعادة المحاولة والتخزين المؤقت وحالات الواجهة مرة واحدة، وطبقها بشكل متسق عبر المسار الكامل.