تطبيق الجوال

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

التحدي الحقيقي في تطبيقات الجوال

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

القرارات التي يتخذها مشروع الجوال

العناوين الستة أدناه تغطي القرارات الدائمة في مشروع الجوال: اثنان في التقنية والعقد، واثنان في قيود الجهاز نفسه، واثنان في التوزيع.

الاختيار بين التطوير متعدد المنصات والتطوير الأصلي

يُخرج Flutter وReact Native نسختي iOS وAndroid من قاعدة شيفرة واحدة، بينما يكتب Swift وKotlin كل منصة على حدة. ثلاثة معايير تحسم القرار: مقدار ما يلمسه التطبيق من إمكانات الجهاز (الكاميرا، تقنية Bluetooth، الموقع في الخلفية)، ومقدار الإحساس الخاص بالمنصة الذي تحتاجه الواجهة، ومن سيتولى الصيانة بعد التسليم. إعالة فريق واحد بدل فريقين تحسم الأمر غالبا في تطبيقات الأعمال. مشروع Welldone مثال على هذا الجانب: تطبيق الميدان كُتب بـ Flutter، ولوحة الإدارة بـ React، والخدمات بـ .NET وفق ما تذكره صفحة المشروع. ما احتاجه الميدان هو مسح رمز QR للتغليف بالقطعة وحالة الطلب لحظيا، لا تفاعلا خاصا بمنصة بعينها. واختيار تعدد المنصات لا يعني أن الشيفرة الأصلية لن تُلمس: الأذونات وتسجيل الإشعارات وسلوك الخلفية تُعالَج على كل منصة على حدة.

عقد الواجهة الخلفية وتوافق النسخ

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

العمل دون اتصال والمزامنة

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

الإشعارات والمهام في الخلفية

إشعار push ليس ميزة في التطبيق بل سلسلة: خادمك، ثم خدمتا الإشعارات لدى Apple وGoogle، ثم الجهاز، ثم نظام التشغيل الذي له الكلمة الأخيرة. ويمكن أن يسقط الإشعار عند أي حلقة: المستخدم قد يرفض الإذن، والنظام قد يؤخر التسليم توفيرا للبطارية، والجهاز قد يكون مغلقا. لذلك لا يُبنى أي مسار عمل على الإشعارات وحدها، وينبغي أن يرى المستخدم الذي فاته الإشعار المعلومة نفسها حين يفتح التطبيق. والمهام في الخلفية مقيدة أيضا: نظام التشغيل يوقظ تطبيقك حين يقرر هو، وميزة مبنية على مهمة خلفية يُفترض أنها تعمل بانتظام تنجح على جهاز الاختبار وتفشل في الميدان. مشروع Togodo مثال هنا: طُوّرت لتطبيق الفعاليات الاجتماعية مراسلة لحظية وإشعارات push فورية.

النشر في المتاجر وأسباب الرفض

متجرا App Store وGoogle Play عمليتان منفصلتان بقواعد ومهل مختلفة. وفي تقويم الإصدار يقف وقت المراجعة بندا مستقلا، لأنه خارج سيطرتك ولأن الإرسال الأول عادة هو الأبطأ. ويمكن إزالة أسباب الرفض الشائعة مسبقا: إقرار خصوصية ناقص أو غير مطابق للواقع، وغياب مسار لحذف الحساب، وعدم تزويد المراجع بحساب اختبار يعمل، وتسجيل دخول إلزامي بلا مبرر، وأذونات تُطلب دون نص توضيحي، ومواد ناقصة في صفحة المتجر. وكل سبب منها، إذا صُحّح بعد وقوعه، يكلّف دورة مراجعة كاملة، ولذلك تدخل جميعها في قائمة تدقيق سابقة للإرسال. وصفحة المتجر نفسها جزء من التسليم: العنوان والوصف والكلمات المفتاحية واللقطات. وخط البناء الآلي يختصر الدورة، وفي مشروع Welldone أُنجزت أتمتة CI/CD عبر Jenkins، وتفاصيل هذا الجانب تعود إلى قسم DevOps وCI/CD في خدماتنا.

التحديث الإجباري وتعذّر التراجع

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

لماذا تصبح النسخ القديمة مشكلة

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

نطاق الصيانة بعد الإصدار

الصيانة على الجوال لا تعني إصلاح الأخطاء فحسب. تطبيق الجوال يتوقف عن العمل مع الوقت حتى لو لم يلمس أحد شيفرته، لأن الأرض تحته تتغير عدة مرات في السنة. والتقويم يتكون من بنود ثابتة: تغيّرات السلوك في الإصدارات الكبرى السنوية لأنظمة التشغيل، وقواعد المتاجر بشأن هدف البناء وإقرارات الخصوصية، وشهادات التوقيع وملفات التزويد التي تنتهي صلاحيتها، وتحديثات المكتبات الخارجية. وحين تنتهي صلاحية الشهادة يستمر التطبيق في العمل لكنك لا تستطيع نشر نسخة جديدة، أي أنك تفقد القدرة على إصلاح الأخطاء. وإلى جانب ذلك تقف مراقبة مستمرة: تقارير الأعطال، وسجلات الشاشات التي لا تستجيب، وتعليقات المتجر. وتعليق المتجر ليس مؤشرا تسويقيا بل مصدرا لمعرفة الأخطاء. واستلام تطبيق عامل وتطويره جزء عادي من هذا العمل. ففي Togodo كان التطبيق القائم يعمل، لكن شاشات إدارة الفعاليات والمراسلة وملف المستخدم كانت ناقصة، فصُممت للمنصة القائمة شاشات جديدة وطُوّرت مراسلة لحظية ونُفّذت أعمال SEO وASO (تحسين الظهور داخل متاجر التطبيقات) على التطبيق.

كيف نختار الصيغة الصحيحة

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

الحسابات ومفاتيح التوقيع والتسليم

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

تطبيقان يعملان الآن

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

• مشروع Welldone: تطبيق ميداني بـ Flutter ولوحة إدارة بـ React وخدمات بـ .NET لعملية مغسلة صناعية. جُمعت الطلبات والشحن والترفيف والتغليف على منصة واحدة، ويمسح فريق الميدان رمز QR ليغلّف بالقطعة، وتتحدث حالة الطلب لحظيا، ويجري تواصل الفريق عبر المنصة نفسها. بُنيت البنية التحتية على .NET وMySQL، وأُنجزت أتمتة CI/CD عبر Jenkins أيضا. وتطبيق Welldone Helper متاح للتنزيل من متجري App Store وGoogle Play معا.
• مشروع Togodo: جرى تطوير تطبيق فعاليات اجتماعية عامل. صُممت شاشات جديدة لقائمة الفعاليات وملفات المستخدمين وإدارة المجتمع، وصار المستخدمون ينشئون الفعاليات وينضمون إليها ويدعون أصدقاءهم. طُوّرت مراسلة لحظية وإشعارات push، ونُفّذت أعمال SEO وASO، وصحّحت تحسينات الأداء السلوك تحت حركة مرور عالية. الجانب المحمول بـ Flutter وجانب الخادم بـ .NET وفق صفحة المشروع.