คำถามที่พบบ่อยเกี่ยวกับข้อความ Push

เหตุใดข้อความ Push จึงไม่ทำงานเมื่อปิดเบราว์เซอร์

คำถามนี้เกิดขึ้นบ่อยครั้ง ส่วนใหญ่เป็นเพราะมีสถานการณ์บางอย่างที่ทำให้ยากต่อการให้เหตุผลและทำความเข้าใจ

มาเริ่มกันที่ Android ก่อน ระบบปฏิบัติการ Android ออกแบบมาเพื่อคอยฟังข้อความ Push และเมื่อได้รับข้อความ ระบบจะปลุกแอป Android ที่เหมาะสมให้จัดการข้อความ Push ไม่ว่าแอปจะปิดอยู่หรือไม่ก็ตาม

ซึ่งเหมือนกับเบราว์เซอร์ใดๆ ใน Android เบราว์เซอร์จะถูกปลุกเมื่อได้รับข้อความ Push และเบราว์เซอร์จะปลุก Service Worker และส่งเหตุการณ์ Push

ในระบบปฏิบัติการเดสก์ท็อปจะมีรายละเอียดปลีกย่อยมากกว่า และอธิบายได้ง่ายที่สุดใน Mac OS X เนื่องจากมีตัวบ่งชี้ภาพเพื่อช่วยอธิบายสถานการณ์ต่างๆ

ใน Mac OS X คุณจะทราบได้ว่าโปรแกรมทำงานอยู่หรือไม่จากเครื่องหมายใต้ไอคอนแอปใน Dock

หากคุณเปรียบเทียบไอคอน Chrome 2 ไอคอนใน Dock ต่อไปนี้ ไอคอนทางด้านซ้ายกำลังทำงานอยู่ ดังที่แสดงโดยเครื่องหมายใต้ไอคอน ส่วน Chrome ทางด้านขวาไม่ได้ทำงานอยู่ จึงไม่มีเครื่องหมายอยู่ด้านล่าง

ตัวอย่างของ OS X

ในบริบทของการรับข้อความ Push บนเดสก์ท็อป คุณจะได้รับข้อความเมื่อเบราว์เซอร์ทำงานอยู่ กล่าวคือ มีเครื่องหมายใต้ไอคอน

ซึ่งหมายความว่าเบราว์เซอร์อาจไม่มีหน้าต่างเปิดอยู่ และคุณจะยังคงได้รับข้อความพุชใน Service Worker เนื่องจากเบราว์เซอร์ทำงานอยู่เบื้องหลัง

ครั้งเดียวที่ระบบจะไม่ได้รับข้อความ Push คือเมื่อเบราว์เซอร์ปิดสนิท กล่าวคือ ไม่ทำงานเลย (ไม่มีเครื่องหมาย) เช่นเดียวกับ Windows แม้ว่าจะตรวจสอบได้ยากกว่าเล็กน้อยว่า Chrome ทำงานอยู่เบื้องหลังหรือไม่

ฉันจะทำให้เว็บแอปในหน้าจอหลักเปิดแบบเต็มหน้าจอจากข้อความ Push ได้อย่างไร

ใน Chrome สำหรับ Android คุณสามารถเพิ่มเว็บแอปลงในหน้าจอหลักได้ และเมื่อเปิดเว็บแอปจากหน้าจอหลัก เว็บแอปจะเปิดในโหมดเต็มหน้าจอโดยไม่มีแถบ URL ดังที่แสดงด้านล่าง

ไอคอนหน้าจอหลักเป็นแบบเต็มหน้าจอ

นักพัฒนาแอปต้องการให้การแจ้งเตือนที่คลิกเปิดเว็บแอปแบบเต็มหน้าจอด้วย เพื่อให้ประสบการณ์การใช้งานนี้สอดคล้องกัน

Chrome "ค่อนข้าง" นำฟีเจอร์นี้ไปใช้ แม้ว่าคุณอาจพบว่าฟีเจอร์นี้ไม่น่าเชื่อถือและเข้าใจยาก รายละเอียดการใช้งานที่เกี่ยวข้องมีดังนี้

ซึ่งหมายความว่าหากผู้ใช้ไม่ได้เข้าชมเว็บไซต์ผ่านไอคอนหน้าจอหลักเป็นประจำ การแจ้งเตือนจะเปิดขึ้นใน UI ของเบราว์เซอร์ปกติ

เราจะดำเนินการแก้ไขปัญหานี้ต่อไป

เหตุใดวิธีนี้จึงดีกว่า WebSockets

Service Worker จะทำงานได้เมื่อปิดหน้าต่างเบราว์เซอร์ WebSockets จะทำงานตราบเท่าที่เบราว์เซอร์และหน้าเว็บยังเปิดอยู่เท่านั้น

GCM, FCM, Web Push และ Chrome มีความเกี่ยวข้องกันอย่างไร

คำถามนี้มีหลายแง่มุม และวิธีที่ง่ายที่สุดในการอธิบายคือการย้อนดูประวัติของ Web Push และ Chrome (ไม่ต้องกังวล แบบสำรวจนี้สั้นมาก)

ธันวาคม 2014

เมื่อ Chrome เริ่มใช้ข้อความพุชบนเว็บเป็นครั้งแรก Chrome ได้ใช้ Google Cloud Messaging (GCM) เพื่อขับเคลื่อนการส่งข้อความพุชจากเซิร์ฟเวอร์ไปยังเบราว์เซอร์

