מודעות מותאמות הן נכסים שמצורפים למודעה שמוצגים למשתמשים באמצעות רכיבי ממשק משתמש שמותאמים לפלטפורמה. הן מוצגות באמצעות אותם סוגי תצוגות שבהם אתם כבר משתמשים כדי ליצור את הפריסות, ואפשר לעצב אותן כך שיתאימו לעיצוב החזותי של האפליקציה.
כשטעינת מודעה מותאמת מתבצעת, האפליקציה מקבלת אובייקט מודעה שמכיל את הנכסים שלה, והאפליקציה (ולא Google Mobile Ads SDK (Legacy)) אחראית להציג אותם.
באופן כללי, כדי להטמיע מודעות מותאמות צריך לבצע שתי פעולות: לטעון מודעה באמצעות ה-SDK ואז להציג את תוכן המודעה באפליקציה.
בדף הזה מוסבר איך להשתמש ב-SDK כדי לטעון מודעות מותאמות.
דרישות מוקדמות
לפני שממשיכים, מגדירים את Google Mobile Ads SDK (Legacy).
תמיד כדאי לבצע בדיקות באמצעות מודעות בדיקה
כשאתם מפתחים ובודקים את האפליקציות, חשוב להשתמש במודעות בדיקה ולא במודעות פעילות.
הדרך הכי קלה לטעון מודעות לבדיקה היא להשתמש במזהה הייעודי של יחידת המודעות לבדיקה של מודעות מותאמות ב-Android:
/21775744923/example/native
הוא הוגדר במיוחד כדי להחזיר מודעות בדיקה לכל בקשה, ואתם יכולים להשתמש בו באפליקציות שלכם בזמן התכנות, הבדיקה וניפוי הבאגים. רק חשוב להקפיד להחליף אותו במזהה יחידת המודעות שלכם לפני פרסום האפליקציה.
פרטים על Google Mobile Ads SDK (Legacy) מודעות בדיקה זמינים במאמר הפעלת מודעות בדיקה.
טעינת מודעות
מודעות מותאמות נטענות באמצעות המחלקה AdLoader, שיש לה מחלקה משלה, Builder, שמאפשרת להתאים אותה אישית במהלך היצירה. כשמוסיפים מאזינים ל-AdLoader בזמן הפיתוח, האפליקציה מציינת אילו סוגים של מודעות מותאמות היא מוכנה לקבל. אחר כך, AdLoader מבקש רק את הסוגים האלה.
יצירת AdLoader
הקוד הבא מדגים איך ליצור AdLoader שיכול לטעון מודעות מותאמות:
Java
Kotlin
מחליפים את AD_UNIT_ID במזהה מכשיר הבדיקה.
ה-method forNativeAd() אחראית להכנת ה-AdLoader לפורמט NativeAd.
כשהמודעה נטענת בהצלחה, מתבצעת קריאה ל-method onNativeAdLoaded() של אובייקט ה-listener.
הגדרת AdListener עם AdLoader (אופציונלי)
כשיוצרים את ה-AdLoader, הפונקציה withAdListener מגדירה AdListener ל-loader. ה-method מקבלת AdListener כפרמטר היחיד שלה, שמקבל קריאות חוזרות (callbacks) מ-AdLoader כשמתרחשים אירועים במחזור החיים של המודעה:
Java
adLoaderBuilder.withAdListener(
// Override AdListener callbacks here.
new AdListener() {});
Kotlin
adLoaderBuilder.withAdListener(
// Override AdListener callbacks here.
object : AdListener() {}
)
בקשה להצגת מודעות
אחרי שמסיימים ליצור AdLoader, אפשר להשתמש בה כדי לבקש מודעות.
יש שתי שיטות זמינות: loadAd() ו-loadAds().
loadAd()
השיטה הזו שולחת בקשה למודעה אחת.
Java
adLoader.loadAd(new AdManagerAdRequest.Builder().build());
Kotlin
adLoader.loadAd(AdManagerAdRequest.Builder().build())
loadAds()
השיטה הזו שולחת בקשה לכמה מודעות (עד חמש):
Java
// Load three native ads.
adLoader.loadAds(new AdManagerAdRequest.Builder().build(), 3);
Kotlin
// Load three native ads.
adLoader.loadAds(AdManagerAdRequest.Builder().build(), 3)
בשתי השיטות, הפרמטר הראשון הוא אובייקט AdManagerAdRequest. זהו אותו מחלקהAdManagerAdRequest שמשמשת מודעות באנר ומודעות מעברון, ואפשר להשתמש בשיטות של המחלקה AdManagerAdRequest כדי להוסיף מידע על טירגוט, בדיוק כמו בפורמטים אחרים של מודעות.
טעינת כמה מודעות (אופציונלי)
ה-method loadAds() מקבלת פרמטר נוסף: מספר המודעות שה-SDK צריך לנסות לטעון לבקשה. המספר הזה מוגבל לחמש, ואין ערובה לכך שה-SDK יחזיר את המספר המדויק של המודעות שנדרשו.
כל מודעות Google שיוחזרו יהיו שונות זו מזו, אבל לא מובטח שמודעות ממלאי שטחי פרסום שמור או מקונים מצד שלישי יהיו ייחודיות.
אל תשתמשו ב-loadAds() אם אתם משתמשים בתהליך בחירת הרשת, כי בקשות לכמה מודעות מותאמות לא פועלות במזהים של יחידות מודעות שהוגדרו לתהליך בחירת הרשת.
התקשרות חזרה
אחרי קריאה ל-loadAd(), מתבצעת קריאה חוזרת (callback) אחת לשיטות המאזין שהוגדרו קודם כדי להעביר את אובייקט המודעה המותאמת או לדווח על שגיאה.
שחרור משאבים
חשוב להשתמש בשיטה destroy() במודעות מותאמות שנטענו. הפעולה הזו משחררת משאבים בשימוש ומונעת דליפות זיכרון.
מוודאים שכל ההפניות ל-NativeAd מושמדות בשיטה
onDestroy() של הפעילות.
ב-callback של onNativeAdLoaded, חשוב להשמיד את כל המודעות המותאמות הקיימות שההפניה אליהן תוסר.
בדיקה חשובה נוספת היא אם הפעילות נהרסה, ואם כן, צריך להפעיל את destroy() במודעה שהוחזרה ולחזור מיד:
Java
nativeAd.destroy();
Kotlin
nativeAd.destroy()
שיטות מומלצות
חשוב לפעול לפי הכללים הבאים כשמטמיעים מודעות.
באפליקציות שבהן נעשה שימוש במודעות מותאמות ברשימה, צריך לבצע אחסון במטמון מראש של רשימת המודעות.
כששומרים מודעות במטמון מראש, צריך לנקות את המטמון ולטעון מחדש אחרי שעה.
- אל תפעילו את
loadAd()ב-AdLoaderעד שהבקשה הראשונה תסיים להיטען.
הגבילו את השמירה במטמון של מודעות מותאמות רק למה שצריך. לדוגמה, כשמבצעים שמירה מראש במטמון, צריך לשמור במטמון רק את המודעות שמופיעות מיד על המסך. למודעות מותאמות יש הזיכרון שבשימוש גדול, ושמירת מודעות מותאמות במטמון בלי להסיר אותן גורמת לשימוש מוגזם בזיכרון.
להשמיד מודעות מותאמות כשהן כבר לא בשימוש.
שיפור מהירות באמצעות חומרה במודעות וידאו
כדי שמודעות וידאו יוצגו בהצלחה בתצוגות של מודעות מותאמות, צריך להפעיל האצת חומרה.
שיפור מהירות באמצעות חומרה מופעל כברירת מחדל, אבל באפליקציות מסוימות אפשר להשבית אותה. אם זה המצב באפליקציה שלכם, מומלץ להפעיל שיפור מהירות באמצעות חומרה במחלקות Activity שמשתמשות במודעות.
הפעלת שיפור המהירות באמצעות חומרה
אם האפליקציה לא פועלת כמו שצריך כששיפור המהירות באמצעות חומרה מופעל באופן גלובלי, אפשר לשלוט בו גם לפעילויות ספציפיות. כדי להפעיל או להשבית את שיפור המהירות באמצעות חומרה, משתמשים במאפיין android:hardwareAccelerated ברכיבים <application> ו-<activity> ב-AndroidManifest.xml. בדוגמה הבאה, שיפור המהירות באמצעות חומרה מופעל בכל האפליקציה, אבל מושבת בפעילות אחת:
<application android:hardwareAccelerated="true">
<!-- For activities that use ads, hardwareAcceleration should be true. -->
<activity android:hardwareAccelerated="true" />
<!-- For activities that don't use ads, hardwareAcceleration can be false. -->
<activity android:hardwareAccelerated="false" />
</application>
מידע נוסף על אפשרויות השליטה בשיפור מהירות באמצעות חומרה מופיע במדריך לשיפור מהירות באמצעות חומרה. שימו לב: אי אפשר להפעיל שיפור מהירות באמצעות חומרה בתצוגות של מודעות בודדות אם ה-Activity מושבת, ולכן צריך להפעיל את שיפור המהירות באמצעות חומרה ב-Activity עצמו.
הצגת המודעה
אחרי שטענתם מודעה, כל מה שנותר הוא להציג אותה למשתמשים. מידע נוסף זמין במאמרים מודעה מותאמת מסוג Advanced או מודעות מותאמות במסך מלא.