البرمجيات والمنصّات
المجالُ كاملًا، وبقيّةُ القدرات ضمنه.
تطبيقات الهاتف المحمول
تطبيقاتُ iOS وAndroid يُصمَّم فيها السلوكُ دون اتصال والمزامنةُ وعمليةُ الإصدار قبل الشاشة الأولى.
ما هذه الخدمة
تطبيقُ الهاتف المحمول ثلاثةُ أشياء في آنٍ واحد: العميلُ على الجهاز، والخدمةُ الخلفية التي تخدمه، وعمليةُ الإصدار التي توصلهما إلى أيدي المستخدمين. نبني تطبيقاتٍ أصيلةً وعابرةً للمنصّات على iOS وAndroid، مع طبقة الخدمة الخلفية المخصّصة للواجهة (Backend for Frontend) التي تعتمد عليها، وتدفّقاتِ الهوية التي تستوثق عبرها، وخطِّ البناء والتوقيع والإصدار والمراقبة.
النمطُ الأكثر تكرارًا في الإخفاق هو معاملةُ العمل دون اتصال بوصفه ميزةَ تخزينٍ مؤقّت. التخزينُ المؤقّت يجعل القراءةَ ممكنةً بلا شبكة، لكنّه لا يعالج جهازين يعدّلان السجلَّ نفسه وكلاهما دون اتصال. ومن دون قاعدةٍ لحلّ التعارض مقرَّرة سلفًا، يُسقِط التطبيقُ تعديلاتِ أحد المستخدمين بصمت، فتظهر المشكلةُ بعد أشهرٍ بيانًا لا يستطيع أحدٌ تفسيره.
متى تحتاجها
إن صدق أكثرُ من واحدةٍ ممّا يلي، فهذه عادةً نقطةُ البداية الصحيحة.
- يفقد العاملون الميدانيون عملَهم حين يخرجون من التغطية، ولا يمنحهم التطبيقُ وسيلةً لمعرفة هل حُفظ آخرُ تغييرٍ أجروه.
- يستغرق الإصدارُ أيامًا من الخطوات اليدوية وقلقِ مراجعة المتجر، فتنتظر الإصلاحاتُ الدفعةَ التالية بدل أن تخرج.
- تصلكم تقاريرُ الأعطال من المستخدمين لا من أدوات القياس، ولا تستطيعون إعادةَ إنتاجها على جهازٍ تملكونه.
- يستدعي عميلُ الهاتف الـ APIs نفسها التي يستدعيها تطبيقُ الويب، فيدفع الثمنَ ذهابًا وإيابًا وفي حجم الحمولة وفي البطارية.
ما الذي يشمله النطاق
- اختيارُ المنصّة — Swift وKotlin أصيلين أو قاعدةُ كودٍ مشتركة — مبنيًّا على حزمة ميزاتكم وفريقكم وإيقاعِ إصداركم لا على خيارٍ افتراضي.
- تصميمُ العمل دون اتصال والمزامنة: ما المتاح دون اتصال، وكيف تصطفّ التغييرات، والقاعدةُ الصريحة التي تحسم التعارض.
- طبقةُ خدمةٍ خلفية مخصّصة للواجهة، مصمَّمة لعدد الرحلات وحجمِ الحمولة والبطارية، بدل إعادة استخدام واجهة الويب كما هي.
- الهويةُ والجلسةُ وثقةُ الجهاز، بما فيها الفتحُ الحيوي (Biometric) وتجديدُ الرموز وتسجيلُ الخروج عن بُعد لجهازٍ مفقود.
- خطُّ البناء والتوقيع والإصدار إلى المتاجر والطرحُ المرحلي، مع ربط تقارير الأعطال والأداء قبل الإطلاق.
ما الذي تستلمه
| المُخرَج | ما يحتويه |
|---|---|
| نسخُ التطبيق الموقَّعة | نسخُ iOS وAndroid مبنيّةً وموقَّعةً عبر حسابات المطوّرين الخاصة بكم، مع مساراتِ اختبارٍ داخلية مهيّأة لمراجِعيكم. |
| مواصفةُ المزامنة والتعارض | مواصفةٌ مكتوبة لنطاق العمل دون اتصال وسلوكِ الاصطفاف وحلِّ التعارض، تفصل الحالات التي تُحسم آليًّا عن الحالات التي تُعرض على المستخدم. |
| الخدمةُ الخلفية للواجهة | طبقةُ الـ API الموجّهة للهاتف وعقدُها واختباراتُها، منشورةً في بيئاتكم إلى جانب التطبيق لا مُضافةً لاحقًا. |
| خطُّ الإصدار | بناءٌ وتوقيعٌ وتقديمٌ إلى المتاجر وطرحٌ مرحلي آلي، مع تقارير الأعطال ورفعِ ملفات الرموز ومسارٍ موثَّق للعودة إلى النسخة السابقة. |
مخطّطٌ معماريٌّ مرجعيّ
مرجعٌ لا قالب. بيئتُك هي التي تقرّر أيَّ أجزائه ينطبق، وبأيّ ترتيبٍ يصل.
كيف يُقاس النجاح
تُتَّفق المستهدفاتُ معك قبل بدء العمل، ويُرفَع التقريرُ عليها طوال مدّته.
- الجلساتُ والمستخدمون الخالون من الأعطال في كلّ إصدار، مقروءةً من نظام تقارير الأعطال لديكم لا من ملخّصات المتاجر وحدها.
- زمنُ البدء البارد وزمنُ الجاهزية للتفاعل على الأجهزة متوسطة الفئة التي يحملها مستخدموكم فعلًا، مأخوذةً بالعيّنة في كلّ إصدار.
- عمقُ طابور المزامنة، وعددُ محاولات الإعادة، ومرّاتُ حدوث التعارض، ليكون السلوكُ دون اتصال ملاحَظًا لا مفترَضًا.
أسئلةٌ تُطرح علينا
أصيلٌ أم عابرٌ للمنصّات؟
يتوقّف الأمر على مقدار قيمتكم القائم على قدراتٍ خاصة بالمنصّة. العملُ المكثّف على الكاميرا أو الموقع في الخلفية أو Bluetooth أو الودجات يرجّح Swift وKotlin أصيلين. أمّا التطبيقاتُ القائمة على النماذج والمحتوى وسير العمل فتخدمها غالبًا قاعدةُ كودٍ مشتركة تُنصّف المساحةَ التي تصونونها. نقدّم الحجّة مكتوبةً أمام قائمة ميزاتكم، ولا ندّعي أنّ جوابًا واحدًا يناسب كلّ تطبيق.
كيف تعالجون تعارضات العمل دون اتصال؟
بحسم القاعدة قبل كتابة كود المزامنة. الخياراتُ الشائعة هي رجحانُ آخر كتابةٍ على مستوى الحقل، أو دمجٌ يحسمه الخادم، أو حسمٌ صريح من المستخدم للسجلّات التي قد يكون أيُّ الطرفين محقًّا فيها. لكلّ خيارٍ تبعاتٌ يجب أن يقبلها أصحابُ العمل لديكم، فهو قرارُ منتجٍ يُوثَّق في المواصفة لا تفصيلُ تنفيذٍ نحسمه بصمت.
هل يمكن النشرُ تحت حسابات المطوّرين لدينا؟
نعم، بل نفضّله. تعيش التطبيقاتُ في حسابَي Apple وGoogle الخاصين بكم وبهوية توقيعكم منذ البداية، فلا تتعلّق الملكيةُ ولا الشهاداتُ ولا العلاقةُ بالمتجر بنا. نعمل بوصفنا أعضاءً في فرقكم بمستوى الوصول الذي تمنحونه.
كم تستغرق مراجعةُ المتجر؟
مدّةُ المراجعة تحدّدها Apple وGoogle ولا نستطيع الوعدَ برقم. ما نستطيع تقليصه هو أسبابُ الرفض التي تسيطرون عليها: إقراراتُ الخصوصية، ونصوصُ تبرير الأذونات، ومسارُ حذف الحساب، ومتطلّباتُ تسجيل الدخول. نجهّز هذه قبل التقديم الأول لا بعد الرفض الأول.
هل نحتاج خدمةً خلفية منفصلة للتطبيق؟
ليس دائمًا نظامًا منفصلًا، لكن غالبًا طبقةً منفصلة. عميلُ الهاتف على شبكةٍ بطيئة يستفيد من نقاط نهايةٍ مصمَّمة على شكل شاشاته لا على شكل نموذجكم للمجال. وطبقةُ الخدمة الخلفية للواجهة تجلس فوق خدماتكم القائمة وتؤدّي هذا التشكيل دون استنساخ منطق العمل في تنفيذٍ ثانٍ.
كيف تتعاملون مع أمن تطبيقات الهاتف؟
نبني وفق معيار OWASP للتحقّق من أمن تطبيقات الهاتف (MASVS) بوصفه قائمةَ عملٍ: التعاملُ مع الشهادات، والتخزينُ الآمن للرموز والمفاتيح، والتعميةُ حيث تستحقّ كلفتها، وسياسةُ الأجهزة المكسورة الحماية متّفقٌ عليها معكم. وإن أردتم اختبارَ اختراقٍ مستقلًّا فسندعمه ونصلح ما يكشفه؛ ولا نراجع عملنا بأنفسنا ونسمّي ذلك ضمانًا.
اقرأ أيضًا
برمجيات المؤسسات
أنظمةٌ مؤسسية مخصّصة مصمَّمة حول نموذج البيانات وسطحِ التكامل، مع صلاحياتٍ قائمة على الأدوار، ومسارِ تدقيقٍ، وترحيلِ بياناتٍ مطابَق ومُوثَّق.
واجهات البرمجة والتكامل
هندسةُ الـ API والتكامل: تصميمٌ يبدأ بالعقد، وإعدادُ البوّابة ووسيط الرسائل، والعمليةُ المتكرّرة الآمنة وإعادةُ المحاولة، والتتبّعُ وتحليلاتُ الاستهلاك.
ابدأ بتقييم
أسرعُ طريقٍ إلى جوابٍ مفيد نظرةٌ قصيرةٌ محدَّدةُ النطاق على ما لديكم أصلًا.