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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Chrome "แบบ" นำวิธีนี้มาใช้ แม้ว่าคุณอาจจะเห็นว่าไม่น่าเชื่อถือ และยากต่อการให้เหตุผล รายละเอียดการติดตั้งใช้งานที่เกี่ยวข้องมีดังนี้

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

ปัญหานี้จะได้รับการดำเนินการเพิ่มเติม

เหตุใดวิธีนี้จึงดีกว่าเว็บซ็อกเก็ต

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

GCM, FCM, Web Push และ Chrome มีการจัดการอย่างไร

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

ธันวาคม 2014

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

ข้อมูลนี้ไม่ใช่ข้อความ Push จากเว็บ การตั้งค่า Chrome และ GCM ในช่วงแรกๆ นี้ไม่ใช่การพุชจากเว็บ "เกิดขึ้นจริง"

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

กรกฎาคม 2016

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

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

เหตุใดวันนี้จึงชวนสับสน

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

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

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

Firebase มี JavaScript SDK อะไรและเพราะเหตุใด

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

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

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

วิธีนี้ใช้การพุชเบื้องหลังจากเว็บ แต่เป้าหมายคือการนำส่วนนี้ออก

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

ขั้นตอนถัดไป

ห้องทดลองการเขียนโค้ด