الأسئلة الشائعة حول الإشعارات الفورية

يظهر هذا السؤال بشكل بارز إلى حد كبير، ويرجع ذلك إلى وجود عدد قليل من السيناريوهات التي تجعل من الصعب فهمه وفهمه.

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

وهذا ما يحدث تمامًا مع أي متصفح على Android، حيث سيتم تنشيط المتصفح عند استلام رسالة فورية، وحينئذٍ ينشّط المتصفح عامل الخدمة ويرسل حدث الدفع.

في نظام التشغيل Mac OS X، يكون الأمر أكثر دقة ويسهل شرحه على نظام التشغيل Mac OS X لأن هناك مؤشرًا مرئيًا للمساعدة في شرح السيناريوهات المختلفة.

في نظام التشغيل Mac OS X، يمكنك معرفة ما إذا كان البرنامج قيد التشغيل أم لا عن طريق وضع علامة أسفل أيقونة التطبيق في شريط الإرساء.

إذا قارنت رمزَي Chrome في شريط الإرساء التالي، يعني ذلك أنّ الرمز الموجود على اليسار يعمل، كما هو موضّح في العلامة الموجودة أسفل الرمز، في حين أنّ Chrome على اليمين لا يعمل، وبالتالي لا يتم وضع العلامة الموجودة أسفلها.

مثال على نظام التشغيل OS X

في سياق استلام رسائل الدفع على سطح المكتب، ستتلقى رسائل عندما يكون المتصفح قيد التشغيل، أي أنه يحتوي على علامة أسفل الرمز.

ويعني هذا أنّه لا يمكن أن تكون هناك نوافذ مفتوحة للمتصفّح، وأنّه سيظل بإمكانك تلقّي رسائل فورية في مشغّل الخدمات، لأنّ المتصفّح قيد التشغيل في الخلفية.

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

كيف أجعل تطبيق الويب للشاشة الرئيسية يفتح بملء الشاشة من الدفع؟

في Chrome لنظام Android، يمكن إضافة تطبيق ويب إلى الشاشة الرئيسية وعند فتح تطبيق الويب من الشاشة الرئيسية، يمكن تشغيله في وضع ملء الشاشة بدون شريط عناوين URL، كما هو موضح أدناه.

رمز الشاشة الرئيسية إلى وضع ملء الشاشة

وللحفاظ على اتساق هذه التجربة، يريد المطوِّرون فتح تطبيق الويب في وضع ملء الشاشة أيضًا على الإشعارات التي تم النقر عليها.

نفّذ Chrome هذا "كنوع من أنواع"، على الرغم من أنّك قد تجده غير موثوق به ومن الصعب السبب وراءه. في ما يلي تفاصيل التنفيذ ذات الصلة:

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

وسيتم العمل على هذه المشكلة بشكل أكبر.

لماذا يعد ذلك أفضل من مآخذ الويب؟

يمكن إحياء عامل الخدمة عند إغلاق نافذة المتصفح. يستمر مقبس الويب في العمل طالما ظل المتصفح وصفحة الويب مفتوحَين.

ما هي الصفقة مع GCM وFCM وWeb Push وChrome؟

يحتوي هذا السؤال على عدد من الواجهات، وأسهل طريقة لشرحه هي استعراض تاريخ الدفع على الويب وChrome. (لا داعي للقلق، فهو قصير.)

كانون الأول (ديسمبر) 2014

عندما نفّذ Chrome ميزة "إرسال الرسائل الفورية" على الويب للمرة الأولى، استخدم Chrome خدمة "المراسلة عبر السحابة الإلكترونية من Google" (GCM) لتعزيز عملية إرسال الرسائل الفورية من الخادم إلى المتصفّح.

لم يكن هذا الإجراء إرسالًا سريعًا على الويب. هناك عدة أسباب تجعل من هذا الإعداد المبكر لـ Chrome وGCM لم يكن دفعة "واقعية" على الويب.

  • تتطلب خدمة GCM من مطوّري البرامج إعداد حساب على Google Developers Console.
  • كان Chrome وGCM بحاجة إلى معرّف مُرسِل خاص لمشاركته من قِبل أحد تطبيقات الويب حتى يتمكن التطبيق من إعداد الرسائل بشكل صحيح.
  • قبلت خوادم GCM طلب واجهة برمجة تطبيقات مخصصًا لم يكن معيارًا للويب.

