שאלות נפוצות בנושא התראות

למה לא מתבצעת בדחיפה של עבודה כשהדפדפן סגור?

השאלה הזו מופיעה לא מעט, בעיקר כי יש מספר תרחישים שמקשים על ההיגיון וההבנה.

נתחיל עם Android. מערכת ההפעלה Android נועדה להאזין להודעות דחיפה, וכשתקבלו אותה, אפליקציית Android המתאימה תטפל בהודעה, גם אם האפליקציה סגורה וגם אם לא.

זה בדיוק אותו הדבר בכל דפדפן ב-Android: הדפדפן יצא ממצב שינה כשמתקבלת הודעת Push, ולאחר מכן הדפדפן יעיר את ה-service worker וישלח את אירוע ה-push.

במערכות הפעלה למחשב, היא מורכבת יותר וקל יותר להסביר אותה ב-Mac OS X, כי יש אינדיקטור חזותי שעוזר להסביר את התרחישים השונים.

ב-Mac OS X אפשר לדעת אם תוכנה פועלת או לא לפי סימון מתחת לסמל האפליקציה ב-Dock.

אם משווים בין שני הסמלים של Chrome באביזר העגינה הבא, הסמל שבצד שמאל פועל כפי שמוצג בסימון מתחת לסמל, בעוד ש-Chrome שמשמאל לא פועל, ולכן היעדר הסימון מתחתיו.

דוגמה של OS X

בהקשר של קבלת הודעות Push במחשב, תקבלו הודעות כשהדפדפן פועל, כלומר מתחת לסמל.

כלומר, לא ניתן לפתוח חלונות בדפדפן, ועדיין תתקבל הודעת דחיפה בקובץ השירות (service worker) כי הדפדפן פועל ברקע.

הפעם היחידה שבה לא מתקבלת הודעת Push היא כשהדפדפן סגור לגמרי, כלומר לא פועל בכלל (ללא סימון). הדבר נכון גם ל-Windows, למרות שקצת יותר קשה לקבוע אם Chrome פועל ברקע או לא.

איך מגדירים שאפליקציית האינטרנט במסך הבית תיפתח במסך מלא מלחיצה?

ב-Chrome עבור Android, ניתן להוסיף אפליקציית אינטרנט למסך הבית, וכשאפליקציית האינטרנט נפתחת ממסך הבית, היא יכולה לפעול במצב מסך מלא ללא סרגל הכתובות, כפי שמוצג בהמשך.

סמל מסך הבית למצב מסך מלא

כדי לשמור על עקביות בחוויית השימוש, המפתחים רוצים שההתראות שהם ילחצו עליהן יפתחו גם את אפליקציית האינטרנט במסך מלא.

Chrome ביצע את ההטמעה הזו, למרות שיכול להיות שתגלו שהיא לא אמינה ושקשה להסביר אותה. פרטי ההטמעה הרלוונטיים הם:

המשמעות היא שאם המשתמש שלכם לא מבקר באתר דרך הסמל של מסך הבית באופן די קבוע, ההתראות ייפתחו בממשק המשתמש הרגיל של הדפדפן.

אנחנו נמשיך לטפל בבעיה הזו.

למה זה טוב יותר משקעי אינטרנט?

קובץ שירות (service worker) יכול להתעורר לחיים כשחלון הדפדפן סגור. שקע אינטרנט יפעל רק כל עוד הדפדפן ודף האינטרנט פתוחים.

מה קורה עם GCM, FCM, Web Push ו-Chrome?

לשאלה הזו יש כמה היבטים, והדרך הפשוטה ביותר להסביר אותה היא לעבור על ההיסטוריה של דחיפת האינטרנט ו-Chrome. (אל דאגה, הוא קצר).

דצמבר 2014

כש-Chrome הטמיע את דחיפת האינטרנט בפעם הראשונה, Chrome השתמש בהעברת הודעות בענן של Google (GCM) כדי לאפשר שליחה של הודעות דחיפה מהשרת לדפדפן.

