פתרון בעיות ושאלות נפוצות בנושא העברת הודעות בענן ב-Firebase

מה ההבדל בין ניסוח מסרים (Notifications Composer) לבין FCM?

‫Firebase Cloud Messaging מספק קבוצה מלאה של יכולות העברת הודעות באמצעות ערכות ה-SDK של הלקוח ופרוטוקול שרת ה-HTTP. אם אתם צריכים לשלוח הודעות מורכבות יותר, FCM הוא הבחירה הנכונה.

הכלי "ניסוח מסרים" הוא פתרון קל משקל להעברת הודעות בלי שרת (serverless), שמבוסס על Firebase Cloud Messaging. הכלי לניסוח מסרים כולל מסוף גרפי ידידותי למשתמש ודורש פחות כתיבת קוד. הוא מאפשר למשתמשים לשלוח הודעות כדי לעודד אינטראקציה חוזרת ולשמר משתמשים, להגדיל את מספר המשתמשים באפליקציה ולתמוך בקמפיינים שיווקיים.

האם צריך להשתמש בשירותים אחרים של Firebase כדי להשתמש ב-FCM?

אפשר להשתמש ב-Firebase Cloud Messaging כרכיב עצמאי, בלי להשתמש בשירותים אחרים של Firebase.

למה נראה שמכשירי היעד לא מקבלים הודעות?

אם נראה שהמכשירים לא קיבלו הודעות, קודם כל צריך לבדוק את שתי הסיבות האפשריות הבאות:

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

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

• 5228
• 5229
• 5230

‫FCM משתמש בדרך כלל ביציאה 5228, אבל לפעמים הוא משתמש ביציאות 5229 ו-5230. ‫FCM לא מספק כתובות IP ספציפיות, לכן צריך לאפשר לחומת האש לקבל חיבורים יוצאים לכל כתובות ה-IP שכלולות בבלוקים של כתובות ה-IP שרשומים ב-ASN של Google‏ (15169).

למה לא מתבצעת קריאה ל-onMessageReceived באפליקציה שלי ל-Android?

כשהאפליקציה פועלת ברקע, הודעות ההתראה מוצגות במגש המערכת, והפונקציה onMessageReceived לא מופעלת. בהודעות התראה עם מטען ייעודי (payload) של נתונים, הודעת ההתראה מוצגת במגש המערכת, ואפשר לאחזר את הנתונים שנכללו בהודעת ההתראה מה-intent שהופעל כשהמשתמש לחץ על ההתראה.

מידע נוסף זמין במאמר קבלת הודעות וטיפול בהן.

למה מופיעה שגיאה 404 כשאני שולח הודעות למופע פעיל של אפליקציה ששוחזר מגיבוי?

מזהה ההתקנה של Firebase‏ (FID) הוא המזהה של מופע האפליקציה. כברירת מחדל, הנתונים של Firebase Installation מגובים ומשוחזרים. לכן, במקרה של שחזור, למופע של האפליקציה ששוחזר ולמופע המקורי של האפליקציה יש אותו FID. מכיוון ש-FCM מאחסן רק אסימון אחד לכל FID, אם גם מופע האפליקציה המקורי וגם מופע האפליקציה ששוחזר נמצאים בשימוש, אז כשמופע אפליקציה אחד נרשם ב-FCM, האסימון של מופע האפליקציה השני מוסר, מה שגורם לשגיאות 404.

אנחנו ממליצים למפתחים לבצע את הפעולות הבאות באפליקציה:

• לא לכלול את נתוני ההתקנה של Firebase בגיבוי. נתוני ההתקנה של Firebase מאוחסנים בקובץ PersistedInstallation....json. שם הקובץ הוא קבוע לאפליקציה. לדוגמה, <exclude domain="file" path="PersistedInstallation.W0R...GQ.json" />

חברת Apple הודיעה שהיא מוציאה משימוש את הפרוטוקול הבינארי הקודם של APNs. מה צריך לעשות?

לא. בשנת 2017, Firebase Cloud Messaging עברה לפרוטוקול APNs שמבוסס על HTTP/2. אם אתם משתמשים ב-FCM כדי לשלוח התראות למכשירי iOS, לא נדרשת פעולה מצדכם.

איך אפשר להודיע לקהל לקוחות גדול תוך 2 דקות?

