خدمة

تطوير تطبيقات الجوال

تطبيقات تواصل العمل حين تتوقف الشبكة.

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

القرار

متى يكون هذا هو القرار الصحيح.

معظم تطبيقات الجوال تُعرَض على شبكة المكتب وتُستخدم على اتصال 4G متقطع عند بوابة موقع. وتلك الفجوة هي حيث تفشل. فالتطبيق الذي يفترض الاتصال سيُلام على فقدان بيانات لم تصله أصلاً، وما إن يفقد موظفو الميدان الثقة به حتى يعودوا إلى الورق — وهي بالضبط النتيجة التي مُوِّل المشروع لمنعها.

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

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

ما الذي تحصل عليه

ما الذي يشمله العمل.

بيانات تعمل دون اتصال أولاً

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

مزامنة يمكنك فحصها

حالة المزامنة ظاهرة للمستخدم وللدعم، حتى تتحول عبارة 'لم يُحفظ' إلى سؤال له إجابة.

أصلي أم متعدد المنصات

Kotlin وSwift حيث يتطلب العتاد أو العمل في الخلفية أو الأداء ذلك؛ وقاعدة شيفرة مشتركة حيث يكون التطبيق شاشات في معظمه ويكون التوفير حقيقياً.

عمل في الخلفية يستمر فعلاً

مزامنة ورفع مجدولان يواصلان العمل تحت قيود البطارية في Android، ومختبران على واجهات المصنّعين التي تعطّلهما.

مصادقة تفشل بأمان

تُعالَج صلاحية الرموز كما ينبغي — الجلسة المنتهية تُخرج المستخدم بدل تكرار طلب ميت إلى الأبد.

هندسة الإصدارات

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

التقنيات

بماذا نبنيه.

تُختار لكل مشروع. لا شيء هنا يُفرَض افتراضياً، والفريق الذي سيصونها يزن بقدر المشكلة نفسها.

Android

Kotlin مع Jetpack Compose، وRoom للتخزين المحلي، وWorkManager للمزامنة في الخلفية.

iOS

Swift مع SwiftUI، والاعتماد على تخزين المنصة نفسه بدل طبقة وسيطة.

متعدد المنصات

React Native أو Flutter حيث يكون التطبيق قائماً على الشاشات وتوفّر قاعدة شيفرة واحدة نصف العمل فعلاً.

الواجهة الخلفية

واجهة البرمجة نفسها التي يستخدمها موقعك، مرقّمة الإصدار حتى يواصل تطبيق قديم في الميدان العمل.

التوزيع

متجر Play ومتجر App، أو توزيع مؤسسي مُدار حين يكون التطبيق داخلياً.

مقارنة

متعدد المنصات مقابل الأصلي.

أول قرار حقيقي في مشروع جوال. نحن نبني الاثنين، فهذا الجدول هو المنطق الفعلي لا ترويج لما نفضّله.

متعدد المنصات مقارنةً بالأصلي
الجانبمتعدد المنصاتأصلي
الأنسب لـنماذج وقوائم ومزامنة — تطبيقات هي في معظمها شاشات فوق واجهة برمجيةالكاميرا أو تحديد الموقع في الخلفية أو البلوتوث أو أداء متواصل
تكلفة منصتينبناء واحد تقريباً، مع لمسات خاصة بكل منصةقريب من بناءين، ومع صيانة قاعدتي شيفرة بعد ذلك
العمل دون اتصال والمزامنةممكن تماماً؛ تصميم المزامنة أهم بكثير من إطار العملالأمر نفسه — هذا قرار يخص نموذج البيانات لا المنصة
ميزات العتاد ونظام التشغيلمناسب للشائع منها؛ وأي شيء غير معتاد يحتاج وحدة أصلية على أي حالوصول مباشر، ولا جسر برمجي يحتاج تصحيحاً حين يغيّر المصنّع سلوكه
العمل في الخلفية تحت قيود البطارية في Androidيعمل، لكن واجهات المصنّعين الصارمة تحتاج اختباراً في الحالتينأسهل في التحكم، وأسهل في التشخيص حين يوقف الجهاز العملية
الصيانة على المدى الطويلقاعدة شيفرة واحدة، مع إطار عمل له دورة ترقية خاصة بهقاعدتا شيفرة، لكن كلٌّ منهما على مسار منصتها الموثّق جيداً

كيف يسير الأمر

من أول حديث حتى الإطلاق.

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

  1. أسبوع واحد

    الاستكشاف

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

  2. 4-8 أسابيع

    البناء الأساسي

    التخزين المحلي وطابور المزامنة والمسار الرئيسي للعمل أولاً، مختبرة على اتصال بطيء لا على شبكة المكتب.

  3. 2-3 أسابيع

    تجربة ميدانية

    مستخدمون حقيقيون على هواتفهم — بما فيها الرخيصة — بينما تستمر العملية الورقية. هنا تُصحَّح الافتراضات حول العمل دون اتصال.

  4. 1-2 أسبوع

    الإصدار

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

بعد الإطلاق

ما الذي يتغير.

  • يواصل موظفو الميدان استخدامه بعد الشهر الثاني، وهذا هو المقياس الحقيقي الوحيد لتطبيق ميداني.
  • تتحول عبارة 'لم يُحفظ' إلى سؤال له إجابة، لأن حالة المزامنة ظاهرة للمستخدم وللدعم.
  • هاتف ظل دون اتصال ثلاثة أيام يطابق بياناته دون أن يفقد أحد عمله.
  • يواصل إصدار قديم في الميدان العمل، لأن واجهة البرمجة مرقّمة الإصدار لا مفترضة حديثة.

وُصفت نوعياً عن قصد. نحن لا ننشر نسب تحسّن لا نستطيع نسبتها إلى عميل بعينه وبموافقته.

أسئلة

أسئلة شائعة.

أصلي أم متعدد المنصات — أيهما نختار؟

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

هل سيعمل دون إنترنت؟

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

هل تنشرون التطبيق في المتاجر نيابةً عنا؟

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

هل يمكن أن يعمل إلى جانب نظامنا الحالي؟

نعم. معظم تطبيقات الجوال التي نبنيها واجهة ميدانية فوق نظام قائم بالفعل، لا منتج منفصل ببياناته الخاصة.

هل يمكنكم تسلّم تطبيق بناه شخص آخر؟

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

هل نحتاج إلى تطبيق أصلاً، أم يكفي موقع للجوال؟

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