إطلاق التطبيقات في الجزائر

3

متعاملين نختبر عليهم وصول رمز التحقق، في الأسبوع الأول

5 د

مدة صلاحية رمز التحقق، تُفحص على الخادم، خمس محاولات

468

اختبارًا في منتج واحد، كثير منها للاتجاه والتباين

~78

ملفًا لمسناها لمغادرة Firebase، من تطبيق كامل

المال أولًا، ثم كل شيء آخر

لا وجود لـ Stripe هنا. البطاقات هي الذهبية وCIB، والتحويلات تمر عبر بريدي موب وCCP، ومعالجات الدفع العالمية لا تصل إلى هذه القنوات. منصّتنا لوظائف الطلبة تمرّر الدفع عبر Chargily Pay من دالة بلا خادم، مع webhook يكتب سطر الاشتراك، وما تزال خارطة طريقها تحمل بندًا مفتوحًا لم نحلّه بالكامل: الاشتراكات على قنوات دفع غير متكررة. الحل الذي يعمل هو التجديد كل فترة: الباقة شراء بتاريخ، وتذكير يدفعك لتكراره، والانقضاء حالة يتراجع إليها التطبيق، لا اقتطاعًا فاشلًا يغلق الباب.

في تطبيق طلب الطعام للمطاعم تجاوزنا الدفع كليًا. الطعام سلعة مادية، فالشراء داخل التطبيق عند Apple ممنوع، والتطبيق لا يحصّل شيئًا: الدفع عند الطاولة أو عند التوصيل. ملاحظات مراجع App Store تقول ذلك بوضوح، وتدقيق الجاهزية يتأكد أن لا واجهة شراء موجودة في أي مكان من الكود.

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

ثلاثة متعاملين، شريحة لكل واحد

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

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

أحيانًا الجواب الصحيح ليس الرسائل النصية أصلًا. الرسائل تكلف مالًا، لذا يستعمل منتج الروضات رموز دعوة تصدرها المديرة مع جلسة مرتبطة بالجهاز، والتسجيل الذاتي غير مدعوم عمدًا. قاعدة من ذلك الكود نطبقها الآن في كل مكان: المصادقة هي الشيء الوحيد الذي لا يمكن وضعه في طابور. التشغيل بلا شبكة ينتظر بدل أن يخرج أحدًا من حسابه؛ وحده 401 حقيقي يفعل ذلك.

من اليمين إلى اليسار منذ أول commit

تعديل تطبيق لاحقًا ليدعم اليمين-إلى-اليسار مؤلم، فتوقفنا عن التعديل اللاحق. القواعد التي يفرضها الآن إعداد المحلّل والاختبارات في مشاريعنا الأحدث:

• استعمل EdgeInsetsDirectional وAlignmentDirectional وstart / end. أبدًا left / right.
• اختبر كل شاشة باللغتين منذ الأسبوع الأول. منصة المعدات تُشحن مع 468 اختبارًا عبر نحو ثلاثين ملفًا، وحصة جيدة منها فحوص تدويل واتجاه وتباين.
• ضمّن الخطوط. Tajawal للعربية، مشحونة داخل التطبيق، لأن التطبيق يُستعمل حيث لا Wi-Fi، والخط الذي يُحمَّل عند التشغيل خط لا يُحمَّل أحيانًا.
• أبقِ العلامة هندسةً متجهية، لا حرفًا من خط، حتى تُرسم بالشكل نفسه في كل لغة.
• اكتب العربية ولا تترجمها. تعليقا commit في موقع Batipro يقولانها أفضل: «عربية بسيطة لا عربية أدبية» و«العربية تُرجمت ولم تُكتب».

“

عربية بسيطة لا عربية أدبية. العربية تُرجمت ولم تُكتب.

”

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

ما يراه المراجع

تدقيق الجاهزية لـ App Store الذي كتبناه لتطبيق المطعم مرتّب حسب أسباب الرفض التي يصطدم بها المطورون أكثر. تلك التي غيّرت إعداداتنا الافتراضية:

• لا نافذة طلب تتبّع إن كنت لا تتبّع. Apple ترفض التطبيقات التي تعرض الطلب دون استعمال المعرّف.
• أيقونة حقيقية بحجم 1024 في 1024. تصغير شعار نصي تلقائيًا إلى مربع سبب رفض شائع، وهو قبيح على أي حال.
• اقفل iPhone على الوضع العمودي ما لم تكن كل شاشة تتعامل فعلًا مع الأفقي. إعلان دعم لا تملكه سبب رفض.
• ارفع رقم البناء في كل رفع. إعادة رفع الرقم نفسه مرفوضة.
• حاجز عدم اتصال صارم يستبدل الشاشة كلها عدواني جدًا في نظر المراجعين، الذين يختبرون على شبكات ضعيفة ويحبون رؤية المحتوى المخزن يظهر. اعرض شريطًا بدلًا منه.
• اكتب ملاحظات المراجع مسبقًا. ملاحظاتنا تشرح لماذا يعمل «إرسال الطلب» بلا خطوة دفع، وأن طلبات الاختبار ستظهر في لوحتنا باسم المراجع وستُحذف.

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

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

الهجرة التي لم تكن تبديل إعدادات

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

الحكم الذي كتبناه من البداية: هذا تغيير منصة كبير. عدّ الاستعمالات في الكود جعله ملموسًا. نحو 55 معاملة، و60 كتابة مجمّعة، و59 استعلام مجموعة تجميعات، و209 عمليات على قيم الحقول لم يكن لها مقابل واحد لواحد، والمستندات بلا مخطط صارت خصائص محددة مسبقًا. الاشتراكات اللحظية ورمز التحقق بالهاتف والتخزين انتقلت بسلاسة.

شيئان جعلا الأمر قابلًا للنجاة. البنية النظيفة حصرت العمل في طبقة البيانات، نحو 78 ملف Dart، وفي 18 دالة سحابية، بدل إعادة كتابة كاملة. ونحو 398 اختبار وحدة إضافة إلى اختبارات تكامل ضد نسخة Appwrite حقيقية جرت قبل أن يثق أحد بالانتقال. ومع ذلك كشفت أخطاء حقيقية: استعلامات تستعمل أسماء حقول Firebase قديمة لم تعد موجودة، وتدقيق مخطط وجد عشر خصائص ناقصة في المشروع الحي، وحفنة من مؤشرات التحميل العالقة.

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

إن كنت تطلق هنا

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