لماذا لا تعمل ميزة "الدفع" عندما يكون المتصفّح مغلقًا؟
يظهر هذا السؤال كثيرًا، ويرجع ذلك إلى حد كبير إلى أنّ هناك بعض السيناريوهات التي تصعِّب فهمه والتعامل معه.
لنبدأ بأجهزة Android. تم تصميم نظام التشغيل Android للاستماع إلى رسائل الإشعارات الفورية وعند تلقّي واحدة منها، يتم تنشيط تطبيق Android المناسب لمعالجة رسالة الإشعار الفوري، بغض النظر عمّا إذا كان التطبيق مغلقًا أم لا.
وينطبق ذلك بالضبط على أي متصفّح على Android، حيث سيتم تنشيط المتصفّح عند تلقّي رسالة دفع، وسيفعّل المتصفّح بدوره العامل في الخدمة ويرسِل حدث الدفع.
في أنظمة التشغيل المخصّصة لأجهزة الكمبيوتر المكتبي، تكون العملية أكثر دقة، ومن الأسهل شرحها على نظام التشغيل Mac OS X لأنّ هناك مؤشرًا مرئيًا للمساعدة في شرح السيناريوهات المختلفة.
في نظام التشغيل Mac OS X، يمكنك معرفة ما إذا كان البرنامج قيد التشغيل أم لا من خلال علامة أسفل رمز التطبيق في شريط التطبيقات.
إذا قارنت بين رمزَي Chrome في شريط الإرساء التالي، ستلاحظ أنّ الرمز على اليمين غير مفعّل، وبالتالي لا يظهر له علامة تحته، في حين أنّ الرمز على اليسار مفعّل، كما هو موضّح في العلامة تحته.

في سياق تلقّي الرسائل الفورية على الكمبيوتر المكتبي، ستتلقّى الرسائل عندما يكون المتصفّح قيد التشغيل، أي عندما يظهر العلامة تحت الرمز.
وهذا يعني أنّه يمكن أن يكون المتصفح غير مفتوح، وسيظل بإمكانك تلقّي رسالة الإشعار الفوري في خدمة Worker، لأنّ المتصفح يعمل في الخلفية.
لن يتم تلقّي إشعار فوري إلا عندما يكون المتصفّح مغلقًا تمامًا، أي عندما لا يكون قيد التشغيل إطلاقًا (بدون وضع علامة). وينطبق الأمر نفسه على نظام التشغيل Windows، إلا أنّه من الصعب تحديد ما إذا كان متصفّح Chrome قيد التشغيل في الخلفية أم لا.
كيف يمكنني جعل تطبيق الويب على الشاشة الرئيسية يفتح بملء الشاشة من خلال الضغط عليه؟
في Chrome لأجهزة Android، يمكن إضافة تطبيق ويب إلى الشاشة الرئيسية، وعند فتح تطبيق الويب من الشاشة الرئيسية، يمكن تشغيله في وضع ملء الشاشة بدون شريط عنوان URL، كما هو موضّح أدناه.

