18 سبتمبر 2025·8 دقيقة
كيفية بناء تطبيق محمول لجمع البيانات الميدانية دون اتصال
تعلّم كيفية التخطيط والتصميم وبناء تطبيق موبايل يركز على العمل دون اتصال لجمع البيانات الميدانية، بما في ذلك التخزين، المزامنة، حل التعارضات، الأمن، والاختبار.
تعلّم كيفية التخطيط والتصميم وبناء تطبيق موبايل يركز على العمل دون اتصال لجمع البيانات الميدانية، بما في ذلك التخزين، المزامنة، حل التعارضات، الأمن، والاختبار.
قبل اختيار الأدوات أو البدء في تصميم الشاشات، كن واضحًا جدًا بشأن كيفية سير العمل في الميدان—وماذا يعني "دون اتصال" لفريقك. هذا القسم يهدف إلى تحويل الروتينات الحقيقية إلى متطلبات يمكنك بناؤها، اختبارها، ودعمها.
ابدأ بتسمية الأدوار: مفتشون، مسحون، فنيو صيانة، مراجِعون، عمال مجتمعيون، أو مقاولون. كل دور عادةً ما يواجه قيودًا مختلفة (معدات واقية، استخدام بيد واحدة، أيام سفر طويلة، أجهزة مشتركة).
وثّق أين يعملون: مرافق داخلية، أقبية، طرق نائية، مزارع، مواقع إنشاءات، أو عَبْر الحدود. سجّل حقائق عملية مثل التغطية المتقطعة، فرص الشحن، وما إذا كان بإمكان المستخدمين الابتعاد "للانتظار للمزامنة" (معظمهم لا يستطيعون).
سجّل السجلات التي يجب على التطبيق جمعها وإرفاقها بمهمة، أصل، موقع، أو عميل. كن محددًا بشأن كل حقل ونوع ملف، على سبيل المثال:
حدد أيضًا ماذا يعني "مكتمل": هل يمكن حفظ السجل كمسودة، إرساله، ثم اعتماده لاحقًا؟
حدد أهداف تشغيلية مثل أقصى أيام دون اتصال، السجلات المتوقعة لكل جهاز، والحجم الأقصى للمرفقات. هذه الأرقام تحدد احتياجات التخزين المحلي، قيود الأداء، وسلوك المزامنة.
اشمل قيود الحافة: أجهزة مشتركة، مهام متعددة في اليوم، وما إذا كان يجب على المستخدمين البحث في سجلات سابقة أثناء عدم الاتصال.
حدد أي بيانات تعريف شخصية متضمنة، متطلبات الموافقة، قواعد الاحتفاظ، ومسارات التدقيق. إذا كانت الموافقات مطلوبة (مراجعة مشرف، فحوص QA)، عرف أي إجراءات يجب حظرها دون اتصال وأيها يمكن وضعها في قائمة انتظار للإرسال لاحقًا.
تصميم offline-first يبدأ بنطاق صارم وواضح. كل ميزة تسمح بها دون اتصال تزيد من التخزين المحلي، تعقيد المزامنة، ومخاطر التعارض—فقَسّم ما يجب أن يعمل عندما يفقد الإشارة.
لأغلب فرق جمع البيانات الميدانية، يحتاج تطبيق دون اتصال لدعم مجموعة أساسية من الإجراءات دون الاعتماد على الشبكة:
كن صريحًا بشأن ما يمكن أن يكون "للقراءة فقط" مقابل ما هو قابل للتعديل بالكامل. السماح بالتحرير دون اتصال عادةً يعني أنك ستحتاج إلى مزامنة لاحقة مع حل تعارضات.
طريقة عملية لتقليل تعقيد العمل دون اتصال هي إطلاق أصغر حل يعمل أولًا:
إذا أجبرت ميزة "جميل أن تتوافر" على كاش مرجعي ضخم أو دمج معقد، أجّلها حتى يصبح مسار العمل الأساسي موثوقًا.
بعض الإجراءات ينبغي حظرها دون اتصال (أو عند أن تكون بيانات المراجع قديمة). أمثلة:
استخدم قواعد واضحة مثل "السماح بالمسودة دون اتصال، تتطلب المزامنة للإرسال".
لا تُخفِ الاتصال—اجعله واضحًا:
تحويل هذا النطاق إلى عقدة لكل قرار لاحق: نموذج البيانات، المزامنة الخلفية، وأمان الجهاز دون اتصال.
هندسة تطبيقك دون الاتصال يجب أن تجعل "انعدام الاتصال" الحالة الطبيعية، لا الاستثناء. الهدف هو الحفاظ على إدخال بيانات سريع وآمن على الجهاز، مع جعل المزامنة متوقعة عند عودة الاتصال.
ابدأ بتقرير ما إذا كنت تبني لـ iOS، Android، أو كليهما.
إذا كان المستخدمون في الغالب على منصة واحدة (شائع في المؤسسات)، يمكن للبناء الأصلي أن يُبسط ضبط الأداء، سلوك الخلفية، وميزات التخزين/الأمن الخاصة بنظام التشغيل. إذا احتجت iOS وAndroid من اليوم الأول، أطر العمل العابرة للمنصات مثل React Native أو Flutter تقلل من تكرار واجهة المستخدم—لكنك ستحتاج إلى تعامل واعٍ بالمنصة لخدمات الخلفية، الأذونات (GPS/كاميرا)، وتخزين الملفات.
إذا كنت تتحرك بسرعة وتريد مسارًا رأييًا، قد يساعد توحيد مجموعة تقنيات صغيرة عبر الويب، الخلفية، والموبايل. على سبيل المثال، منصات مثل Koder.ai مصممة حول سير عمل مدفوع بالدردشة لبناء تطبيقات ويب، خوادم، وموبايل (عادة React للويب، Go + PostgreSQL للخلفية، وFlutter للموبايل). حتى إن لم تتبنَّ منصة كاملة، فالعقلية الموحدة تسهّل تطوير بنهج offline-first وقابليته للتوسع.
تعيش أو تموت التطبيقات دون اتصال بقاعدة بياناتها على الجهاز. الخيارات النموذجية:
أيًا كان اختيارك، أعطِ الأولوية لترحيلات موثوقة، أداء استعلامات على الأجهزة القديمة، ودعم التشفير.
REST وGraphQL كلاهما قد يعملان للمزامنة دون اتصال، لكن اختر واحدًا وصمّمه مع التغير عبر الزمن في الحسبان.
أضف استراتيجية إصدار صريحة (مثلاً /v1 أو إصدارات سكيمة) حتى تستمر نسخ التطبيق القديمة في المزامنة بأمان أثناء النشر.
الصور والتوقيعات والصوت والمستندات تحتاج خطة خاصة:
فصل نظيف—واجهة المستخدم → قاعدة بيانات محلية → عامل مزامنة → API—يبقي الالتقاط دون اتصال موثوقًا حتى مع شبكات غير متوقعة.
فرق الميدان لا "تملأ نموذجًا" مثل مستخدمي المكتب. إنهم واقفون في المطر، يتحركون بين المواقع، ويتعرضون للمقاطعات. عملك أن تجعل التقاط البيانات غير قابل للكسر—حتى عند فقد الاتصال.
ابدأ بمحرك نماذج يعامل كل ضغط مفتاح كقيمة ثمينة. احفظ المسودات تلقائيًا محليًا (ليس فقط عند الإرسال)، واجعل الحفظ غير مرئي: لا دوامات تحميل، لا حوار "الرجاء الانتظار" الذي يوقف المستخدم.
حقّق التحقق محليًا حتى يتمكن المستخدم من إنهاء المهمة بدون الشبكة. اجعل القواعد بسيطة وسريعة (الحقول المطلوبة، النطاقات، الصيغ الأساسية). إذا تطلبت بعض الفحوص تحققًا من الخادم (مثلاً التحقق من معرف)، ضع علامة عليها بوضوح كـ "سيتم التحقق أثناء المزامنة" ودع المستخدم يتابع.
تجنّب الشاشات الثقيلة. قسم العمليات الطويلة إلى خطوات أصغر مع تقدم واضح (مثلاً "1 من 4"). هذا يقلل من الأعطال، يجعل الاستئناف أسهل، ويحسن الأداء على الأجهزة القديمة.
عمليات الفحص الحقيقية تتضمن غالبًا أنماط "أضف عنصرًا آخر": أصول متعددة، قراءات، أو عيوب. ادعم الأقسام المتكررة بـ:
يجب أن تكون الأسئلة الشرطية حتمية دون اتصال. اجعل الشروط مبنية فقط على القيم الموجودة بالفعل على الجهاز (إجابات سابقة، دور المستخدم، نوع الموقع المحدد)، وليس على استعلام خادم.
اجعل التطبيق يجمع السياق تلقائيًا عندما يكون ذا صلة:
خزن هذه الإشارات جنبًا إلى جنب مع القيم المدخلة حتى تتم مراجعة السجل وثوقيته لاحقًا.
عامل كل مرفق كمهمة صغيرة منفصلة. ضع الرفع في قائمة انتظار مستقلة عن مزامنة النموذج، ادعم المحاولة/الاستئناف، وأظهر حالة لكل ملف: معلق، جاري الرفع، فشل، تم الرفع. دع المستخدمين يستمرون في العمل أثناء رفع المرفقات في الخلفية، ولا تقفل إرسال النموذج على انتظار رفع فوري إذا كان الجهاز دون اتصال.
فرق الميدان نادرًا ما تعمل بـ"نموذج فقط". يحتاجون أيضًا لمعلومات مرجعية—قوائم أصول، مواقع عملاء، كتالوجات، قوائم اختيار—وغالبًا ما يحتاجون لخريطة تعمل عند فقد الإشارة. اعتبر هذه الميزات من الدرجة الأولى، لا من الكماليات.
حدد أصغر مجموعة بيانات مرجعية تجعل سير العمل ممكنًا (مثلاً أوامر العمل المخصصة، معرفات الأصول، المواقع، القيم المسموحة). ادعم التنزيل الجزئي حسب المنطقة، المشروع، الفريق، أو نطاق التاريخ حتى لا يضطر الجهاز لتخزين كل شيء.
نهج عملي هو شاشة "تحميل للاستخدام دون اتصال" تُظهر:
إن احتاج الفنيون إلى ملاحة وسياق، نفّذ خرائط دون اتصال عبر جلب مربعات لمنطقة محددة (مثلاً مربع يحيط بموقع العمل أو ممر مسار). فرض حدود على الكاش—سواء الحجم الكلي أو لكل منطقة—لتجنب فشل التخزين الصامت.
أضف عناصر تحكم لِـ:
دون بحث سريع، يكون الوصول دون اتصال محبطًا. فهرس الحقول الأساسية محليًا (معرفات، أسماء، علامات، عناوين) وادعم فلاتر تتماشى مع المهام الحقيقية (مشروع، حالة، مخصصة لي). الاستعلامات المحفوظة ("مواقعي هذا الأسبوع") تقلل النقرات وتجعل وضع عدم الاتصال متعمدًا.
اعرض دائمًا "حدثية" بيانات المراجع ومناطق الخريطة: وقت آخر مزامنة، إصدار مجموعة البيانات، وما إذا كانت توجد تحديثات معلقة. إذا كانت بيانات ما قديمة، أظهر لافتة واضحة ودع المستخدم يستمر مع قيود معرفة—مع وضع تجديد في قائمة الانتظار عند الاتصال التالي.
المزامنة هي الجسر بين ما يحدث في الميدان وما يراه المكتب لاحقًا. استراتيجية موثوقة تفترض أن الاتصال غير متوقع، البطاريات محدودة، وقد يغلق المستخدم التطبيق أثناء الرفع.
تحتاج الفرق المختلفة توقيتات مختلفة. المشغلات الشائعة:
غالبًا ما تجمع التطبيقات بينهما: مزامنة خلفية افتراضية وزر يدوي للطمأنة.
عامل كل إنشاء/تحديث/حذف كحدث محلي يُكتب إلى قائمة الانتظار. يقرأ محرك المزامنة الصندوق، يرسل التغييرات إلى الخادم، ويعلم كل حدث عند التأكيد.
هذا يجعل المزامنة متينة: يمكن للمستخدمين الاستمرار في العمل، وتعرف دائمًا ماذا تبقى للرفع.
شبكات المحمول تفقد حزمًا، وقد يضغط المستخدم "مزامنة" مرتين. صمّم الطلبات بحيث لا تُكرر السجلات عند تكرارها.
تكتيكات عملية:
بعد يوم دون اتصال، قد تكون عمليات الرفع ضخمة. منع انتهاء المهلة والحدّ عبر:
اطمح لإظهار تقدم مرئي ("23 من 120 عنصرًا تم رفعها") حتى يثق فريق الميدان في التطبيق.
العمل دون اتصال يعني وجود نسختين من الحقيقة: ما تغيّر على الجهاز وما تغيّر على الخادم. إن لم تخطط لذلك ستحصل على استبدالات غامضة، قيم مفقودة، وتذاكر دعم لا يمكن تكرارها.
ابدأ بتحديد ما يجب أن يفعله التطبيق عند تحرير نفس السجل في مكانين.
اكتب هذه القواعد وأعد استخدامها عبر التطبيق. "يعتمد الأمر" مقبول طالما أنه متوقع لكل نوع سجل.
لسجلات عالية القيمة، لا تدمج تلقائيًا. اعرض واجهة تعارض تجاوب على سؤالين:
دع المستخدم يختار: احتفظ بعملي، احتفظ بعمل الخادم، أو (إن دعمت) قبول التغييرات حقل-بحقل. استخدم صياغة بسيطة—تجنب الطوابع الزمنية التقنية ما لم تكن مفيدة فعلًا.
أفضل تعارض هو الذي لا تنشئه. تكتيكات شائعة للمنع تتضمن قفل خفيف للسجل، تخصيص العمل (شخص واحد يملك المهمة)، أو نوافذ تحرير (تصبح السجلات للقراءة فقط بعد الإرسال).
تحقّق محليًا باستخدام نفس قواعد الخادم (حقول مطلوبة، نطاقات) لتقليل مفاجآت الرفض أثناء المزامنة.
عامل المزامنة كعملية أعمال: خزّن سجل مزامنة محليًا مع طوابع زمنية، رموز خطأ، وعدد محاولات كل سجل. عند إبلاغ المستخدم "تحديثي اختفى" ستكون قادرًا على تتبع ما إذا فشل الرفع، تعارض، أو رُفض بواسطة تحقق الخادم.
جمع البيانات الميدانية غالبًا يتضمن تفاصيل عملاء، مواقع، صور، وملاحظات فحص. عند تخزين هذه البيانات محليًا للاستخدام دون اتصال، يصبح الهاتف جزءًا من حدود الأمان لديك.
إذا جمعت معلومات حساسة أو خاضعة للتنظيم، شفر البيانات الراقدة في قاعدة البيانات المحلية وأي تخزين ملفات للمرفقات. على iOS وAndroid اعتمد على مخازن المفاتيح المدعومة من النظام (Keychain / Keystore) لحماية مفاتيح التشفير—لا تُشفِر أسرارًا في الكود، ولا تخزن المفاتيح في تفضيلات نصية.
نهج عملي: شفر قاعدة البيانات المحلية، شفر المرفقات الكبيرة بشكل منفصل، وجدد المفاتيح عند خروج المستخدم أو عندما تتطلب السياسات ذلك.
استخدم مصادقة قوية ورموز وصول قصيرة العمر. حدد ماذا يعني "دون اتصال" بعد تسجيل الدخول:
هذا يحد من التعرض إذا فُقد الجهاز ويمنع وصولًا دائمًا للبيانات المخبأة.
يُستخدم التطبيق الميداني في أماكن عامة—مستودعات، مواقع عمل، ردهات—فحماية مستوى الشاشة مهمة.
البيانات دون اتصال قد تُعدّل قبل المزامنة. قلل خطر العبث عبر تصميم للتحقق:
هذه الخطوات لا تلغي كل المخاطر، لكنها تجعل التخزين دون اتصال أكثر أمانًا دون جعل التطبيق مزعجًا.
مستخدمي الميدان يهتمون أقل بـ"التقنية" وأكثر بما إذا كان التطبيق يخبرهم بما يحدث ويجعلهم يستمرون في العمل. تصميم offline-first مشكلة تجربة مستخدم بقدر ما هو هندسة: إن لم يثق الناس بالحالة فسيخلقون حلولًا بديلة (ملاحظات ورقية، إرسال مكرر، لقطات شاشة).
اعرض الاتصال وحالة المزامنة في أماكن ينظر إليها المستخدمون طبيعيًا—دون ضجيج.
استخدم مؤشر حالة بسيط (مثلاً Offline / Syncing / Up to date) واظهر دائمًا طابع زمني لـ آخر مزامنة. عند حدوث خطأ، أظهر لافتة خطأ تبقى مرئية حتى يتصرف المستخدم أو تُحل المشكلة.
مؤشرات جيدة تساعد المستخدمين على الإجابة:
حتى أفضل مزامنة خلفية قد تتوقف بسبب شبكات ضعيفة، قيود الخلفية في نظام التشغيل، أو أخطاء الخادم. قدم ضوابط تطابق سير العمل الحقيقي:
إذا دعم تطبيقك المزامنة الخلفية، اجعلها شفافة: أظهر عدد العناصر في القائمة (مثال: "3 عناصر في الانتظار").
تجنّب أخطاء غامضة مثل "فشل المزامنة." استخدم لغة بسيطة تشرح ما حدث وما يجب فعله.
أمثلة:
اربط الرسائل بزر إجراء واضح ("حاول مرة أخرى"، "افتح الإعدادات"، "اتصل بالدعم") حتى يتمكن المستخدم من الاسترداد بسرعة.
جمع البيانات الميدانية غالبًا على هواتف قديمة بمساحة محدودة وشحن غير منتظم. حَسّن للموثوقية:
عندما يكون التطبيق متوقعًا تحت ظروف الاتصال الضعيف، سيثق به المستخدمون—وسيصبح اعتماده أسهل.
تطبيقات الميدان دون اتصال لا تفشل في المختبر—تفشل على جانب طريق مع بطارية 2% وإشارة متقطعة. يتعين على الاختبار أن يعكس تلك الواقع، خصوصًا حول المزامنة، المرفقات، والتقاط GPS.
غطِّ أكثر من "لا إنترنت". أنشئ قائمة اختبار قابلة للتكرار تتضمّن:
تحقق من قدرة المستخدم على الاستمرار في العمل، ثبات قاعدة البيانات المحلية، ووضوح واجهة المستخدم فيما تم حفظه محليًا مقابل ما تم مزامنته.
أخطاء المزامنة تظهر غالبًا بعد محاولات متكررة. أضف اختبارات آلية (وحدات + تكامل) التي تتحقق من:
إن أمكن، شغّل هذه الاختبارات مقابل خادم staging يقوم بحقن أعطال (انتهاء مهلة، 500s، واستجابات بطيئة) لمحاكاة ظروف الميدان.
خطط لـ "أيام متعددة دون اتصال" و"تزامن كل شيء دفعة واحدة." اختبر ضغطًا بآلاف السجلات، مرفقات كثيرة، وتعديلات على عناصر قديمة. قِس استهلاك البطارية، نمو التخزين على الجهاز، وزمن المزامنة على هواتف ذات مواصفات منخفضة.
قم بتجارب ميدانية قصيرة واجمع الملاحظات فورًا: أي نماذج موبايل مربكة، أين تمنع الفحوص التقدم، وما الذي يجعل المزامنة تبدو بطيئة. كرر على تدفق النموذج وقواعد حل التعارضات قبل النشر الواسع.
إطلاق تطبيق ميداني دون اتصال ليس نهاية المسيرة—هو لحظة تبدأ فيها أنماط الاتصال والأجهزة وسلوك المستخدم الحقيقي بالظهور. عامل الإصدارات الأولى كمرحلة تعلم، مع مقاييس واضحة ودورة ملاحظات سريعة.
أضف قياسات خفيفة حتى تتمكن من الإجابة بسرعة:
سجّل أسباب فشل المزامنة عندما أمكن (انتهاء صلاحية المصادقة، حمولة كبيرة جدًا، تحقق الخادم، مهلة الشبكة) دون تسجيل بيانات حساسة.
تفشل التطبيقات دون اتصال بطرق متوقعة. اكتب دليلًا بسيطًا داخليًا لتشخيص:
اجعل الدليل قابلًا للاستخدام من قبل غير المهندسين (الدعم والعمليات)، وضمّن ما تطلبه من المستخدم (مثلاً فتح التطبيق على Wi‑Fi، إبقاءه في المقدمة لمدة دقيقتين، التقاط معرف سجل تشخيصي).
تطبيقات offline-first تحتاج ترقيات آمنة. صنف سكيمة قاعدة البيانات المحلية وإرفاق ترحيلات مُختبرة (إضافة أعمدة، تعبئة قيم افتراضية، إعادة فهرسة). كما صنّف عقود API حتى تتعامل نسخ التطبيقات القديمة برفق بدلاً من إسقاط حقول بصمت.
أنشئ أدلة تدريب قصيرة لفرق الميدان: كيفية التأكد أن البيانات محفوظة، كيفية معرفة حالة "قيد الانتظار للرفع"، ومتى يجب إعادة المحاولة.
إذا كنت تنتج محتوى أو تمكين داخلي حول إطلاق offline-first، فكر في حوافز للتبني. على سبيل المثال، Koder.ai يقدم برنامج "كسب أرصدة" لإنشاء محتوى حول المنصة وبرنامج إحالة—وكلاهما مفيد لفرق توثيق نهج البناء وتشجيع الاستخدام.
إذا احتجت مساعدة في نطاق الإطلاق أو الدعم، وجه الأطراف المعنية إلى /pricing أو /contact.
ابدأ بتدوين الأهداف التشغيلية:
تحدد هذه الأرقام مباشرة احتياجات التخزين المحلي، أداء قاعدة البيانات، وما إذا كانت المزامنة يجب أن تكون متزايدة أو مجمعة أو عبر Wi‑Fi فقط.
قم بتوثيق:
حوّل هذا إلى متطلبات قابلة للاختبار مثل "إنشاء فحص كامل في وضع الطائرة" و"إتمام مهمة دون أي نوافذ انتظار".
تبدأ معظم الفرق بدائرة عمل صغيرة تُبقي العمل متحركًا:
اجعل الميزات الثقيلة (لوحات تحكم غير متصلة، بحث عالمي واسع، موافقات متعددة المراحل) لاحقة بعد أن تصبح عملية الالتقاط والمزامنة الأساسية موثوقة.
استخدم قواعد بسيطة تقلل المخاطر:
اجعل القاعدة مرئية في واجهة المستخدم (مثال: "تم حفظ المسودة. يتطلب الإرسال مزامنة").
اختر قاعدة بيانات محلية تدعم:
خيارات شائعة:
صمّم البيانات كـ "عمل جاري" وليس فقط كسجل نهائي:
عامل المرفقات كمهام صغيرة منفصلة:
لا تُعرقل إكمال النموذج بالانتظار لرفع الملفات فورًا؛ اترك السجل يتزامن والمرفقات تُلحَق عند استعادة الاتصال.
استخدم نمط الصندوق الصادر (outbox):
اجعل الأحداث قابلة للتكرار دون تأثير (idempotent) عبر معرفات عميل ثابتة ومعرفات طلب فريدة. اجمع بين المشغلات (المزامنة الخلفية أثناء فتح التطبيق + زر "المزامنة الآن") وتعامل مع الطوابير الكبيرة بالدفعات، التجزئة، وإعادة المحاولة بتراجع.
حدد وسجل قواعد واضحة لكل نوع سجل:
لسجلات عالية القيمة (فحوص، توقيعات)، اعرض شاشة تعارض توضح الفرق بين و ودع المستخدم يختار (الخاص بي، خادم، أو دمج حقل-بحقل).
ركّز على مخاطر الجهاز وإمكانية المراجعة:
هذه الخطوات تقلل المخاطر دون جعل التطبيق مرهقًا للاستخدام.
أجب عن الأسئلة الأساسية التي يهتم بها المستخدم الميداني:
استخدم مؤشر حالة بسيط (مثال: Offline / Syncing / Up to date) واظهر دائمًا طابع زمني لـ آخر مزامنة. عند حدوث خطأ، اعرض لافتة توضح المشكلة حتى يتمكن المستخدم من فهمها والتصرف.
قم بمحاكاة أكثر من مجرد "لا إنترنت". نصّب قائمة اختبار قابلة للتكرار تتضمّن:
تحقق من أن المستخدم يمكنه الاستمرار في العمل، وأن قاعدة البيانات المحلية تبقى متسقة، وأن واجهة المستخدم توضح ما تم حفظه محليًا مقابل ما تم مزامنته.
اختر بناءً على منصة فريقك واحتياجك لأداء متوقع على أجهزة قديمة.
created_atupdated_atdevice_iduser_idversionهذا يجعل التحريرات، الحذف، وإعادة المحاولة متوقعة بعد إعادة تشغيل التطبيق.