Engage SDK: הוראות לשילוב טכני של צד שלישי

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

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

פרטי השילוב

טרמינולוגיה

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

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

  • אשכול המלצות יכול להיות מורכב מנכסי ProductEntity,‏ StoreEntity או RecipeEntity, אבל לא משילוב של סוגי ישויות שונים.

  

  איור : 'ProductEntity',‏ 'StoreEntity' ו-'RecipeEntity'. (*ממשק המשתמש הוא לצורכי המחשה בלבד)

• באשכול מומלצים מוצגת מבחר ישויות מכמה שותפי פיתוח במקבץ אחד בממשק המשתמש. יהיה אשכול אחד של תכנים נבחרים, שיוצג בחלק העליון של ממשק המשתמש במיקום בעל עדיפות מעל כל אשכולות ההמלצות. כל שותף פיתוח יורשה לשדר עד 10 ישויות באשכול 'מומלצים'.

  

  איור : אשכול מומלץ עם 'RecipeEntity'. (*ממשק המשתמש הוא לצורכי המחשה בלבד)

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

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

    

    איור: אשכול של עגלות קניות של מזון משותף יחיד. (*ממשק המשתמש הוא לצורך המחשה בלבד)

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

  

  איור: אשכול של רשימת קניות של מזון משותף יחיד. (*ממשק המשתמש הוא לצורך המחשה בלבד)

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

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

    • תמונות של X פריטים בהזמנה הקודמת של המשתמש.
    • תוויות ל-X פריטים בהזמנה הקודמת של המשתמש.

  

  איור: אשכול של הזמנות חוזרות למסעדות מאותו שותף. (*ממשק המשתמש הוא לצורך המחשה בלבד)

עבודה מוקדמת

רמת ה-API המינימלית: 19

מוסיפים את הספרייה com.google.android.engage:engage-core לאפליקציה:

dependencies {
    // Make sure you also include that repository in your project's build.gradle file.
    implementation 'com.google.android.engage:engage-core:1.5.2'
}

סיכום

התכנון מבוסס על הטמעה של שירות מוגדר.

הנתונים שלקוח יכול לפרסם כפופים למגבלות הבאות לסוגים שונים של אשכולות:

סוג האשכול	מגבלות על אשכולות	מגבלות מקסימליות על ישויות באשכול
אשכולות המלצות	5 לכל היותר	עד 25 (ProductEntity,‏ RecipeEntity או StoreEntity)
אשכול מומלץ	1 לכל היותר	עד 10 (ProductEntity,‏ RecipeEntity או StoreEntity)
אשכול של עגלות קניות עם מזון	1 לכל היותר	ShoppingCartEntity אחד לכל היותר
אשכול של רשימת קניות למזון	1 לכל היותר	ShoppingListEntity אחד לכל היותר
אשכול של הזמנות חוזרות של אוכל	1 לכל היותר	ReorderEntity אחד לכל היותר

שלב 1: מציינים את נתוני הישות

ב-SDK מוגדרות ישויות שונות שמייצגות כל סוג פריט. אנחנו תומכים בישויות הבאות בקטגוריית 'מזון':

1. ProductEntity
2. StoreEntity
3. RecipeEntity
4. FoodShoppingCart
5. FoodShoppingList
6. FoodReorderCluster

בטבלאות הבאות מפורטים המאפיינים והדרישות הזמינים לכל סוג.

ProductEntity

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

איור : מאפיינים של ProductEntity

מאפיין	דרישה	תיאור	פורמט
תמונות של פוסטרים	חובה	צריך לספק לפחות תמונה אחת.	לקבלת הנחיות, אפשר לעיין במפרט לתמונות.
URI של פעולה	חובה	הקישור המעמיק לדף באפליקציה שבו מוצגים פרטים על המוצר. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. אפשר לעיין בשאלות הנפוצות האלה	URI
כותרת	אופציונלי	שם המוצר.	טקסט חופשי גודל טקסט מומלץ: פחות מ-90 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
מחיר – נוכחי	נדרש באופן מותנה	המחיר הנוכחי של המוצר. חובה לציין אם צוין מחיר קודם מחוק.	טקסט חופשי
מחיר – מחיר קודם מחוק	אופציונלי	המחיר המקורי של הישות, שמופיע עם קו חוצה בממשק המשתמש.	טקסט חופשי
הסבר	אופציונלי	קריאה לפעולה להצגת קידום מכירות, אירוע או עדכון למוצר, אם הם זמינים.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
האותיות הקטנות של יתרונות מרכזיים	אופציונלי	טקסט של האותיות הקטנות בנכס היתרונות המרכזיים.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
דירוג (אופציונלי) – הערה: כל הדירוגים מוצגים באמצעות מערכת הדירוג הרגילה שלנו לפי כוכבים.
דירוג – ערך מקסימלי	אופציונלי	הערך המקסימלי בסולם הדירוג. חובה לספק את הערך הזה אם צוין גם הערך הנוכחי של הדירוג.	מספר >= 0.0
דירוג – ערך נוכחי	אופציונלי	הערך הנוכחי של סולם הדירוג. חובה לספק את הערך הזה אם צוין גם הערך המקסימלי של הדירוג.	מספר >= 0.0
דירוג – ספירה	אופציונלי	מספר הדירוגים של המוצר. הערה: יש לציין את השדה הזה אם האפליקציה שלכם קובעת איך המספר יוצג למשתמשים. להשתמש במחרוזת תמציתית. לדוגמה, אם המספר הוא 1,000,000, כדאי להשתמש בקיצור כמו 1M כדי שהמספר לא יקוצר במסכים קטנים יותר.	מחרוזת
דירוג – ערך ספירה	אופציונלי	מספר הדירוגים של המוצר. הערה: יש לציין את השדה הזה אם אתם לא מטפלים בעצמכם בלוגיקה של קיצורי הדרך להצגה. אם גם המדד Count וגם המדד Count Value נמצאים ב-Chart, המדד Count יוצג למשתמשים.	ארוך
DisplayTimeWindow (אופציונלי) – הגדרת חלון זמן להצגת תוכן במשטח
חותמת הזמן של ההתחלה	אופציונלי	חותמת הזמן של תחילת המילניום (epoch) שאחרי שתחלוף היא אמורה להציג את התוכן בממשק. אם המדיניות לא מוגדרת, התוכן עומד בדרישות להצגה בממשק.	חותמת זמן של תחילת המילניום באלפיות השנייה
חותמת זמן של סיום	אופציונלי	חותמת הזמן של עידן (epoch) שאחרי כן התוכן לא יוצג יותר בממשק. אם המדיניות לא מוגדרת, התוכן עומד בדרישות להצגה בממשק.	חותמת זמן של תחילת המילניום באלפיות השנייה