תרחיש השימוש הזה לא נתמך. צריך לפרוס את התנועה על פני 5 דקות.

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

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

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

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

איך אפשר לעקוב אחרי ניצול המכסות?

איך ממפים ועוקבים אחרי מדדי מכסות ב-Google Cloud

שגיאות 429 הן קשות לטיפול בשבילי ובשביל העסק שלי. האם אפשר לקבל פטור או מכסה גדולה יותר כדי להימנע משגיאות 429?

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

כמה זמן לוקח עד שמקבלים תשובה לבקשה להגדלת המכסה?

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

אפשר להגדיל את המכסה לאירוע זמני?

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

האם המכסה הנוכחית שלי יכולה להשתנות?

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

אילו ממשקי API ותכונות יוצאו משימוש ויושבתו? מה צריך לעשות אם משתמשים בממשקי ה-API האלה?

כל ממשקי ה-API של שרת InstanceId והתכונה "קבוצת מכשירים" הוצאו משימוש ויושבתו ב-29 בספטמבר 2027. בטבלה הבאה מפורטים פרטים נוספים על ממשקי ה-API והתכונות שהוצאו משימוש, ועל הפעולות שצריך לבצע.

אם אני משתמש ב-SDK של Firebase לאדמינים כדי לנהל מינויים לנושאים, האם ההוצאה משימוש תשפיע עליי? מה לעשות?

אם אתם משתמשים בגרסאות קודמות של SDK של Firebase לאדמינים כדי לנהל מינויים לנושאים, הפסקת התמיכה תשפיע עליכם. צריך לשדרג את ה-SDK של Firebase לאדמינים לגרסאות הבאות:

האם תהיה ירידה ברמת השירות לפני 29 בספטמבר 2027?

לא. יש לכם 12 חודשים לעבור מממשקי ה-API שהוצאו משימוש לחלופות, בלי שהשירות יושפע. מומלץ מאוד לתכנן את ההעברה בהקדם האפשרי כדי שההוצאה משימוש לא תשפיע עליכם.

אם תשלחו קריאות לממשקי API שהוצאו משימוש אחרי 29 בספטמבר 2027, תקבלו שגיאות.

האם משתמשים חדשים יכולים להצטרף לממשקי ה-API או לתכונות שהוצאו משימוש לפני שהם יושבתו?

משתמשים חדשים יכולים להצטרף לממשקי ה-API או לתכונות שהוצאו משימוש לפני 1 בינואר 2027. אחרי 1 בינואר 2027, משתמשים חדשים לא יוכלו להשתמש בממשקי ה-API שהוצאו משימוש. משתמשים שכבר משתמשים בממשקי ה-API שהוצאו משימוש יכולים להמשיך להשתמש בהם עד 29 בספטמבר 2027.

למשך כמה זמן תהיה תמיכה ב-AndroidConfig (v1) API הקודם?

‫FCM מתכננת להמשיך לתמוך במטענים ייעודיים (payloads) של AndroidConfig בגרסה 1 במשך כמה שנים אחרי ההשקה של AndroidConfigV2 לכלל המשתמשים (GA). ציר הזמן של ההעברה נמשך כמה שנים, אבל AndroidConfigV2 מספקת מסירת התראות צפויה יותר, ואנחנו ממליצים לעבור בהקדם האפשרי.

באילו גרסאות של Android OS יש תמיכה ב-AndroidConfigV2?

‫AndroidConfigV2 תתמוך בכל גרסאות Android שנתמכות על ידי Google. כשגרסה 1 של ה-API תוצא משימוש, כל המכשירים ייתמכו, חוץ ממכשירים בני יותר מ-10 שנים.

האם AndroidConfigV2 יעביר מטענים ייעודיים (payloads) למכשירים שתומכים רק בממשק v1 הישן, ובאיזה סדר צריך להשיק את השינויים?

כן. כששולחים בקשה של AndroidConfigV2, ‏FCM ו-GMS Core מתרגמים באופן אוטומטי את המטען הייעודי (payload) למכשירים שפועלים בהם ערכות SDK ישנות יותר של לקוחות, או לאפליקציות שעדיין לא ביטלו את onNotificationReceived() או את onBackgroundSyncReceived(), ומעבירים אותו באמצעות onMessageReceived().