זו לא דחיפה של אתר. יכולות להיות כמה סיבות לכך שההגדרה המוקדמת של Chrome ו-GCM לא הייתה דחיפה 'אמיתית' באינטרנט.

  • ב-GCM נדרש ממפתחים להגדיר חשבון ב-Google Developers Console.
  • Chrome ו-GCM היו זקוקים למזהה שולח מיוחד כדי שאפליקציית אינטרנט תוכל להגדיר את העברת ההודעות בצורה נכונה.
  • שרתי GCM קיבלו בקשת API מותאמת אישית שאינה תקן אינטרנט.

יולי 2016

ביולי יצאה תכונה חדשה ב-WebPush – מפתחות שרת אפליקציות (או VAPID, כידוע המפרט). כשהוספנו ל-Chrome תמיכה ב-API החדש, הוא השתמש ב-Firebase Cloud Messaging (שנקרא גם FCM) במקום ב-GCM בתור שירות העברת הודעות. זה חשוב מכמה סיבות:

  • כדי להגדיר פרויקט ב-Google או ב-Firebase אין צורך להגדיר פרויקטים ב-Chrome וב-Application Sver. זה פשוט יעבוד.
  • ב-FCM יש תמיכה בפרוטוקול Web Push Protocol – ה-API שתומך בכל שירותי ה-Web Push. כלומר, לא משנה באיזה שירות דחיפה משתמש הדפדפן, כל מה שאתם צריכים לעשות הוא לשלוח את אותו סוג בקשה והוא ישלח את ההודעה.

למה זה מבלבל היום?

כיום יש הרבה בלבול כי התוכן נכתב בנושא 'דחיפה באינטרנט', ורובם מתייחסים ל-GCM או ל-FCM. אם התוכן מתייחס ל-GCM, כדאי להתייחס אליו כאל סימן לכך שמדובר בתוכן ישן או שהוא מתמקד יותר מדי ב-Chrome. (אני אשם בכך שעשיתי זאת בכמה פוסטים ישנים).

במקום זאת, אפשר לחשוב על דחיפת אינטרנט כעל דפדפן שמשתמש בשירות דחיפה כדי לנהל את השליחה והקבלה של הודעות, שבו שירות ה-Push יקבל בקשה של "פרוטוקול דחיפה באינטרנט". אם תחשבו על המונחים האלה, תוכלו להתעלם מבאיזה דפדפן ובאיזה שירות דחיפה הוא משתמש ולהתחיל לעבוד.

המדריך הזה נכתב כהתמקדות בגישה לתקנים של דחיפת אתרים, ומתעלמים בכוונה מכל דבר אחר.

ל-Firebase יש JavaScript SDK. מה ולמה?

אם אלה מכם שמצאו את ה-SDK לאינטרנט של Firebase ושימו לב שיש בו API להעברת הודעות עבור JavaScript, תוכלו להבין מה ההבדל בין ה-SDK שלו לאינטרנט.

ערכת ה-SDK להעברת הודעות (שנקראת Firebase Cloud Messaging JS SDK) מבצעת כמה טריקים מאחורי הקלעים כדי להקל על ההטמעה של ה-Webpush.

  • במקום לדאוג לגבי PushSubscription והשדות השונים שלו, צריך רק לטפל באסימון FCM (מחרוזת).
  • באמצעות האסימונים לכל משתמש, אפשר להשתמש ב-FCM API הקנייני כדי להפעיל דחיפת הודעות. ה-API הזה לא מחייב הצפנת מטענים ייעודיים. אפשר לשלוח מטען ייעודי (payload) של טקסט פשוט בגוף בקשת POST.
  • ה-API הקנייני של FCM תומך בתכונות מותאמות אישית, כמו FCM Topics (הוא פועל גם באינטרנט, אבל התיעוד שלו גרוע).
  • לבסוף, ב-FCM יש תמיכה ב-Android, ב-iOS ובאינטרנט, כך שלצוותים מסוימים קל יותר לעבוד איתם בפרויקטים קיימים.

התכונה הזו משתמשת בדחיפה של אינטרנט אל מאחורי הקלעים, אבל המטרה היא להרחיק אותה מהשטח.

כמו שאמרתי בשאלה הקודמת, אם אתם מתייחסים ל-Push באינטרנט בתור דפדפן ושירות דחיפה, אתם יכולים להתייחס ל-Messaging SDK ב-Firebase כספרייה כדי לפשט את ההטמעה של Push Web Push.

השלבים הבאים

שיעורי Lab