StoreEntity

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

איור : מאפיינים של StoreEntity

מאפיין	דרישה	תיאור	פורמט
תמונות של פוסטרים	חובה	צריך לספק לפחות תמונה אחת.	לקבלת הנחיות, אפשר לעיין במפרט לתמונות.
URI של פעולה	חובה	קישור העומק לדף באפליקציה שבו מוצגים פרטים על החנות. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. אפשר לעיין בשאלות הנפוצות האלה	URI
כותרת	אופציונלי	שם החנות.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
מיקום	אופציונלי	המיקום של החנות.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
הסבר	אופציונלי	כותרת מודגשת עם מבצע, אירוע או עדכון לחנות, אם יש כאלה.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
האותיות הקטנות של יתרונות מרכזיים	אופציונלי	טקסט של האותיות הקטנות בנכס היתרונות המרכזיים.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
תיאור	אופציונלי	תיאור של החנות.	טקסט חופשי גודל טקסט מומלץ: פחות מ-90 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
קטגוריה	אופציונלי	קטגוריה של חנות. בהקשר של מקומות לסעודה, יכולה להיות זו קטגוריית מטבח, כמו 'צרפתי', 'אמריקאי חדש', 'ראמן', 'מסעדת שף'.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
הערה: כל הדירוגים מוצגים לפי מערכת הדירוג הרגילה שלנו לפי כוכבים.
דירוג – ערך מקסימלי	אופציונלי	הערך המקסימלי בסולם הדירוג. חובה לספק את הערך הזה אם צוין גם הערך הנוכחי של הדירוג.	מספר >= 0.0
דירוג – ערך נוכחי	אופציונלי	הערך הנוכחי של סולם הדירוג. חובה לספק את הערך הזה אם צוין גם הערך המקסימלי של הדירוג.	מספר >= 0.0
דירוג – ספירה	אופציונלי	מספר הדירוגים של החנות. הערה: יש לציין את השדה הזה אם רוצים לקבוע באפליקציה איך המידע הזה יוצג למשתמשים. יש לציין את המחרוזת המקוצרת שאפשר להציג למשתמש. לדוגמה, אם המספר הוא 1,000,000, מומלץ להשתמש בקיצור כמו 1M כדי שהוא לא ייחתך במסכים קטנים יותר.	מחרוזת
דירוג – ערך ספירה	אופציונלי	מספר הדירוגים של החנות. הערה: יש לספק את השדה הזה אם אתם לא רוצים לטפל בעצמכם בלוגיקה של קיצורי השמות בתצוגה. אם גם Count וגם Count Value נמצאים, נשתמש ב-Count כדי להציג למשתמשים	ארוך

RecipeEntity

האובייקט RecipeEntity מייצג פריט מתכון ששותפי הפיתוח רוצים לפרסם.

איור : מאפיינים של RecipeEntity

מאפיין	דרישה	תיאור	פורמט
תמונות של פוסטרים	חובה	צריך לספק לפחות תמונה אחת.	לקבלת הנחיות, אפשר לעיין במפרט לתמונות.
URI של פעולה	חובה	קישור העומק לדף באפליקציה שבו מוצגים פרטים על המתכון. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. אפשר לעיין בשאלות הנפוצות האלה	URI
כותרת	אופציונלי	השם של המתכון.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
מחבר	אופציונלי	מחבר המתכון.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
זמן הבישול/ההכנה	אופציונלי	זמן הבישול של המתכון.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
הסבר	אופציונלי	כותרת מודגשת עם קידום מכירות, אירוע או עדכון לגבי המתכון, אם יש כאלה.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
קטגוריה	אופציונלי	הקטגוריה של המתכון.	טקסט חופשי גודל טקסט מומלץ: פחות מ-45 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
תיאור	אופציונלי	תיאור של המתכון.	טקסט חופשי גודל טקסט מומלץ: פחות מ-90 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
הערה: כל הדירוגים מוצגים לפי מערכת הסיווג הרגילה שלנו לפי כוכבים.
דירוג – ערך מקסימלי	אופציונלי	הערך המקסימלי בסולם הדירוג. חובה לספק את הערך הזה אם צוין גם הערך הנוכחי של הדירוג.	מספר >= 0.0
דירוג – ערך נוכחי	אופציונלי	הערך הנוכחי של סולם הדירוג. חובה לספק את הערך הזה אם צוין גם הערך המקסימלי של הדירוג.	מספר >= 0.0
דירוג – ספירה	אופציונלי	מספר הדירוגים של המתכון. הערה: יש לציין את השדה הזה אם רוצים לקבוע באפליקציה איך המידע הזה יוצג למשתמשים. יש לציין את המחרוזת המקוצרת שאפשר להציג למשתמש. לדוגמה, אם המספר הוא 1,000,000, מומלץ להשתמש בקיצור כמו 1M כדי שהוא לא ייחתך במסכים קטנים יותר.	מחרוזת
דירוג – ערך ספירה	אופציונלי	מספר הדירוגים של המתכון. הערה: יש לספק את השדה הזה אם אתם לא רוצים לטפל בעצמכם בלוגיקה של קיצורי השמות בתצוגה. אם גם Count וגם Count Value נמצאים, נשתמש ב-Count כדי להציג למשתמשים	ארוך