للحفاظ على اتساق هذه التجربة، يريد المطوّرون أن تؤدي النقرة على الإشعارات إلى فتح تطبيق الويب في وضع ملء الشاشة أيضًا.
نفَّذ Chrome هذا الإجراء "نوعًا ما"، ولكن قد ترى أنّه غير موثوق ويصعب التعامل معه. في ما يلي تفاصيل التنفيذ ذات الصلة:
وهذا يعني أنّه ما لم يكن المستخدم يزور موقعك الإلكتروني من خلال رمز الشاشة الرئيسية بانتظام إلى حدٍ ما، سيتم فتح إشعاراتك في واجهة مستخدم المتصفّح العادية.
سيتم العمل على حلّ هذه المشكلة.
ما الذي يجعل هذا الخيار أفضل من مآخذ الويب؟
يمكن تنشيط مشغّل خدمة عند إغلاق نافذة المتصفّح. لن يبقى مقبس الويب نشطًا إلا ما دام المتصفّح و صفحة الويب مفتوحَين.
ما هي الصفقة المتعلقة بـ GCM وFCM وWeb Push وChrome؟
يتضمّن هذا السؤال عددًا من الجوانب، وأفضل طريقة لشرحه هي الاطّلاع على سجلّ إشعارات الدفع على الويب وChrome. (لا داعي للقلق، الرسالة قصيرة).
كانون الأول (ديسمبر) 2014
عندما نفَّذ Chrome رسائل Web Push لأول مرة، استخدم Chrome خدمة Google Cloud Messaging (GCM) لتعزيز إرسال الرسائل الفورية من الخادم إلى المتصفّح.
لم يكن هذا إشعارًا عبر الويب. هناك بعض الأسباب التي أدّت إلى أنّ عملية الإعداد المبكّرة هذه لتطبيق Chrome وGoogle Cloud Messaging لم تكن "حقيقية" من خلال إرسال إشعارات فورية على الويب.
- تتطلّب خدمة GCM من المطوّرين إعداد حساب على Google Developers Console.
- كان Chrome وGMS بحاجة إلى معرّف مُرسِل خاص يشاركه تطبيق ويب ليتمكّن من إعداد الرسائل بشكل صحيح.
- قبلت خوادم GCM طلب واجهة برمجة تطبيقات مخصّصًا لم يكن معيارًا على الويب.
تموز (يوليو) 2016
في شهر تموز (يوليو)، تم طرح ميزة جديدة في إشعارات الدفع على الويب، وهي مفاتيح Application Server Keys (أو VAPID، كما يُعرف التنسيق). عندما أضاف Chrome واجهة برمجة التطبيقات هذه، استخدم Firebase Cloud Messaging (المعروفة أيضًا باسم FCM) بدلاً من GCM كخدمة مراسلة. وهذا أمر مهم لعدة أسباب:
- لا تحتاج مفاتيح Chrome وخادم التطبيقات إلى إعداد أي نوع من المشاريع باستخدام Google أو Firebase. سيعمل هذا الإجراء على ما يرام.
- تتوافق خدمة "إرسال إشعارات من خادم Google" مع بروتوكول إشعارات الويب، وهو واجهة برمجة التطبيقات التي ستتيح جميع خدمات إشعارات الويب. وهذا يعني أنّه بغض النظر عن خدمة الإشعارات الفورية التي يستخدمها المتصفّح، ما عليك سوى إرسال النوع نفسه من الطلبات وسيؤدي ذلك إلى إرسال الرسالة.
ما هو سبب الالتباس اليوم؟
هناك قدر كبير من الالتباس الآن بعد أن تم كتابة محتوى حول موضوع إعلامات الويب الدفع، ويشير الكثير منه إلى GCM أو FCM. إذا كان المحتوى يشير إلى GCM، من المحتمل أن يشير ذلك إلى أنّه محتوى قديم أو أنّه يركز كثيرًا على Chrome. (لقد سبق لي إجراء ذلك في عدد من المشاركات القديمة).
بدلاً من ذلك، يمكنك اعتبار رسائل Web Push على أنّها تتألف من متصفّح يستخدم خدمة دفع لإدارة إرسال الرسائل واستلامها، حيث ستقبل خدمة الدفع طلب "بروتوكول Web Push" . إذا كنت تفكر بهذه الطريقة، يمكنك تجاهل المتصفّح وخدمة الإشعارات الفورية التي يستخدمها والبدء في العمل.
تم تأليف هذا الدليل للتركيز على نهج المعايير في إرسال الإشعارات الفورية على الويب، ويغضّ النظر عن أي شيء آخر عن قصد.
تتوفّر حزمة تطوير برامج (SDK) لـ JavaScript في Firebase. ما هي هذه الميزة ولماذا؟
إذا كنت قد عثرت على حزمة تطوير البرامج (SDK) لتطبيقات الويب من Firebase ولاحظت أنّها تتضمّن واجهة برمجة تطبيقات للمراسلة لسمة JavaScript، قد تتساءل عن الفرق بينها وبين إشعارات الدفع على الويب.
تُنفِّذ حزمة تطوير البرامج (SDK) للمراسلة (المعروفة باسم حزمة تطوير البرامج (SDK) لـ "المراسلة عبر السحابة الإلكترونية من Firebase") بعض الحيل في الخلفية لتسهيل تنفيذ إشعارات الدفع على الويب.
- بدلاً من القلق بشأن
PushSubscription
وحقوله المختلفة، ما عليك سوى القلق بشأن رمز FCM (سلسلة). - باستخدام الرموز المميزة لكل مستخدم، يمكنك استخدام واجهة برمجة التطبيقات للمراسلة عبر السحابة الإلكترونية من Firebase المملوكة للشركة لبدء إرسال الرسائل الفورية. لا تتطلّب واجهة برمجة التطبيقات هذه تشفير الحمولات. يمكنك إرسال حمولة نصية عادية في نص طلب POST.
- تتيح واجهة برمجة التطبيقات المملوكة لخدمة "إشعارات Google من خادم Firebase" استخدام ميزات مخصّصة، مثل مواضيع "إشعارات Google من خادم Firebase" (تعمل هذه المواضيع على الويب أيضًا، إلا أنّها غير موثّقة بشكل جيد).
- أخيرًا، يتوافق إطار عمل إرسال الرسائل إلى الأجهزة الجوّالة (FCM) مع Android وiOS والويب، لذا يكون من السهل على بعض الفِرق استخدام هذا الإطار في المشاريع الحالية.
يستخدم هذا الإجراء إشعارات الويب من وراء الكواليس، ولكن هدفه هو إزالة هذه الإشعارات.
كما ذكرتُ في السؤال السابق، إذا كنت تعتقد أنّ إشعارات الويب هي مجرد متصفّح وخدمة إشعارات، يمكنك اعتبار حزمة تطوير البرامج (SDK) لميزة المراسلة في Firebase مكتبة لتبسيط تنفيذ إشعارات الويب.
الخطوات التالية
- نظرة عامة على الإشعارات الفورية على الويب
- آلية عمل الإشعارات الفورية
- اشتراك مستخدم
- تجربة المستخدم في ما يتعلّق بالأذونات
- إرسال الرسائل باستخدام مكتبات Web Push
- Web Push Protocol
- معالجة أحداث الإشعارات الفورية
- عرض إشعار
- سلوك الإشعار
- نماذج الإشعارات الشائعة
- الأسئلة الشائعة حول الإشعارات الفورية
- المشاكل الشائعة والإبلاغ عن الأخطاء