למה ב-AndroidConfigV2 צריך להחזיר התראות דרך ה-SDK של FCM במקום להפעיל ישירות את NotificationManager.notify()‎?

אפשר להחזיר NotificationResponse ל-SDK של FCM בקוד פתוח, או להשתמש ב-FcmNotificationManager:

• האפליקציה מקבלת חלון הרצה מוגן כדי לפענח או להתאים אישית את ההתראה.
• אם האפליקציה לא מספיקה להציג את ההתראה בזמן, GMS Core מציג את התראת הגיבוי שהגדרתם ב-remote_notification.notification.

האם AndroidConfigV2 מטפל בהתראות באופן שונה כשהאפליקציה פועלת בחזית לעומת כשהיא פועלת ברקע?

לא. בניגוד להודעות התראה מדור קודם בגרסה 1, ב-AndroidConfigV2 אין פיצול של ניתוב ההודעות על סמך המיקום של האפליקציה – בחזית או ברקע. כששולחים RemoteNotification, ההתראה מוצגת באופן אוטומטי בשני המצבים, אלא אם מגדירים את mutable_content: true ומשתיקים אותה באופן מפורש ב-onNotificationReceived() באמצעות NotificationResponse.createEmpty().

כמה זמן יש לאפליקציה שלי לטפל ב-RemoteNotification שניתן לשינוי?

כשמגדירים את mutable_content: true ב-RemoteNotification, לאפליקציה יש עד 20 שניות בתוך onNotificationReceived() כדי לפענח את המטען הייעודי (payload), לאחזר נכסים קטנים (כמו דמויות avatar) או ליצור קשר עם שרת האפליקציה לפני החזרת NotificationResponse. אם הקריאה החוזרת נמשכת יותר מ-20 שניות, הביצוע מבוטל ו-GMS Core מפרסם באופן אוטומטי התראה חלופית על סמך המטען הייעודי (payload) של remote_notification.notification.

איך פועלת אכיפת ביטול ההתראות ב-RemoteNotifications שניתנות לשינוי?

אפליקציות יכולות להשתיק RemoteNotification על ידי החזרת הערך NotificationResponse.suppress() מ-onNotificationReceived(). לדוגמה, כשצ'אט מושתק, כששולח נחסם או כשאימות של מטען ייעודי (payload) מוצפן מקצה לקצה נכשל.

• ברקע: האפליקציה יכולה להשתיק עד 25% מההודעות שהתקבלו מ-RemoteNotification בחלון זמן דינמי. אם שיעור ההשתקה ברקע של האפליקציה חורג מ-25%, GMS Core מעבד ומפרסם באופן אוטומטי את ההתראה החלופית מהמטען הייעודי (payload) של remote_notification.notification.
• בחזית: אתם יכולים להשתיק את כל ההתראות מרחוק כשהאפליקציה פעילה בחזית. לדוגמה, כדי להציג הודעה קצרה באפליקציה או לעדכן מסך צ'אט פתוח במקום לפרסם התראה של המערכת.

האם האפליקציה שלי יכולה לפרסם כמה התראות או לבטל התראה קיימת מ-RemoteNotification יחיד?

כן. כדי לבטל או לפרסם כמה התראות:

• ביטול התראה אחת: מחזירים את הערך NotificationResponse.createCancel(tag, id) מ-onNotificationReceived() כדי לבטל התראה שנשלחה בעבר.
• פרסום של כמה התראות או שילוב של ביטולים ופרסומים: קוראים ל-getFcmNotificationManager(message) בתוך onNotificationReceived() כדי להפעיל את postNow(tag, id, notification) ואת cancelNow(tag, id) כמה פעמים, ומחזירים את manager.finished() בסיום.

האם אפשר להשתמש ב-RemoteViews בהתאמה אישית עם AndroidConfigV2?

כן, תצוגות RemoteViews בהתאמה אישית יפעלו עם AndroidConfigV2. ‫onNotificationReceived() מחזיר אובייקט Notification רגיל של Android, וכל ממשקי ה-API הרגילים של Android להתראות, כמו setCustomContentView(), עדיין נתמכים. חשוב לזכור ש-RemoteViews ו-Views נמצאים במצב תחזוקה, ומומלץ לעבור ל-Compose.