FoodShoppingCart

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

מאפיין	דרישה	תיאור	פורמט
URI של פעולה	חובה	קישור העומק לעגלת הקניות באפליקציה של השותף. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. כאן מפורטות שאלות נפוצות בנושא	URI
מספר הפריטים	חובה	מספר הפריטים (לא רק מספר המוצרים) בעגלת הקניות. לדוגמה: אם יש עגלת קניות עם 3 תפוזים ואפל אחד, המספר הזה צריך להיות 4.	מספר שלם >= 1
כותרת	אופציונלי	שם העגלה (לדוגמה, עגלת הקניות). אם המפתח לא מספק שם, ברירת המחדל היא הכרטיסייה שלך.	טקסט חופשי גודל טקסט מומלץ: פחות מ-25 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
טקסט הפעולה	אופציונלי	טקסט הקריאה לפעולה של הלחצן בעגלת הקניות (לדוגמה, הסל שלך). אם המפתח לא מספק טקסט של פעולה, ברירת המחדל היא הצגת עגלת הקניות. המאפיין הזה נתמך מגרסה 1.1.0 ואילך.	מחרוזת
תמונות של עגלות קניות	אופציונלי	תמונות של כל מוצר בעגלת הקניות. אפשר לספק עד 10 תמונות לפי סדר עדיפות. מספר התמונות שיוצגו בפועל תלוי בגורם הצורה של המכשיר.	לקבלת הנחיות, אפשר לעיין במפרט לתמונות.
תוויות של פריטים	אופציונלי	רשימת התוויות של הפריטים ברשימת הקניות. מספר התוויות שמוצג בפועל תלוי בגורם הצורה של המכשיר.	רשימה של תוויות טקסט חופשי גודל טקסט מומלץ: פחות מ-20 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
DisplayTimeWindow (אופציונלי) – הגדרת חלון זמן להצגת תוכן במשטח
חותמת הזמן של ההתחלה	אופציונלי	חותמת הזמן של תחילת המילניום (epoch) שאחרי שתחלוף היא אמורה להציג את התוכן בממשק. אם המדיניות לא מוגדרת, התוכן עומד בדרישות להצגה בממשק.	חותמת זמן של תחילת המילניום באלפיות השנייה
חותמת זמן של סיום	אופציונלי	חותמת הזמן של עידן (epoch) שאחרי כן התוכן לא יוצג יותר בממשק. אם המדיניות לא מוגדרת, התוכן עומד בדרישות להצגה בממשק.	חותמת זמן של תחילת המילניום באלפיות השנייה

FoodShoppingList

איור: אשכול של רשימת קניות של מזון.

מאפיין	דרישה	תיאור	פורמט
URI של פעולה	חובה	קישור העומק לרשימה של קניות באפליקציה של השותף. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. אפשר לעיין בשאלות הנפוצות האלה	URI
מספר הפריטים	חובה	מספר הפריטים ברשימת הקניות.	מספר שלם >= 1
כותרת	אופציונלי	שם הרשימה (לדוגמה, רשימת הקניות שלך). אם המפתח לא מספק שם, ברירת המחדל היא רשימת קניות.	טקסט חופשי גודל טקסט מומלץ: פחות מ-25 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
תוויות של פריטים	חובה	רשימת התוויות של הפריטים ברשימת הקניות. צריך לספק לפחות תווית אחת ועד 10 תוויות לפי סדר עדיפות. המספר בפועל של התוויות שיוצגו תלוי בגורמים שונים, כמו גורם הצורה של המכשיר.	רשימה של תוויות טקסט חופשי גודל טקסט מומלץ: פחות מ-20 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)

FoodReorderCluster

איור: אשכול של הזמנות חוזרות של מזון.