تموز (يوليو) 2016

في تموز (يوليو)، تم إطلاق ميزة جديدة في خدمة الدفع على الويب، وهي "مفاتيح خادم التطبيقات" (أو VAPID، حسب المواصفات المعروفة). عندما أتاح Chrome استخدام واجهة برمجة التطبيقات الجديدة هذه، استخدم "المراسلة عبر السحابة الإلكترونية من Firebase" (المعروفة أيضًا باسم "المراسلة عبر السحابة الإلكترونية من Firebase") بدلاً من خدمة GCM كخدمة مراسلة. هذا مهم لعدة أسباب:

  • لا يحتاج Chrome ومفاتيح خادم التطبيق إلى إعداد أي نوع من المشاريع مع Google أو Firebase. إنه سيعمل فقط.
  • تتوافق خدمة "المراسلة عبر السحابة الإلكترونية من Firebase" مع بروتوكول الإشعارات الفورية على الويب، وهو واجهة برمجة تطبيقات متوافقة مع جميع خدمات إرسال الرسائل على الويب. وهذا يعني أنه بغض النظر عن خدمة الدفع التي يستخدمها المتصفح، فإنك ترسل الطلب نفسه وسيرسل الرسالة.

لماذا يبدو الأمر محيرًا اليوم؟

هناك قدر كبير من الالتباس الآن بسبب كتابة المحتوى حول موضوع الإشعارات الفورية عبر الويب، ويشير الكثير منه إلى GCM أو FCM. إذا كان المحتوى يشير إلى GCM، من المحتمل أن تتعامل معه كعلامة على أنه إما محتوى قديم أو أنه يركز بشكل كبير على Chrome. (أنا مذنب للقيام بذلك في عدد من المشاركات القديمة).

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

تمت كتابة هذا الدليل للتركيز على النهج القياسي لدفع البيانات على الويب ويتجاهل عمدًا أي شيء آخر.

يتضمّن Firebase حزمة تطوير برامج (SDK) بلغة JavaScript. ماذا ولماذا؟

بالنسبة إلى المستخدمين الذين عثروا على حزمة تطوير البرامج (SDK) للويب لمنصة Firebase ولاحظوا أنّها تتضمّن واجهة برمجة تطبيقات للمراسلة باستخدام JavaScript، قد تتساءلون عن أوجه اختلافها عن ميزة الدفع على الويب.

تقوم حزمة SDK للمراسلة (المعروفة باسم Firebase Cloud Messaging JS SDK) ببعض الحِيل من وراء الكواليس لتسهيل تنفيذ الدفع على الويب.

  • فبدلاً من القلق بشأن PushSubscription وحقوله المختلفة، ما عليك سوى القلق بشأن الرمز المميّز للمراسلة عبر السحابة الإلكترونية من Firebase (سلسلة).
  • باستخدام الرموز المميزة لكل مستخدم، يمكنك استخدام واجهة برمجة التطبيقات FCM API لعرض رسائل الدفع. لا تتطلب واجهة برمجة التطبيقات هذه تشفير الحمولات. يمكنك إرسال حمولة نص عادي في نص طلب POST.
  • تتوافق واجهة برمجة التطبيقات التي تملكها ميزة "المراسلة عبر السحابة الإلكترونية من Firebase" مع ميزات مخصّصة، مثل مواضيع FCM (تعمل هذه الميزة على الويب أيضًا، ولكنها ليست موثَّقة بشكل دقيق).
  • وأخيرًا، يدعم "المراسلة عبر السحابة الإلكترونية من Firebase" أنظمة التشغيل Android وiOS والويب، لذلك يسهل بالنسبة إلى بعض الفِرق العمل في المشاريع الحالية.

يستخدم هذا الدفع على الويب وراء الكواليس، لكن هدفه هو تجريده بعيدًا.

وكما قلت في السؤال السابق، إذا كنت تعتبر إرسال الإشعارات على الويب مجرد متصفح وخدمة إرسال بيانات، يمكنك اعتبار حزمة SDK للمراسلة في Firebase كمكتبة لتبسيط تنفيذ إرسال الإشعارات على الويب.

الخطوات التالية

الدروس التطبيقية حول الترميز