นี่ไม่ใช่ข้อความ Push บนเว็บ มีสาเหตุบางประการที่ทำให้การตั้งค่า Chrome และ GCM ในช่วงแรกนี้ไม่ใช่ Web Push "จริง"

  • GCM กำหนดให้นักพัฒนาแอปต้องตั้งค่าบัญชีใน Google Developers Console
  • Chrome และ GCM ต้องใช้รหัสผู้ส่งพิเศษที่เว็บแอปแชร์เพื่อตั้งค่าการรับส่งข้อความอย่างถูกต้อง
  • เซิร์ฟเวอร์ของ GCM ยอมรับคำขอ API ที่กำหนดเองซึ่งไม่ใช่มาตรฐานเว็บ

กรกฎาคม 2016

ในเดือนกรกฎาคม ฟีเจอร์ใหม่ใน Web Push ได้เปิดตัวขึ้น ซึ่งก็คือคีย์เซิร์ฟเวอร์แอปพลิเคชัน (หรือ VAPID ตามที่ทราบกันในข้อกำหนดเฉพาะ) เมื่อ Chrome เพิ่มการรองรับ API ใหม่นี้ Chrome ได้ใช้ Firebase Cloud Messaging (หรือที่เรียกว่า FCM) แทน GCM เป็นบริการรับส่งข้อความ ซึ่งสำคัญด้วยเหตุผลต่อไปนี้

  • คีย์ Chrome และคีย์เซิร์ฟเวอร์แอปพลิเคชันไม่จำเป็นต้องตั้งค่าโปรเจ็กต์ใดๆ กับ Google หรือ Firebase ซึ่งจะทำงานได้ทันที
  • FCM รองรับโปรโตคอลพุชบนเว็บ ซึ่งเป็น API ที่บริการพุชบนเว็บทั้งหมดรองรับ ซึ่งหมายความว่าไม่ว่าเบราว์เซอร์จะใช้บริการพุชใด คุณก็เพียงแค่ส่งคำขอประเภทเดียวกันและระบบจะส่งข้อความ

ทำไมวันนี้ถึงดูสับสน

ตอนนี้มีความสับสนอย่างมากเนื่องจากมีการเขียนเนื้อหาเกี่ยวกับหัวข้อพุชบนเว็บ ซึ่งส่วนใหญ่จะอ้างอิงถึง GCM หรือ FCM หากเนื้อหาอ้างอิงถึง GCM คุณควรถือว่าเนื้อหานั้นเป็นเนื้อหาเก่าหรือเน้นที่ Chrome มากเกินไป (ฉันเองก็เคยทำแบบนี้ในโพสต์เก่าๆ หลายโพสต์)

แต่ให้คิดว่า Web Push ประกอบด้วยเบราว์เซอร์ ซึ่งใช้บริการพุชเพื่อจัดการการส่งและรับข้อความ โดยบริการพุชจะยอมรับคำขอ "โปรโตคอล Web Push" หากคุณคิดในแง่นี้ คุณสามารถละเว้นเบราว์เซอร์และบริการพุชที่ใช้และเริ่มทำงานได้

คู่มือนี้เขียนขึ้นเพื่อมุ่งเน้นไปที่แนวทางมาตรฐานของข้อความ Push บนเว็บและละเว้นสิ่งอื่นๆ โดยเจตนา

Firebase มี JavaScript SDK What and why?

สำหรับผู้ที่พบ Firebase Web SDK และสังเกตเห็นว่ามี Messaging API สำหรับ JavaScript คุณอาจสงสัยว่า SDK นี้แตกต่างจาก Web Push อย่างไร

SDK การรับส่งข้อความ (หรือที่เรียกว่า Firebase Cloud Messaging JS SDK) มีกลเม็ดบางอย่างเบื้องหลังเพื่อช่วยให้ติดตั้งใช้งานข้อความ Push บนเว็บได้ง่ายขึ้น

  • คุณไม่ต้องกังวลเกี่ยวกับ PushSubscription และช่องต่างๆ ของออบเจ็กต์นี้ แต่ต้องกังวลเกี่ยวกับโทเค็น FCM (สตริง) เท่านั้น
  • เมื่อใช้โทเค็นสำหรับผู้ใช้แต่ละราย คุณจะใช้ FCM API ที่เป็นกรรมสิทธิ์เพื่อทริกเกอร์ข้อความ Push ได้ API นี้ไม่จำเป็นต้องเข้ารหัสเพย์โหลด คุณสามารถส่งเพย์โหลดข้อความธรรมดาในเนื้อหาคำขอ POST ได้
  • API ที่เป็นกรรมสิทธิ์ของ FCM รองรับฟีเจอร์ที่กำหนดเอง เช่น หัวข้อ FCM (ซึ่งทำงานบนเว็บด้วย แม้ว่าจะมีเอกสารประกอบไม่มากนัก)
  • สุดท้าย FCM รองรับ Android, iOS และเว็บ ดังนั้นสำหรับบางทีม การทำงานกับโปรเจ็กต์ที่มีอยู่จึงง่ายกว่า

ซึ่งจะใช้ข้อความ Push บนเว็บเบื้องหลัง แต่เป้าหมายคือการซ่อนรายละเอียดทางเทคนิคไว้

อย่างที่บอกไปในคำถามก่อนหน้านี้ หากคุณมองว่าข้อความ Push บนเว็บเป็นเพียงเบราว์เซอร์และบริการ Push คุณก็สามารถมองว่า SDK การรับส่งข้อความใน Firebase เป็นไลบรารีที่ช่วยให้การติดตั้งใช้งานข้อความ Push บนเว็บง่ายขึ้นได้

ขั้นตอนต่อไป

Code Labs