מאפיין	דרישה	תיאור	פורמט
URI של פעולה	חובה	קישור העומק לביצוע הזמנה מחדש באפליקציה של השותף. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. אפשר לעיין בשאלות הנפוצות האלה	URI
טקסט הפעולה	אופציונלי	טקסט הקריאה לפעולה של הלחצן ב'הזמנה מחדש' (לדוגמה, הזמנה מחדש). אם המפתח לא מספק טקסט של פעולה, ברירת המחדל היא סידור מחדש. המאפיין הזה נתמך מגרסה 1.1.0 ואילך.	מחרוזת
מספר הפריטים	חובה	מספר הפריטים (לא רק מספר המוצרים) בהזמנה הקודמת. לדוגמה: אם בהזמנה הקודמת היו 3 קפה קטנים וקרואסון אחד, המספר הזה צריך להיות 4.	מספר שלם >= 1
כותרת	חובה	הכותרת של הפריט שרוצים להזמין מחדש.	טקסט חופשי גודל טקסט מומלץ: פחות מ-40 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
תוויות של פריטים	אופציונלי (אם לא, יש לספק תמונות של כרזות)	רשימת תוויות הפריטים של ההזמנה הקודמת. אפשר לספק עד 10 תוויות לפי סדר עדיפות. מספר התוויות שיוצגו בפועל תלוי בגורם הצורה של המכשיר.	רשימה של טקסט חופשי גודל הטקסט המומלץ לכל תווית: פחות מ-20 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
תמונות של פוסטרים	אופציונלי (אם לא צוינו, יש לציין תוויות של פריטים)	תמונות של הפריטים בהזמנה הקודמת. אפשר לספק עד 10 תמונות לפי סדר עדיפות. מספר התמונות שיוצגו בפועל תלוי בגורם הצורה של המכשיר.	לקבלת הנחיות, אפשר לעיין במפרט לתמונות.

מפרט לתמונות

המפרטים הנדרשים לנכסי תמונות מפורטים בהמשך:

יחס גובה-רוחב	מספר פיקסלים מינימלי	מספר פיקסלים מומלץ
ריבוע (1x1) מועדף	300x300	1,200x1,200
לרוחב (1.91x1)	600x314	1,200x628
לאורך (4x5)	480x600	960x1200

פורמטים של קבצים

PNG, ‏ JPG, ‏ GIF סטטי, ‏ WebP

גודל קובץ מקסימלי

‎5,120 KB

המלצות נוספות

• האזור הבטוח לתמונות: התוכן החשוב צריך להופיע במרכז התמונה, על פני 80% ממנה.
• כדאי להשתמש ברקע שקוף כדי שהתמונה תוצג בצורה תקינה בהגדרות של העיצוב הכהה והבהיר.

שלב 2: מציינים את נתוני האשכולות

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

AppEngageFoodClient אחראי לפרסום אשכולות של מסעדות.

כדי לפרסם אשכולות בלקוח, אפשר להשתמש בממשקי ה-API הבאים:

• isServiceAvailable
• publishRecommendationClusters
• publishFeaturedCluster
• publishFoodShoppingCart
• publishFoodShoppingList
• publishReorderCluster
• publishUserAccountManagementRequest
• updatePublishStatus
• deleteRecommendationsClusters
• deleteFeaturedCluster
• deleteFoodShoppingCartCluster
• deleteFoodShoppingListCluster
• deleteReorderCluster
• deleteUserManagementCluster
• deleteClusters

isServiceAvailable

ה-API הזה משמש לבדיקה אם השירות זמין לשילוב ואם אפשר להציג את התוכן במכשיר.

Kotlin

client.isServiceAvailable.addOnCompleteListener { task ->
    if (task.isSuccessful) {
        // Handle IPC call success
        if(task.result) {
          // Service is available on the device, proceed with content publish
          // calls.
        } else {
          // Service is not available, no further action is needed.
        }
    } else {
      // The IPC call itself fails, proceed with error handling logic here,
      // such as retry.
    }
}

Java

client.isServiceAvailable().addOnCompleteListener(task - > {
    if (task.isSuccessful()) {
        // Handle success
        if(task.getResult()) {
          // Service is available on the device, proceed with content publish
          // calls.
        } else {
          // Service is not available, no further action is needed.
        }
    } else {
      // The IPC call itself fails, proceed with error handling logic here,
      // such as retry.
    }
});

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

publishRecommendationClusters

ה-API הזה משמש לפרסום רשימה של אובייקטים מסוג RecommendationCluster.

לאובייקט RecommendationCluster יכולים להיות המאפיינים הבאים:

מאפיין	דרישה	תיאור
רשימה של ProductEntity,‏ StoreEntity או RecipeEntity	חובה	רשימה של ישויות שמרכיבות את ההמלצות באשכול ההמלצות הזה. יש להשתמש באובייקטים מאותו סוג באשכול אחד.
כותרת	חובה	השם של אשכול ההמלצות (לדוגמה, חיסכון גדול בתפריט לחג ההודיה). גודל טקסט מומלץ: פחות מ-25 תווים (טקסט ארוך מדי עשוי לכלול שלוש נקודות)
כותרת משנה	אופציונלי	כותרת המשנה של אשכול ההמלצות.
URI של פעולה	אופציונלי	קישור העומק לדף באפליקציה של השותף שבו המשתמשים יכולים לראות את רשימת ההמלצות המלאה. הערה: אפשר להשתמש בקישורי עומק לצורך שיוך. כאן מפורטות שאלות נפוצות בנושא

חשוב: ממשקי ה-API לפרסום הם ממשקי API מסוג upsert, והם מחליפים את התוכן הקיים. לא קוראים לממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי.

Kotlin

client.publishRecommendationClusters(
            PublishRecommendationClustersRequest.Builder()
                .addRecommendationCluster(
                    RecommendationCluster.Builder()
                        .addEntity(entity1)
                        .addEntity(entity2)
                        .setTitle("Big savings on Thanksgiving menu")
                        .build())
                .build())

Java

