لماذا لا تصل بعض إشعارات تطبيقك إلى أحد

ما وجده مهندسونا

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

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

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

لماذا يحدث هذا لأعمال مثل عملك

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

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

ما غيّرناه

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

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

أين وصلنا الآن

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

ما يمكنك التحقق منه بنفسك

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

ما تفعله بعد ذلك

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