client.publishRecommendationClusters(
            new PublishRecommendationClustersRequest.Builder()
                .addRecommendationCluster(
                    new RecommendationCluster.Builder()
                        .addEntity(entity1)
                        .addEntity(entity2)
                        .setTitle("Big savings on Thanksgiving menu")
                        .build())
                .build());

כשהבקשה מתקבלת בשירות, מתבצעות הפעולות הבאות בעסקה אחת:

• כל הנתונים הקיימים של אשכול ההמלצות יוסרו.
• הנתונים מהבקשה מנותחים ונשמרים באשכול המלצות חדש.

במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

publishFeaturedCluster

ה-API הזה משמש לפרסום אובייקט FeaturedCluster.

חשוב: ממשקי ה-API לפרסום הם ממשקי API מסוג upsert, והם מחליפים את התוכן הקיים. לא קוראים לממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי.

Kotlin

client.publishFeaturedCluster(
            PublishFeaturedClusterRequest.Builder()
                .setFeaturedCluster(
                    FeaturedCluster.Builder()
                        ...
                        .build())
                .build())

Java

client.publishFeaturedCluster(
            new PublishFeaturedClusterRequest.Builder()
                .setFeaturedCluster(
                    new FeaturedCluster.Builder()
                        ...
                        .build())
                .build());

כשהבקשה מתקבלת בשירות, מתבצעות הפעולות הבאות בעסקה אחת:

• הנתונים הקיימים של FeaturedCluster מהשותף המפתח יוסרו.
• הנתונים מהבקשה מנותחים ונשמרים באשכול המלצות המעודכן.

במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

publishFoodShoppingCart

ה-API הזה משמש לפרסום אובייקט FoodShoppingCart.

חשוב: ממשקי ה-API לפרסום הם ממשקי API מסוג upsert, והם מחליפים את התוכן הקיים. לא קוראים לממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי.

Kotlin

client.publishFoodShoppingCart(
            PublishFoodShoppingCartClusterRequest.Builder()
                .setShoppingCart(
                    FoodShoppingCart.Builder()
                        ...
                        .build())
                .build())

Java

client.publishFoodShoppingCart(
            new PublishFoodShoppingCartClusterRequest.Builder()
                .setShoppingCart(
                    new FoodShoppingCart.Builder()
                        ...
                        .build())
                .build());

כשהבקשה מתקבלת בשירות, מתבצעות הפעולות הבאות בעסקה אחת:

• הנתונים הקיימים של FoodShoppingCart מהשותף המפתח יוסרו.
• הנתונים מהבקשה מנותחים ונשמרים באשכול המעודכן של עגלות הקניות.

במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

publishFoodShoppingList

ה-API הזה משמש לפרסום אובייקט FoodShoppingList.

חשוב: ממשקי ה-API לפרסום הם ממשקי API מסוג upsert, והם מחליפים את התוכן הקיים. לא קוראים לממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי.

Kotlin

client.publishFoodShoppingList(
            PublishFoodShoppingListRequest.Builder()
                .setFoodShoppingList(
                    FoodShoppingListEntity.Builder()
                        ...
                        .build())
                .build())

Java

client.publishFoodShoppingList(
            new PublishFoodShoppingListRequest.Builder()
                .setFoodShoppingList(
                    new FoodShoppingListEntity.Builder()
                        ...
                        .build())
                .build());

כשהבקשה מתקבלת בשירות, מתבצעות הפעולות הבאות בעסקה אחת:

• הנתונים הקיימים של FoodShoppingList מהשותף המפתח יוסרו.
• הנתונים מהבקשה מנותחים ונשמרים באשכול המעודכן של רשימת הקניות.

במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

publishReorderCluster

ה-API הזה משמש לפרסום אובייקט FoodReorderCluster.

חשוב: ממשקי ה-API לפרסום הם ממשקי API מסוג upsert, והם מחליפים את התוכן הקיים. לא קוראים לממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי.

Kotlin

client.publishReorderCluster(
            PublishReorderClusterRequest.Builder()
                .setReorderCluster(
                    FoodReorderCluster.Builder()
                        ...
                        .build())
                .build())

Java

client.publishReorderCluster(
            new PublishReorderClusterRequest.Builder()
                .setReorderCluster(
                    new FoodReorderCluster.Builder()
                        ...
                        .build())
                .build());

כשהבקשה מתקבלת בשירות, מתבצעות הפעולות הבאות בעסקה אחת:

• הנתונים הקיימים של FoodReorderCluster מהשותף המפתח יוסרו.
• הנתונים מהבקשה מנותחים ונשמרים באשכול Reorder המעודכן.

במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

publishUserAccountManagementRequest

ה-API הזה משמש לפרסום כרטיס כניסה . פעולת הכניסה מפנה את המשתמשים לדף הכניסה של האפליקציה כדי שהאפליקציה תוכל לפרסם תוכן (או לספק תוכן מותאם אישית יותר).

המטא-נתונים הבאים הם חלק מכרטיס הכניסה:

מאפיין	דרישה	תיאור
URI של פעולה	חובה	קישור עומק לפעולה (כלומר, ניווט לדף הכניסה לאפליקציה)
תמונה	אופציונלי – אם לא מציינים אותו, צריך לציין את השם	התמונה שמוצגת בכרטיס תמונות ביחס גובה-רוחב של 16x9 ברזולוציה של 1264x712
כותרת	אופציונלי – אם לא יצוין, חובה לציין תמונה	השם בכרטיס
טקסט הפעולה	אופציונלי	הטקסט שמוצג בקריאה לפעולה (למשל 'כניסה')
כותרת משנה	אופציונלי	כתוביות אופציונליות בכרטיס

חשוב: ממשקי ה-API לפרסום הם ממשקי API מסוג upsert, והם מחליפים את התוכן הקיים. לא קוראים לממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי.

Kotlin

var SIGN_IN_CARD_ENTITY =
      SignInCardEntity.Builder()
          .addPosterImage(
              Image.Builder()
                  .setImageUri(Uri.parse("http://www.x.com/image.png"))
                  .setImageHeightInPixel(500)
                  .setImageWidthInPixel(500)
                  .build())
          .setActionText("Sign In")
          .setActionUri(Uri.parse("http://xx.com/signin"))
          .build()

client.publishUserAccountManagementRequest(
            PublishUserAccountManagementRequest.Builder()
                .setSignInCardEntity(SIGN_IN_CARD_ENTITY)
                .build());

Java

SignInCardEntity SIGN_IN_CARD_ENTITY =
      new SignInCardEntity.Builder()
          .addPosterImage(
              new Image.Builder()
                  .setImageUri(Uri.parse("http://www.x.com/image.png"))
                  .setImageHeightInPixel(500)
                  .setImageWidthInPixel(500)
                  .build())
          .setActionText("Sign In")
          .setActionUri(Uri.parse("http://xx.com/signin"))
          .build();

client.publishUserAccountManagementRequest(
            new PublishUserAccountManagementRequest.Builder()
                .setSignInCardEntity(SIGN_IN_CARD_ENTITY)
                .build());

כשהבקשה מתקבלת בשירות, מתבצעות הפעולות הבאות בעסקה אחת:

• הנתונים הקיימים של UserAccountManagementCluster מהשותף המפתח יוסרו.
• הנתונים מהבקשה מנותחים ונשמרים באשכול המעודכן UserAccountManagementCluster.

במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

updatePublishStatus

אם אף אחד מהאשכולות לא פורסם מסיבה עסקית פנימית כלשהי, מומלץ מאוד לעדכן את סטטוס הפרסום באמצעות ה-API updatePublishStatus. חשוב לציין זאת מהסיבות הבאות :

• חשוב לספק את הסטטוס בכל התרחישים, גם כשהתוכן פורסם (STATUS == PUBLISHED), כדי לאכלס מרכזי בקרה שמשתמשים בסטטוס הברור הזה כדי להעביר את סטטוס התקינות ומדדים אחרים של השילוב.
• אם לא פורסם תוכן אבל סטטוס השילוב תקין (STATUS == NOT_PUBLISHED), Google יכולה להימנע מהפעלת התראות בלוחות הבקרה של בריאות האפליקציה. הוא מאשר שהתוכן לא פורסם בגלל מצב צפוי מנקודת המבט של הספק.
• היא עוזרת למפתחים לספק תובנות לגבי הזמנים שבהם הנתונים מתפרסמים, לעומת הזמנים שבהם הם לא מתפרסמים.
• Google עשויה להשתמש בקודי המצב כדי לעודד את המשתמש לבצע פעולות מסוימות באפליקציה, כדי שיוכל לראות את תוכן האפליקציה או להתגבר עליו.

רשימת קודי הסטטוס של פרסום שעומדים בדרישות :

// Content is published
AppEngagePublishStatusCode.PUBLISHED,

// Content is not published as user is not signed in
AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SIGN_IN,

// Content is not published as user is not subscribed
AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SUBSCRIPTION,

// Content is not published as user location is ineligible
AppEngagePublishStatusCode.NOT_PUBLISHED_INELIGIBLE_LOCATION,

// Content is not published as there is no eligible content
AppEngagePublishStatusCode.NOT_PUBLISHED_NO_ELIGIBLE_CONTENT,

// Content is not published as the feature is disabled by the client
// Available in v1.3.1
AppEngagePublishStatusCode.NOT_PUBLISHED_FEATURE_DISABLED_BY_CLIENT,

// Content is not published as the feature due to a client error
// Available in v1.3.1
AppEngagePublishStatusCode.NOT_PUBLISHED_CLIENT_ERROR,

// Content is not published as the feature due to a service error
// Available in v1.3.1
AppEngagePublishStatusCode.NOT_PUBLISHED_SERVICE_ERROR,

// Content is not published due to some other reason
// Reach out to engage-developers@ before using this enum.
AppEngagePublishStatusCode.NOT_PUBLISHED_OTHER

אם התוכן לא פורסם כי המשתמש לא נכנס לחשבון, Google ממליצה לפרסם את כרטיס הכניסה. אם מסיבה כלשהי הספקים לא יכולים לפרסם את כרטיס הכניסה, מומלץ לבצע קריאה ל-API‏ updatePublishStatus עם קוד הסטטוס NOT_PUBLISHED_REQUIRES_SIGN_IN.

Kotlin

client.updatePublishStatus(
   PublishStatusRequest.Builder()
     .setStatusCode(AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SIGN_IN)
     .build())

Java

client.updatePublishStatus(
    new PublishStatusRequest.Builder()
        .setStatusCode(AppEngagePublishStatusCode.NOT_PUBLISHED_REQUIRES_SIGN_IN)
        .build());

deleteRecommendationClusters

ממשק ה-API הזה משמש למחיקת התוכן של אשכולות ההמלצות.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל [e-mail].

Kotlin

client.deleteRecommendationClusters()

Java

client.deleteRecommendationClusters();

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

הערה: ממשק ה-API הזה זמין מגרסה 1.1.0 ואילך.

deleteFeaturedCluster

ממשק ה-API הזה משמש למחיקת התוכן של 'אוסף פריטים נבחרים'.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל engage-developers@‎.

Kotlin

client.deleteFeaturedCluster()

Java

client.deleteFeaturedCluster();

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

הערה: ממשק ה-API הזה זמין מגרסה 1.1.0 ואילך.

deleteFoodShoppingCartCluster

ה-API הזה משמש למחיקת התוכן של אשכול עגלות הקניות של מוצרי מזון.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל engage-developers@‎.

Kotlin

client.deleteFoodShoppingCartCluster()

Java

client.deleteFoodShoppingCartCluster();

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

הערה: ה-API הזה זמין מגרסה 1.1.0 ואילך.

deleteFoodShoppingListCluster

ה-API הזה משמש למחיקת התוכן של אשכול רשימת הקניות של מזון.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל engage-developers@‎.

Kotlin

client.deleteFoodShoppingListCluster()

Java

client.deleteFoodShoppingListCluster();

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

הערה: ממשק ה-API הזה זמין מגרסה 1.1.0 ואילך.

deleteReorderCluster

ה-API הזה משמש למחיקת התוכן של FoodReorderCluster.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל [e-mail].

Kotlin

client.deleteReorderCluster()

Java

client.deleteReorderCluster();

כשהבקשה מתקבלת בשירות, הנתונים הקיימים מוסרים מאשכול ה-Reorder. במקרה של שגיאה, הבקשה כולה נדחית והמצב הקיים נשמר.

הערה: ממשק ה-API הזה זמין מגרסה 1.1.0 ואילך.

deleteUserManagementCluster

ממשק ה-API הזה משמש למחיקת התוכן של UserAccountManagement Cluster.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל [e-mail].

Kotlin

client.deleteUserManagementCluster()

Java

client.deleteUserManagementCluster();

כשהבקשה מתקבלת בשירות, הנתונים הקיימים מוסרים מהאשכול UserAccountManagement. במקרה של שגיאה, הבקשה כולה תידחה והמצב הקיים יישמר.

הערה: ממשק ה-API הזה זמין מגרסה 1.1.0 ואילך.

deleteClusters

ממשק ה-API הזה משמש למחיקת התוכן של סוג אשכול נתון.

חשוב: צריך להפעיל את Delete APIs רק אם אין תוכן לפרסם. לא צריך להפעיל את ממשקי ה-API של המחיקה והפרסום לאחר מכן כדי להחליף את התוכן, כי ממשקי ה-API של הפרסום עושים זאת באופן מהותי. לפני שמשתמשים בממשקי API למחיקה, צריך לפנות אל [e-mail].

Kotlin

client.deleteClusters(
    DeleteClustersRequest.Builder()
      .addClusterType(ClusterType.TYPE_FEATURED)
      .addClusterType(ClusterType.TYPE_RECOMMENDATION)
      ...
      .build())

Java

client.deleteClusters(
            new DeleteClustersRequest.Builder()
                .addClusterType(ClusterType.TYPE_FEATURED)
                .addClusterType(ClusterType.TYPE_RECOMMENDATION)
                ...
                .build());

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

טיפול בשגיאות

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

client.publishRecommendationClusters(
              new PublishRecommendationClustersRequest.Builder()
                  .addRecommendationCluster(...)
                  .build())
          .addOnCompleteListener(
              task -> {
                if (task.isSuccessful()) {
                  // do something
                } else {
                  Exception exception = task.getException();
                  if (exception instanceof AppEngageException) {
                    @AppEngageErrorCode
                    int errorCode = ((AppEngageException) exception).getErrorCode();
                    if (errorCode == AppEngageErrorCode.SERVICE_NOT_FOUND) {
                      // do something
                    }
                  }
                }
              });

השגיאה מוחזרת כ-AppEngageException, והסיבה כלולה כקוד שגיאה.

קוד שגיאה	שם השגיאה	הערה
1	SERVICE_NOT_FOUND	השירות לא זמין במכשיר הנתון.
2	SERVICE_NOT_AVAILABLE	השירות זמין במכשיר הנתון, אבל הוא לא זמין בזמן השיחה (לדוגמה, הוא מושבת באופן מפורש).
3	SERVICE_CALL_EXECUTION_FAILURE	ביצוע המשימה נכשל בגלל בעיות בשרשור. במקרה כזה, אפשר לנסות שוב.
4	SERVICE_CALL_PERMISSION_DENIED	למתקשר אין הרשאה לבצע את קריאת השירות.
5	SERVICE_CALL_INVALID_ARGUMENT	הבקשה מכילה נתונים לא חוקיים (לדוגמה, יותר ממספר האשכולות המותר).
6	SERVICE_CALL_INTERNAL	יש שגיאה בצד השירות.
7	SERVICE_CALL_RESOURCE_EXHAUSTED	קריאת השירות מתבצעת בתדירות גבוהה מדי.

שלב 3: טיפול בכוונות שידור

בנוסף לקריאות ל-Content API לפרסום תוכן דרך משימה, צריך גם להגדיר BroadcastReceiver כדי לקבל את הבקשה לפרסום התוכן.

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

צריך להגדיר את BroadcastReceiver בשתי הדרכים הבאות:

• רישום דינמי של מופע של הכיתה BroadcastReceiver באמצעות Context.registerReceiver(). כך אפשר לתקשר עם אפליקציות שעדיין נמצאות בזיכרון.

class AppEngageBroadcastReceiver extends BroadcastReceiver {
// Trigger recommendation cluster publish when PUBLISH_RECOMMENDATION broadcast
// is received

// Trigger featured cluster publish when PUBLISH_FEATURED broadcast is received

// Trigger shopping cart cluster publish when PUBLISH_FOOD_SHOPPING_CART
// broadcast is received

// Trigger shopping list cluster publish when PUBLISH_FOOD_SHOPPING_LIST
// broadcast is received

// Trigger reorder cluster publish when PUBLISH_REORDER_CLUSTER broadcast is
// received
}

public static void registerBroadcastReceivers(Context context) {

context = context.getApplicationContext();

// Register Recommendation Cluster Publish Intent
context.registerReceiver(new AppEngageBroadcastReceiver(),
new IntentFilter(com.google.android.engage.service.Intents.ACTION_PUBLISH_RECOMMENDATION));

// Register Featured Cluster Publish Intent
context.registerReceiver(new AppEngageBroadcastReceiver(),
new IntentFilter(com.google.android.engage.service.Intents.ACTION_PUBLISH_FEATURED));

// Register Shopping Cart Cluster Publish Intent
context.registerReceiver(new AppEngageBroadcastReceiver(),
new IntentFilter(com.google.android.engage.food.service.Intents.ACTION_PUBLISH_FOOD_SHOPPING_CART));

// Register Shopping List Cluster Publish Intent
context.registerReceiver(new AppEngageBroadcastReceiver(),
new IntentFilter(com.google.android.engage.food.service.Intents.ACTION_PUBLISH_FOOD_SHOPPING_LIST));

// Register Reorder Cluster Publish Intent
context.registerReceiver(new AppEngageBroadcastReceiver(),
new IntentFilter(com.google.android.engage.food.service.Intents.ACTION_PUBLISH_REORDER_CLUSTER));

}

• מגדירים באופן סטטי הטמעה באמצעות התג <receiver> בקובץ AndroidManifest.xml. כך האפליקציה יכולה לקבל כוונות שידור כשהיא לא פועלת, וגם לפרסם את התוכן.

<application>
   <receiver
      android:name=".AppEngageBroadcastReceiver"
      android:exported="true"
      android:enabled="true">
      <intent-filter>
         <action android:name="com.google.android.engage.action.PUBLISH_RECOMMENDATION" />
      </intent-filter>
      <intent-filter>
         <action android:name="com.google.android.engage.action.PUBLISH_FEATURED" />
      </intent-filter>
      <intent-filter>
         <action android:name="com.google.android.engage.action.food.PUBLISH_FOOD_SHOPPING_CART" />
      </intent-filter>
      <intent-filter>
         <action android:name="com.google.android.engage.action.food.PUBLISH_FOOD_SHOPPING_LIST" />
      </intent-filter>
      <intent-filter>
         <action android:name="com.google.android.engage.action.food.PUBLISH_REORDER_CLUSTER" />
      </intent-filter>
   </receiver>
</application>

השירות ישלח את הכוונות הבאות:

• com.google.android.engage.action.PUBLISH_RECOMMENDATION מומלץ להתחיל שיחת publishRecommendationClusters כשמקבלים את הכוונה הזו.
• com.google.android.engage.action.PUBLISH_FEATURED מומלץ להתחיל שיחת publishFeaturedCluster כשמקבלים את הכוונה הזו.
• com.google.android.engage.action.food.PUBLISH_FOOD_SHOPPING_CART מומלץ להתחיל שיחת publishFoodShoppingCart כשמקבלים את הכוונה הזו.
• com.google.android.engage.action.food.PUBLISH_FOOD_SHOPPING_LIST מומלץ להתחיל שיחת publishFoodShoppingList כשמקבלים את הכוונה הזו.
• com.google.android.engage.action.food.PUBLISH_REORDER_CLUSTER מומלץ להתחיל שיחת publishReorderCluster כשמקבלים את הכוונה הזו.

תהליך העבודה של השילוב

במדריך המפורט תהליך השילוב של Engage למפתחים מוסבר איך לאמת את השילוב אחרי שהוא הושלם.

שאלות נפוצות

בשאלות הנפוצות על Engage SDK תוכלו למצוא שאלות נפוצות נוספות.

יצירת קשר

אם יש לכם שאלות במהלך תהליך השילוב, תוכלו לפנות אל [e-mail]. הצוות שלנו ישיב בהקדם האפשרי.

השלבים הבאים

אחרי השלמת השילוב, עליכם לבצע את השלבים הבאים:

• שולחים אימייל לכתובת [e-mail] ומצרפים את קובץ ה-APK המשולב שעומד בדרישות הבדיקה של Google.
• Google תבצע אימות ובדיקה פנימית כדי לוודא שההטמעה פועלת כצפוי. אם יהיה צורך בשינויים, Google תיצור איתכם קשר עם הפרטים הנדרשים.
• בסיום הבדיקה, אם לא נדרשים שינויים, Google תיצור איתכם קשר כדי להודיע לכם שתוכלו להתחיל לפרסם את קובץ ה-APK המעודכן והמשולב בחנות Play.
• אחרי ש-Google תאשר שהקובץ העדכני של ה-APK פורסם בחנות Play, האשכולות המלצות, מוצרים נבחרים, עגלת קניות, רשימת קניות והזמנה מחדש יפורסמו ויוצגו למשתמשים.