סקירה כללית של משאבי האפליקציה

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

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

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

סוגי משאבים של קבוצות

ממקמים כל סוג של משאב בספריית משנה ספציפית של הספרייה res/ של הפרויקט. לדוגמה, היררכיית הקבצים של פרויקט פשוט:

MyProject/
    src/
        MyActivity.java
    res/
        drawable/
            graphic.png
        layout/
            main.xml
            info.xml
        mipmap/
            icon.png
        values/
            strings.xml

הספרייה res/ מכילה את כל המשאבים בספריות המשנה שלה: משאב תמונה, שני משאבי פריסה, ספרייה mipmap/ לאיקונים של מרכז האפליקציות וקובץ משאב למחרוזת. שמות ספריות המשאבים חשובים ומתוארים בטבלה 1.

הערה: מידע נוסף על השימוש בתיקיות mipmap זמין במאמר הוספת סמלי אפליקציות לספריות mipmap.

טבלה 1. ספריות משאבים שנתמכות בתוך ספריית הפרויקט res/.

ספרייה	סוג המשאב
animator/	קובצי XML שמגדירים אנימציות של מאפיינים.
anim/	קובצי XML שמגדירים אנימציות Tween. אפשר לשמור בספרייה הזו גם אנימציות של מאפיינים, אבל עדיף לשמור אותן בספרייה animator/ כדי להבחין בין שני הסוגים.
color/	קובצי XML שמגדירים רשימת צבעים של מצב. מידע נוסף זמין במאמר בנושא משאב של רשימת מצבי צבע.
drawable/	קבצי מפת סיביות (PNG, .9.png, JPG או GIF) או קובצי XML שעברו קומפילציה לסוגי משנה של פריט גרפי שניתן להזזה: קובצי מפת סיביות תשעה תיקונים (מפות סיביות שניתנות לשינוי גודל) רשימות של מדינות צורות נכסי אנימציה מסוג drawable רכיבים אחרים שאפשר לצייר מידע נוסף זמין במאמר משאבים מסוג Drawable.
mipmap/	קבצים מסוג Drawable לצפיפויות שונות של סמלי מרכז האפליקציות. מידע נוסף על ניהול סמלים של מרכז האפליקציות באמצעות תיקיות mipmap/ זמין במאמר הוספת סמלי אפליקציות לתיקיות mipmap.
layout/	קובצי XML שמגדירים פריסה של ממשק משתמש. מידע נוסף זמין במאמר בנושא משאב פריסה.
menu/	קובצי XML שמגדירים תפריטים של אפליקציות, כמו תפריט אפשרויות, תפריט הקשר או תפריט משנה. מידע נוסף מופיע במאמר משאב תפריט.
raw/	קבצים שרירותיים לשמירה בפורמט גולמי. כדי לפתוח את המשאבים האלה באמצעות InputStream, מתקשרים אל Resources.openRawResource() עם מזהה המשאב, שהוא R.raw.filename. עם זאת, אם אתם צריכים גישה לשמות הקבצים המקוריים ולהיררכיית הקבצים, כדאי לשמור את המשאבים בספרייה assets/ במקום בספרייה res/raw/. לקבצים ב-assets/ לא מוקצה מזהה משאב, ולכן אפשר לקרוא אותם רק באמצעות AssetManager.
values/	קובצי XML שמכילים ערכים פשוטים, כמו מחרוזות, מספרים שלמים וצבעים. לעומת זאת, קובצי משאבים בפורמט XML בספריות משנה אחרות של res/ מגדירים משאב יחיד על סמך שם קובץ ה-XML, וקבצים בספרייה values/ מתארים כמה משאבים. במקרה של קובץ בספרייה הזו, כל צאצא של רכיב <resources> מגדיר משאב יחיד. לדוגמה, רכיב <string> יוצר משאב R.string, ורכיב <color> יוצר משאב R.color. כל משאב מוגדר באמצעות רכיב XML משלו, כך שאפשר לתת לקובץ כל שם שרוצים ולכלול בו סוגים שונים של משאבים. עם זאת, לשם הבהרה, כדאי להציב סוגים ייחודיים של משאבים בקבצים שונים. לדוגמה, אלה כמה מוסכמות לשמות קבצים של משאבים שאפשר ליצור בספרייה הזו: ‫arrays.xml למערכי משאבים (מערכים מוקלדים) colors.xml לגבי ערכי צבע ‫dimens.xml לערכי מאפיינים ‫strings.xml עבור ערכי String styles.xml לסגנונות מידע נוסף זמין במאמרים משאבי מחרוזות, משאבי סגנון וסוגים נוספים של משאבים.
xml/	קבצי XML שרירותיים שאפשר לקרוא בזמן הריצה על ידי קריאה ל-Resources.getXML(). צריך לשמור כאן קובצי תצורה שונים מסוג XML, כמו הגדרת חיפוש.
font/	קובצי גופנים עם סיומות כמו TTF,‏ OTF או TTC, או קובצי XML שכוללים אלמנט <font-family>. מידע נוסף על גופנים כמשאבים זמין במאמר הוספת גופן כמשאב XML.

זהירות: אסור לשמור קובצי משאבים ישירות בתוך הספרייה res/. היא גורמת לשגיאת קומפילציה.

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

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

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

לספק משאבים חלופיים

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

איור 1. שני מכשירים שמשתמשים במשאבי פריסה שונים על סמך גודל המסך.

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

1. יוצרים ספרייה חדשה ב-res/ בשם <resources_name>-<qualifier>.
   • ‫<resources_name> הוא שם הספרייה של משאבי ברירת המחדל התואמים (מוגדר בטבלה 1).
   • ‫<qualifier> הוא שם שמציין הגדרה ספציפית שבה יש להשתמש במשאבים האלה (מוגדר בטבלה 2).

   אפשר לצרף יותר מ-<qualifier> אחד. מפרידים בין כל אחד מהם באמצעות מקף.

   זהירות: כשמוסיפים כמה מסננים, צריך להציב אותם באותו סדר שבו הם מופיעים בטבלה 2. אם המאפיינים הנוספים לא מסודרים נכון, המערכת מתעלמת מהמשאבים.

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

לדוגמה, אלה כמה משאבים שמוגדרים כברירת מחדל וכחלופה:

res/
    drawable/
        icon.png
        background.png
    drawable-hdpi/
        icon.png
        background.png

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

שימו לב: כשמגדירים משאב חלופי, צריך להגדיר את המשאב גם בהגדרת ברירת מחדל. אחרת, האפליקציה עלולה להיתקל בחריגות בזמן ריצה כשהמכשיר משנה את ההגדרה. לדוגמה, אם מוסיפים מחרוזת רק ל-values-en ולא ל-values, יכול להיות שהאפליקציה תיתקל בחריגה Resource Not Found כשהמשתמש ישנה את שפת המערכת שמוגדרת כברירת מחדל.

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

טבלה 2. שמות של מחרוזות להגדרת תצורה.

הגדרות אישיות	ערכי מגדיר	תיאור
קוד MCC וקוד MNC	דוגמאות: mcc310 mcc310-mnc004 mcc208-mnc00	קוד מדינה של רשת סלולרית (MCC), שאחריו יכול להופיע קוד הרשת שבה נמצא הנייד (MNC) מכרטיס ה-SIM במכשיר. לדוגמה, mcc310 היא ארה"ב בכל ספק, mcc310-mnc004 היא ארה"ב ב-Verizon, ו-mcc208-mnc00 היא צרפת ב-Orange. אם המכשיר משתמש בחיבור רדיו (כלומר, זה טלפון GSM), ערכי ה-MCC וה-MNC מגיעים מכרטיס ה-SIM. אפשר גם להשתמש רק ב-MCC, למשל כדי לכלול באפליקציה משאבים משפטיים שספציפיים למדינה. אם אתם צריכים לציין לפי שפה בלבד, אתם יכולים להשתמש במקום זאת במאפיין המסווג שפה, סקריפט (אופציונלי) ואזור (אופציונלי). אם אתם משתמשים במזהה MCC ובמספר MNC, עליכם לעשות זאת בזהירות ולבדוק שהם פועלים כמצופה. אפשר גם לראות את שדות ההגדרה mcc ו-mnc, שמציינים את קוד המדינה הנוכחי של רשת סלולרית ואת הקוד של הרשת, בהתאמה.
שפה, כתב (אופציונלי) ואזור (אופציונלי)	דוגמאות: en fr en-rUS fr-rFR fr-rCA b+en b+en+US b+es+419 b+zh+Hant b+sr+Latn+RS	השפה מוגדרת באמצעות קוד שפה בן שתי אותיות לפי תקן ISO 639-1, שאחריו יכול להופיע קוד אזור בן שתי אותיות לפי תקן ISO 3166-1-alpha-2 (לפני קוד האזור מופיע r באותיות קטנות). הקודים לא תלויי אותיות רישיות. הקידומת r משמשת להבחנה בין חלקי האזור. אי אפשר לציין רק אזור. ב-Android 7.0 (רמת API ‏24) נוספה תמיכה בתגי שפה מסוג BCP 47, שאפשר להשתמש בהם כדי לציין משאבים שספציפיים לשפה ולאזור. תג שפה מורכב מרצף של תגי משנה אחד או יותר, וכל אחד מהם מצמצם או משפר את טווח השפה שמזוהה על ידי התג הכולל. מידע נוסף על תגי שפה זמין במאמר תגים לזיהוי שפות. כדי להשתמש בתג שפה לפי BCP 47, צריך לשרשר את b+ ואת קוד השפה בן שתי האותיות ISO 639-1, ואפשר להוסיף אחריו תגי משנה נוספים שמופרדים באמצעות +. תג השפה יכול להשתנות במהלך השימוש באפליקציה אם המשתמשים משנים את השפה שלהם בהגדרות המערכת. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר טיפול בשינויים בהגדרות. מדריך מלא להתאמת האפליקציה לשפות אחרות זמין במאמר התאמת האפליקציה לשוק המקומי. אפשר גם לעיין ב-method‏ getLocales(), שמספק את רשימת הלוקאלים המוגדרת. הרשימה הזו כוללת את הלוקאל הראשי.
כיוון הפריסה	ldrtl ldltr	כיוון הפריסה של האפליקציה. ldrtl פירושו 'פריסה מימין לשמאל'. ‫ldltr פירושו 'כיוון הפריסה משמאל לימין', וזהו ערך ברירת המחדל המרומז. ההגדרה הזו יכולה לחול על כל משאב, כמו פריסות, משאבים שניתנים לציור או ערכים. לדוגמה, אם רוצים לספק פריסה ספציפית לשפה הערבית ופריסה כללית לכל שפה אחרת שמוצגת מימין לשמאל, כמו פרסית או עברית, אפשר להשתמש בספריות כמו אלה: res/   layout/     main.xml (פריסת ברירת המחדל)   layout-ar/     main.xml (פריסה ספציפית לערבית)   layout-ldrtl/     main.xml (כל שפה שנכתבת מימין לשמאל, חוץ מערבית, כי לפרמטר להגדרת שפה 'ar' יש עדיפות גבוהה יותר) הערה: כדי להפעיל תכונות של פריסה מימין לשמאל באפליקציה, צריך להגדיר את SupportsRtl ל-"true" ואת TargetSdkVersion ל-17 ומעלה. נוסף ברמת API‏ 17.
הרוחב הקטן ביותר	sw<N>dp דוגמאות: sw320dp sw600dp sw720dp וכו'.	המימד הקצר ביותר של אזור המסך שזמין לאפליקציה. באופן ספציפי, smallestWidth של חלון האפליקציה הוא המימד הקצר ביותר מבין הגובה והרוחב הזמינים של החלון. אפשר גם לחשוב על זה כעל 'הרוחב המינימלי האפשרי' של החלון. אפשר להשתמש במגביל הזה כדי להבטיח שרוחב האפליקציה יהיה לפחות <N> dps, כך שיהיה מספיק מקום לממשק המשתמש שלה. לדוגמה, אם הפריסה שלכם דורשת שהמימד הקטן ביותר של שטח המסך יהיה לפחות 600dp בכל זמן, אתם יכולים להשתמש במאפיין הזה כדי ליצור את משאבי הפריסה בספרייה res/layout-sw600dp/. המערכת משתמשת במשאבים האלה רק כשהמימד הקטן ביותר של המסך הזמין הוא לפחות 600dp, בלי קשר לשאלה אם הצד של 600dp הוא הגובה או הרוחב שנתפסים על ידי המשתמש. הרוחב הכי קטן יכול להשתנות אם משנים את הגודל של החלון, משנים את הרוחב או הגובה הזמינים, או משנים את המיקום שלו, מה שעשוי לשנות את השוליים הפנימיים של המערכת. השימוש ברוחב הקטן ביותר כדי לקבוע את הגודל הכללי של המסך הוא שימושי, כי הרוחב הוא לרוב הגורם המרכזי בתכנון פריסה. ממשק משתמש לרוב ניתן לגלילה אנכית, אבל יש לו מגבלות די קשיחות על המרחב המינימלי שהוא צריך אופקית. הרוחב הזמין הוא גם הגורם העיקרי שקובע אם להשתמש בפריסה של חלונית אחת בטלפונים ניידים או בפריסה של כמה חלוניות בטאבלטים. לכן, סביר להניח שהכי חשוב לכם לדעת מה הרוחב המינימלי האפשרי בכל מכשיר. הרוחב הקטן ביותר של מכשיר לוקח בחשבון את קישוטי המסך ואת ממשק המשתמש של המערכת. לדוגמה, אם במכשיר יש רכיבי ממשק משתמש קבועים במסך שתופסים מקום לאורך הציר של הרוחב הקטן ביותר, המערכת תגדיר את הרוחב הקטן ביותר כקטן יותר מגודל המסך בפועל, כי אלה פיקסלים במסך שלא זמינים לממשק המשתמש שלכם. כמה ערכים שאפשר להשתמש בהם כאן לגדלים נפוצים של מסכים: ‫320, למכשירים עם הגדרות מסך כמו: ‫240x320 ldpi (טלפון QVGA) ‫320x480‏ mdpi (טלפון נייד) ‫‎480x800 hdpi (מכשיר נייד עם צפיפות גבוהה) ‫480, למסכים כמו 480x800 mdpi (טאבלט/טלפון נייד) ‫600, למסכים כמו 600x1024 mdpi (טאבלט בגודל 7 אינץ') ‫720, למסכים כמו mdpi‏ 720x1280 (טאבלט בגודל 10 אינץ') אם האפליקציה מספקת כמה ספריות משאבים עם ערכים שונים של מסווג smallestWidth, המערכת משתמשת בספרייה שהערך שלה הכי קרוב לערך של smallestWidth במכשיר (בלי לחרוג ממנו). נוסף ברמת API‏ 13. אפשר גם לעיין במאפיין android:requiresSmallestWidthDp, שמצהיר על smallestWidth המינימלית שאיתה האפליקציה תואמת, ובשדה ההגדרה smallestScreenWidthDp, שמכיל את הערך smallestWidth של המכשיר. מידע נוסף על עיצוב למסכים שונים באמצעות המסנן הזה זמין במאמר בנושא עיצוב רספונסיבי/אדפטיבי באמצעות תצוגות.
רוחב וגובה זמינים	w<N>dp h<N>dp דוגמאות: w720dp w1024dp h720dp h1024dp וכו'.	המאפיין הזה מציין את הרוחב או הגובה המינימליים של המסך (בdp יחידות שמוגדרות על ידי הערך <N>) שבהם נעשה שימוש במשאב. ערכי ההגדרה האלה מושווים לרוחב ולגובה הנוכחיים של המסך כשהכיוון של המכשיר משתנה בין תצוגה לאורך ולרוחב, כשהמכשיר מתקפל או נפתח, או כשהמערכת נכנסת למצב ריבוי חלונות או יוצאת ממנו. במצב ריבוי חלונות, הערכים משקפים את הרוחב והגובה של החלון שמכיל את האפליקציה, ולא את הרוחב והגובה של מסך המכשיר. באופן דומה, לגבי פעילויות מוטמעות, הערכים מתייחסים לרוחב ולגובה של הפעילויות הספציפיות, ולא לרוחב ולגובה של המסך. מידע נוסף זמין במאמר בנושא הטמעת פעילות. הרוחב והגובה הזמינים שימושיים לעיתים קרובות כדי לקבוע אם להשתמש בפריסה מרובת חלונות, כי גם בטאבלט לרוב לא רוצים את אותה פריסה מרובת חלונות עבור מצב אנכי כמו עבור מצב אופקי. לכן, אפשר להשתמש בהם כדי לציין את הרוחב ו/או הגובה המינימליים שנדרשים לפריסה, במקום להשתמש יחד במאפיינים של גודל המסך והכיוון. אם האפליקציה מספקת כמה ספריות משאבים עם ערכים שונים לתצורות האלה, המערכת משתמשת בספרייה שהערך שלה הכי קרוב לרוחב המסך הנוכחי של המכשיר (בלי לחרוג ממנו). הערך הכי קרוב ל- נקבע על ידי הוספת ההבדלים בין רוחב המסך בפועל לבין הרוחב שצוין, להבדל בין גובה המסך בפועל לבין הגובה שצוין. אם לא צוינו גובה ורוחב, הערך הוא 0. הערכים לא כוללים את האזור שמוקצה לשוליים פנימיים של חלון, ולכן אם במכשיר יש רכיבים קבועים בממשק המשתמש בקצוות המסך, ערכי הרוחב והגובה קטנים יותר מהמידות האמיתיות של המסך, גם כשהאפליקציה מוצגת מקצה לקצה באמצעות Window.setDecorFitsSystemWindows או WindowCompat.setDecorFitsSystemWindows. קישוטים מסוימים של מסך אנכי שלא קבועים (כמו סרגל הסטטוס של הטלפון שאפשר להסתיר אותו כשמוצג מסך מלא) לא נכללים כאן, וגם לא קישוטי חלונות כמו סרגל הכותרת או סרגל הפעולות. לכן, האפליקציות צריכות להיות מוכנות להתמודד עם שטח קטן יותר ממה שהן מציינות. הערה: המערכת בוחרת את המשאב שתואם גם לרוחב וגם לגובה. לכן, עדיף להשתמש במשאב שמציין את שניהם מאשר במשאב שמציין רק אחד מהם. לדוגמה, אם הרוחב של המסך בפועל הוא 720dp והגובה הוא 1280dp, ומשאב אחד מוגדר כ-w720dp ומשאב אחר מוגדר כ-w700dp-h1200dp, המשאב השני ייבחר למרות שהראשון הוא התאמה מדויקת למה שהוא מציין. נוסף ברמת API‏ 13. אפשר גם לראות את שדות ההגדרה screenWidthDp וscreenHeightDp שמכילים את הרוחב והגובה הנוכחיים של המסך. מידע נוסף על עיצוב למסכים שונים באמצעות התנאי הזה זמין במאמר בנושא עיצוב רספונסיבי/אדפטיבי באמצעות תצוגות.
גודל המסך	small normal large xlarge	‫small: מסכים בגודל דומה למסך QVGA עם צפיפות פיקסלים נמוכה. הגודל המינימלי של הפריסה למסך קטן הוא בערך ‎320x426 יחידות dp. דוגמאות: QVGA בצפיפות נמוכה ו-VGA בצפיפות גבוהה. normal: מסכים בגודל דומה למסך HVGA בצפיפות בינונית. גודל הפריסה המינימלי למסך רגיל הוא בערך 320x470 יחידות dp. דוגמאות למסכים כאלה הן WQVGA בצפיפות נמוכה, HVGA בצפיפות בינונית ו-WVGA בצפיפות גבוהה. ‫large: מסכים שהגודל שלהם דומה לגודל של מסך VGA עם צפיפות בינונית. גודל הפריסה המינימלי למסך גדול הוא בערך 480x640 יחידות dp. דוגמאות הן מסכי VGA ו-WVGA בצפיפות בינונית. ‫xlarge: מסכים גדולים משמעותית ממסך HVGA רגיל בצפיפות בינונית. הגודל המינימלי של הפריסה למסך גדול במיוחד הוא בערך 720x960 יחידות dp. ברוב המקרים, מכשירים עם מסכים גדולים במיוחד הם גדולים מדי כדי לשאת אותם בכיס, וסביר להניח שמדובר במכשירים בסגנון טאבלט. נוסף ברמת API‏ 9. הערה: שימוש במגדיר גודל לא אומר שהמשאבים מיועדים רק למסכים בגודל הזה. אם לא תספקו משאבים חלופיים עם מסננים שתואמים טוב יותר להגדרת המכשיר הנוכחית, המערכת תוכל להשתמש במשאבים שהם ההתאמה הטובה ביותר. זהירות: אם כל המשאבים משתמשים במגדיר גודל שהוא גדול יותר מהמסך הנוכחי, המערכת לא משתמשת בהם והאפליקציה קורסת בזמן הריצה. לדוגמה, זה קורה אם כל משאבי הפריסה מתויגים במגביל xlarge אבל למכשיר יש מסך בגודל רגיל. נוסף ברמת API‏ 4. אפשר גם לראות את שדה ההגדרה screenLayout שמציין אם המסך קטן, רגיל או גדול. מידע נוסף זמין במאמר סקירה כללית על תאימות המסך.
יחס הגובה-רוחב של המסך	long notlong	‫long: מסכים ארוכים, כמו WQVGA, ‏ WVGA, ‏ FWVGA ‫notlong: לא מסכים ארוכים, כמו QVGA,‏ HVGA ו-VGA נוסף ברמת API‏ 4. ההגדרה הזו מבוססת אך ורק על יחס הגובה-רוחב של המסך (מסך long רחב יותר). זה לא קשור לכיוון המסך. אפשר גם לראות את שדה ההגדרה screenLayout, שמציין אם המסך ארוך.
מסך עגול	round notround	‫round: מסכים עגולים, כמו מכשיר לביש עגול ‫notround: מסכים מלבניים, כמו טלפונים או טאבלטים נוסף ברמת API‏ 23. אפשר גם לעיין בשיטת ההגדרה של isScreenRound() כדי לדעת אם המסך עגול.
Wide Color Gamut	widecg nowidecg	‫widecg: מסכים עם מכלול רחב של צבעים, כמו Display P3 או AdobeRGB ‫nowidecg: מסכים עם מרחב צבעים צר כמו sRGB נוסף ברמת API‏ 26. אפשר גם לעיין בשיטת ההגדרה isScreenWideColorGamut() כדי לדעת אם המסך כולל מגוון רחב של צבעים.
טווח דינמי גבוה (HDR)	highdr lowdr	‫highdr: מסכים עם טווח דינמי גבוה ‫lowdr: תצוגה עם טווח דינמי נמוך או רגיל נוסף ברמת API‏ 26. אפשר גם לעיין בשיטת ההגדרה של isScreenHdr(), שבה מצוין אם המסך תומך ב-HDR.
כיוון המסך	port land	‫port: המכשיר מוצג בכיוון לאורך (אנכי) ‫land: המכשיר נמצא בכיוון לרוחב (אופקי) הערך הזה יכול להשתנות במהלך השימוש באפליקציה אם המשתמש מסובב את המסך. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר בנושא טיפול בשינויים בהגדרות. אפשר גם לראות את שדה ההגדרה orientation שמציין את הכיוון הנוכחי של המכשיר.
מצב ממשק המשתמש	car desk television appliance watch vrheadset	‫car: המכשיר מוצג במחבר לרכב ‫desk: המכשיר מוצג במעמד שולחני ‫television: המכשיר מוצג בטלוויזיה, ומספק חוויה של 'עשרה פיט' שבה ממשק המשתמש מוצג על מסך גדול שהמשתמש נמצא רחוק ממנו, והחוויה מבוססת בעיקר על אינטראקציה באמצעות מקשי החיצים או אמצעי ניווט אחרים שאינם מצביעים ‫appliance: המכשיר משמש כמכשיר ביתי, ללא מסך ‫watch: למכשיר יש תצוגה והוא נלבש על פרק כף היד ‫vrheadset: המכשיר מוצג במשקפי מציאות מדומה נוסף ברמת API‏ 8; טלוויזיה נוספה ב-API‏ 13; שעון נוסף ב-API‏ 20. מידע על האופן שבו האפליקציה יכולה להגיב כשמכניסים את המכשיר למעמד או מוציאים אותו ממנו זמין במאמר קביעה ומעקב של מצב העגינה והסוג שלה. הערך הזה יכול להשתנות במהלך השימוש באפליקציה אם המשתמש מניח את המכשיר במעמד. אפשר להפעיל או להשבית חלק מהמצבים האלה באמצעות UiModeManager. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר בנושא טיפול בשינויים בהגדרות.
מצב לילה	night notnight	‫night: בלילה ‫notnight: שעות היום נוסף ברמת API‏ 8. ההגדרה הזו יכולה להשתנות במהלך חיי האפליקציה אם מצב הלילה מוגדר למצב אוטומטי (ברירת מחדל). במקרה כזה, המצב משתנה בהתאם לשעה ביום. אפשר להפעיל או להשבית את המצב הזה באמצעות UiModeManager. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר בנושא טיפול בשינויים בהגדרות.
צפיפות פיקסלים במסך (dpi)	ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi nodpi tvdpi anydpi nnndpi	‫ldpi: מסכים עם צפיפות נמוכה; בערך ‎120 dpi. ‫mdpi: מסכים עם צפיפות בינונית (ב-HVGA מסורתי); בערך 160 dpi. ‫hdpi: מסכים עם צפיפות פיקסלים גבוהה; בערך 240 dpi. ‫xhdpi: מסכים עם צפיפות גבוהה במיוחד; בערך 320 dpi. נוסף ברמת API‏ 8. ‫xxhdpi: מסכים עם צפיפות גבוהה במיוחד; בערך 480 dpi. נוסף ברמת API‏ 16. ‫xxxhdpi: שימוש בצפיפות גבוהה במיוחד (רק בסמל של מרכז האפליקציות – ראו תמיכה בצפיפויות פיקסלים שונות); בערך 640 dpi. נוסף ברמת API‏ 18. ‫nodpi: משמש למשאבי מפת סיביות שלא רוצים לשנות את הגודל שלהם כדי להתאים לצפיפות הפיקסלים של המכשיר. ‫tvdpi: מסכים ברזולוציה שבין mdpi ל-hdpi; בערך ‎213 dpi. הקבוצה הזו לא נחשבת לקבוצת צפיפות 'ראשונית'. הוא מיועד בעיקר לטלוויזיות באיכות 720p, ורוב האפליקציות לא צריכות אותו. במסכי טלוויזיה של 1080p, משתמשים ב-xhdpi, ובמסכי טלוויזיה של 4K, משתמשים ב-xxxhdpi. נוסף ברמת API‏ 13. ‫anydpi: מתאים לכל ערכי הדחיסות של המסך וקודם למסננים אחרים. האפשרות הזו שימושית לפריטים גרפיים וקטוריים שניתנים לשרטוט. נוסף ברמת API‏ 21. ‫nnndpi: משמש לייצוג צפיפויות לא תקניות, כאשר nnn הוא מספר שלם חיובי של צפיפות המסך. ברוב המקרים לא משתמשים בזה. השימוש בדליים סטנדרטיים של צפיפות מפחית באופן משמעותי את התקורה של תמיכה בצפיפויות המסך השונות של המכשירים בשוק. יש יחס קנה מידה של 3:4:6:8:12:16 בין שש הצפיפויות העיקריות (אם מתעלמים מהצפיפות tvdpi). לכן, מפת סיביות בגודל 9x9 ב-ldpi היא בגודל 12x12 ב-mdpi, בגודל 18x18 ב-hdpi, בגודל 24x24 ב-xhdpi וכן הלאה. הערה: שימוש במגביל צפיפות לא אומר שהמשאבים מיועדים רק למסכים בצפיפות הזו. אם לא מספקים משאבים חלופיים עם מסננים שתואמים טוב יותר לתצורת המכשיר הנוכחית, המערכת משתמשת במשאבים שהם ההתאמה הטובה ביותר. מידע נוסף על טיפול בדחיסויות מסך שונות ועל האופן שבו מערכת Android עשויה לשנות את קנה המידה של מפות הביטים כדי להתאים לדחיסות הנוכחית זמין במאמר סקירה כללית על תאימות מסך.
סוג מסך המגע	notouch finger	‫notouch: למכשיר אין מסך מגע. ‫finger: למכשיר יש מסך מגע שמיועד לשימוש באמצעות אינטראקציה של האצבע של המשתמש. אפשר גם לעיין בשדה ההגדרה touchscreen, שמציין את סוג מסך המגע במכשיר.
זמינות המקלדת	keysexposed keyshidden keyssoft	‫keysexposed: במכשיר יש מקלדת זמינה. אם במכשיר מופעלת מקלדת וירטואלית (סביר להניח שכן), המקלדת הזו תשמש את המשתמש גם אם המקלדת הפיזית לא זמינה לו או אם למכשיר אין מקלדת פיזית. אם לא מסופקת מקלדת תוכנה או שהיא מושבתת, נעשה שימוש בהגדרה הזו רק כשמקלדת פיזית חשופה. ‫keyshidden: במכשיר יש מקלדת חומרה זמינה, אבל היא מוסתרת וגם במכשיר לא מופעלת מקלדת וירטואלית. ‫keyssoft: מקלדת וירטואלית מופעלת במכשיר, בין אם היא גלויה ובין אם לא. אם תספקו משאבי keysexposed אבל לא משאבי keyssoft, המערכת תשתמש במשאבי keysexposed בלי קשר לשאלה אם המקלדת מוצגת, כל עוד מופעלת במערכת מקלדת וירטואלית. הערך הזה יכול להשתנות במהלך השימוש באפליקציה אם המשתמש פותח מקלדת חומרה. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר בנושא טיפול בשינויים בהגדרות. אפשר גם לראות את שדות ההגדרה hardKeyboardHidden ו-keyboardHidden, שמציינים את הנראות של מקלדת חומרה ואת הנראות של כל סוג של מקלדת (כולל תוכנה), בהתאמה.
שיטת קלט הטקסט העיקרית	nokeys qwerty 12key	‫nokeys: למכשיר אין מקשי חומרה להזנת טקסט. ‫qwerty: למכשיר יש מקלדת QWERTY פיזית, בין אם היא גלויה למשתמש ובין אם לא. ‫12key: למכשיר יש מקלדת עם 12 מקשים, בין אם היא גלויה למשתמש ובין אם לא. אפשר גם לעיין בשדה ההגדרה keyboard, שבו מצוינת שיטת הזנת הטקסט העיקרית שזמינה.
זמינות מקשי הניווט	navexposed navhidden	‫navexposed: מקשי הניווט זמינים למשתמש. ‫navhidden: מקשי הניווט לא זמינים (למשל, אם המחשב נייד עם מכסה סגור). ההגדרה הזו יכולה להשתנות במהלך השימוש באפליקציה אם המשתמש חושף את מקשי הניווט. מידע על ההשפעה של השינוי הזה על האפליקציה במהלך זמן הריצה זמין במאמר בנושא טיפול בשינויים בהגדרות. אפשר גם לעיין בשדה navigationHidden הגדרה שמציין אם מקשי הניווט מוסתרים.
שיטת הניווט העיקרית שאינה מבוססת על מגע	nonav dpad trackball wheel	‫nonav: למכשיר אין אמצעי ניווט מלבד מסך המגע. ‫dpad: למכשיר יש לחצני חיצים (D-pad) לניווט. ‫trackball: למכשיר יש כדור עקיבה לניווט. ‫wheel: למכשיר יש גלגל או גלגלים לניווט (לא נפוץ). אפשר גם לעיין בשדה ההגדרה navigation, שבו מצוין סוג שיטת הניווט שזמינה.
גרסת פלטפורמה (רמת API)	דוגמאות: v3 v4 v7 וכו'.	רמת ה-API שנתמכת על ידי המכשיר. לדוגמה, v1 לרמת API‏ 1 (מכשירים עם Android 1.0 ומעלה) ו-v4 לרמת API‏ 4 (מכשירים עם Android 1.6 ומעלה). מידע נוסף על הערכים האלה זמין במאמר רמות Android API.

הערה: לא כל הגרסאות של Android תומכות בכל התנאים. שימוש במגדיר חדש מוסיף באופן מרומז את מגדיר גרסת הפלטפורמה, כדי שמכשירים ישנים יותר יוכלו להתעלם ממנו. לדוגמה, שימוש במאפיין w600dp כולל אוטומטית את המאפיין v13, כי המאפיין available-width היה חדש ברמת API 13. כדי להימנע מבעיות, תמיד כדאי לכלול קבוצה של משאבים שמוגדרים כברירת מחדל (קבוצת משאבים ללא מאפיינים). מידע נוסף זמין בקטע בנושא שימוש במשאבים כדי לספק את התאימות הטובה ביותר למכשירים.

כללים לשמות של מגדירים

אלה כמה כללים לגבי השימוש בשמות של מחרוזות להגדרת תצורה:

• אפשר לציין כמה מסננים לקבוצת משאבים אחת, ולהפריד ביניהם באמצעות מקפים. לדוגמה, drawable-en-rUS-land חל על מכשירים באנגלית אמריקאית בפריסה לרוחב.
• המסננים צריכים להיות בסדר שמופיע בטבלה 2.
  • שגוי: drawable-hdpi-port/
  • נכון: drawable-port-hdpi/
• אי אפשר להטמיע ספריות משאבים חלופיות בתוך ספריות אחרות. לדוגמה, אי אפשר להשתמש ב- res/drawable/drawable-en/.
• הערכים לא תלויי-רישיות. מהדר המשאבים ממיר את שמות הספריות לאותיות קטנות לפני העיבוד, כדי למנוע בעיות במערכות קבצים שלא מבחינות בין אותיות רישיות לאותיות קטנות. השימוש באותיות רישיות בשמות הוא רק כדי לשפר את הקריאות.
• המערכת תומכת רק בערך אחד לכל סוג של תנאי. לדוגמה, אם רוצים להשתמש באותם קבצים של drawable בספרד ובצרפת, אי אפשר ליצור ספרייה בשם drawable-es-fr/. במקום זאת, צריך שתי ספריות משאבים, כמו drawable-es/ ו-drawable-fr/, שמכילות את הקבצים המתאימים. עם זאת, לא צריך לשכפל את הקבצים בשני המיקומים. במקום זאת, אפשר ליצור כינוי למשאב, כמו שמתואר בקטע יצירת משאבי כינוי.

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

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

יצירת משאבים של כתובות אימייל חלופיות

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

הערה: לא לכל המשאבים יש מנגנון שמאפשר ליצור כינוי למשאב אחר. בפרט, התכונה הזו לא זמינה באנימציה, בתפריט, בנתוני RAW ובמשאבים אחרים שלא צוינו בספרייה xml/.

לדוגמה, נניח שיש לכם סמל אפליקציה, icon.png, ואתם צריכים גרסה ייחודית שלו ללוקאלים שונים. עם זאת, בשני לוקאלים, אנגלית קנדית וצרפתית קנדית, צריך להשתמש באותה גרסה. אין צורך להעתיק את אותה תמונה לספריית המשאבים גם עבור אנגלית קנדית וגם עבור צרפתית קנדית. במקום זאת, אפשר לשמור את התמונה שמשמשת לשניהם בכל שם חוץ מ icon.png, כמו icon_ca.png, ולשים אותה בספרייה res/drawable/ שמוגדרת כברירת מחדל. לאחר מכן יוצרים קובץ icon.xml ב-res/drawable-en-rCA/ וב-res/drawable-fr-rCA/ שמפנה למשאב icon_ca.png באמצעות הרכיב <bitmap>. כך אפשר לאחסן רק גרסה אחת של קובץ ה-PNG ושני קובצי XML קטנים שמפנים אליו. פרטים נוספים מופיעים בדוגמאות שבקטעים הבאים.

פריט גרפי שניתן להזזה

כדי ליצור כינוי לרכיב drawable קיים, משתמשים באלמנט <drawable>:

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <drawable name="icon">@drawable/icon_ca</drawable>
</resources>

אם שומרים את הקובץ הזה בפורמט icon.xml בספריית משאבים חלופית, כמו res/values-en-rCA/, הוא עובר קומפילציה למשאב שאפשר להתייחס אליו כאל R.drawable.icon, אבל הוא למעשה כינוי למשאב R.drawable.icon_ca, שנשמר ב-res/drawable/.

פריסה

כדי ליצור כינוי לפריסה קיימת, משתמשים ברכיב <include> שעטוף ב-<merge>:

<?xml version="1.0" encoding="utf-8"?>
<merge>
    <include layout="@layout/main_ltr"/>
</merge>

אם שומרים את הקובץ הזה בשם main.xml, הוא עובר קומפילציה למשאב שאפשר להפנות אליו בתור R.layout.main, אבל הוא בעצם כינוי למשאב R.layout.main_ltr.

מחרוזות וערכים פשוטים אחרים

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

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="hello">Hello</string>
    <string name="hi">@string/hello</string>
</resources>

המשאב R.string.hi הוא עכשיו כינוי ל-R.string.hello.

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

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <color name="red">#f00</color>
    <color name="highlight">@color/red</color>
</resources>

גישה למשאבי האפליקציה

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

כשמהדרים את האפליקציה, aapt יוצר את המחלקה R, שמכילה מזהי משאבים לכל המשאבים בספרייה res/. לכל סוג משאב יש מחלקת משנה R, כמו R.drawable לכל המשאבים שניתן לצייר. לכל משאב מהסוג הזה יש מספר שלם סטטי, למשל R.drawable.icon. המספר השלם הזה הוא מזהה המשאב שבו אפשר להשתמש כדי לאחזר את המשאב.

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

• סוג המשאב: כל משאב מקובץ לפי סוג, כמו string,‏ drawable ו-layout. מידע נוסף על הסוגים השונים זמין במאמר סקירה כללית על סוגי משאבים.
• שם המשאב, שהוא שם הקובץ ללא הסיומת או הערך במאפיין android:name של ה-XML, אם המשאב הוא ערך פשוט, כמו מחרוזת.

יש שתי דרכים לגשת למשאב:

• בקוד: שימוש במספר שלם סטטי ממחלקת משנה של המחלקה R, למשל:

  R.string.hello

  ‫string הוא סוג המשאב ו-hello הוא שם המשאב. יש הרבה ממשקי API של Android שיכולים לגשת למשאבים שלכם כשאתם מספקים מזהה משאב בפורמט הזה. מידע נוסף מופיע בקטע גישה למשאבים בקוד.

• ב-XML: באמצעות תחביר XML מיוחד שמתאים למזהה המשאב שהוגדר במחלקה R, למשל:

  @string/hello

  ‫string הוא סוג המשאב ו-hello הוא שם המשאב. אפשר להשתמש בתחביר הזה במשאב XML בכל מקום שבו צפוי ערך שאתם מספקים במשאב. מידע נוסף זמין בקטע גישה למשאבים מ-XML.

גישה למשאבים בקוד

אפשר להשתמש במשאב בקוד על ידי העברת מזהה המשאב כפרמטר של method. לדוגמה, אפשר להגדיר ImageView כדי להשתמש במשאב res/drawable/myimage.png באמצעות setImageResource():

Kotlin

val imageView = findViewById(R.id.myimageview) as ImageView
imageView.setImageResource(R.drawable.myimage)

Java

ImageView imageView = (ImageView) findViewById(R.id.myimageview);
imageView.setImageResource(R.drawable.myimage);

אפשר גם לאחזר משאבים בודדים באמצעות שיטות ב-Resources, שאפשר לקבל מופע שלהן באמצעות getResources().

תחביר

זה התחביר להפניה למשאב בקוד:

[<package_name>.]R.<resource_type>.<resource_name>

• ‫<package_name> הוא שם החבילה שבה נמצא המשאב (לא נדרש כשמפנים למשאבים מהחבילה שלכם).
• ‫<resource_type> הוא מחלקת המשנה R של סוג המשאב.
• ‫<resource_name> הוא שם הקובץ של המשאב ללא הסיומת או ערך המאפיין android:name ברכיב ה-XML, עבור ערכים פשוטים.

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

תרחישים לדוגמה

יש הרבה שיטות שמקבלות פרמטר של מזהה משאב, ואפשר לאחזר משאבים באמצעות שיטות ב-Resources. אפשר לקבל מופע של Resources באמצעות Context.getResources().

ריכזנו כאן כמה דוגמאות לגישה למשאבים בקוד:

Kotlin

// Load a background for the current screen from a drawable resource.
window.setBackgroundDrawableResource(R.drawable.my_background_image)

// Set the Activity title by getting a string from the Resources object, because
//  this method requires a CharSequence rather than a resource ID.
window.setTitle(resources.getText(R.string.main_title))

// Load a custom layout for the current screen.
setContentView(R.layout.main_screen)

// Set a slide in animation by getting an Animation from the Resources object.
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
        R.anim.hyperspace_in))

// Set the text on a TextView object using a resource ID.
val msgTextView = findViewById(R.id.msg) as TextView
msgTextView.setText(R.string.hello_message)

Java

// Load a background for the current screen from a drawable resource.
getWindow().setBackgroundDrawableResource(R.drawable.my_background_image) ;

// Set the Activity title by getting a string from the Resources object, because
//  this method requires a CharSequence rather than a resource ID.
getWindow().setTitle(getResources().getText(R.string.main_title));

// Load a custom layout for the current screen.
setContentView(R.layout.main_screen);

// Set a slide in animation by getting an Animation from the Resources object.
flipper.setInAnimation(AnimationUtils.loadAnimation(this,
        R.anim.hyperspace_in));

// Set the text on a TextView object using a resource ID.
TextView msgTextView = (TextView) findViewById(R.id.msg);
msgTextView.setText(R.string.hello_message);

זהירות: אל תשנו את הקובץ R.java באופן ידני. הוא נוצר על ידי הכלי aapt כשמבצעים קומפילציה של הפרויקט. בפעם הבאה שתבצעו קומפילציה, השינויים יוחלפו.

גישה למשאבים מ-XML

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

לדוגמה, אם מוסיפים Button לפריסה, צריך להשתמש במשאב מחרוזת לטקסט של הלחצן:

<Button
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:text="@string/submit" />

תחביר

התחביר להפניה למשאב במשאב XML:

@[<package_name>:]<resource_type>/<resource_name>

• ‫<package_name> הוא שם החבילה שבה נמצא המשאב (לא נדרש כשמפנים למשאבים מאותה חבילה).
• ‫<resource_type> הוא מחלקת המשנה של סוג המשאב.R
• ‫<resource_name> הוא שם הקובץ של המשאב ללא הסיומת או ערך המאפיין android:name ברכיב ה-XML, במקרה של ערכים פשוטים.

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

תרחישים לדוגמה

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

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <color name="opaque_red">#f00</color>
   <string name="hello">Hello!</string>
</resources>

אפשר להשתמש במקורות המידע האלה בקובץ הפריסה הבא כדי להגדיר את צבע הטקסט ואת מחרוזת הטקסט:

<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:textColor="@color/opaque_red"
    android:text="@string/hello" />

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

<?xml version="1.0" encoding="utf-8"?>
<EditText xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent"
    android:textColor="@android:color/secondary_text_dark"
    android:text="@string/hello" />

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

אפשר אפילו להשתמש במשאבים ב-XML כדי ליצור כתובות אימייל חלופיות. לדוגמה, אפשר ליצור פריט גרפי שניתן להזזה שהוא כינוי למשאב drawable אחר:

<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
    android:src="@drawable/other_drawable" />

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

מאפייני סגנון לדוגמה

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

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

?[<package_name>:][<resource_type>/]<resource_name>

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

<EditText id="text"
    android:layout_width="fill_parent"
    android:layout_height="wrap_content"
    android:textColor="?android:textColorSecondary"
    android:text="@string/hello_world" />

במקרה הזה, המאפיין android:textColor מציין את השם של מאפיין סגנון בעיצוב הנוכחי. מערכת Android משתמשת עכשיו בערך שמוגדר למאפיין הסגנון android:textColorSecondary בתור הערך של android:textColor בווידג'ט הזה. מכיוון שכלי משאבי המערכת יודע שצפוי משאב מאפיין בהקשר הזה, לא צריך לציין במפורש את הסוג, שהוא ?android:attr/textColorSecondary. אפשר להחריג את הסוג attr.

גישה לקבצים המקוריים

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

לקבצים שנשמרים בספרייה assets/ לא מוקצה מזהה משאב, ולכן אי אפשר להפנות אליהם דרך המחלקה R או ממשאבי XML. במקום זאת, אפשר לשלוח שאילתות לקבצים בספרייה assets/ כמו למערכת קבצים רגילה, ולקרוא נתונים גולמיים באמצעות AssetManager.

עם זאת, אם כל מה שאתם צריכים הוא היכולת לקרוא נתונים גולמיים (כמו קובץ וידאו או קובץ אודיו), אז צריך לשמור את הקובץ בספרייה res/raw/ ולקרוא זרם של בייטים באמצעות openRawResource().

גישה למשאבי הפלטפורמה

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

Kotlin

listAdapter = ArrayAdapter(this, android.R.layout.simple_list_item_1, myarray)

Java

setListAdapter(new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, myarray));

בדוגמה הזו, simple_list_item_1 הוא משאב פריסה שהוגדר על ידי הפלטפורמה לפריטים ב-ListView. אתם יכולים להשתמש בפריסה הזו במקום ליצור פריסה משלכם לפריטים ברשימה.

התאמה טובה יותר של משאבים למכשירים

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

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

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

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

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

לדוגמה, אם minSdkVersion מוגדר ל-4, ואתם מציינים את כל משאבי ה-drawable באמצעות מצב לילה (night או notnight, שנוספו ברמת API 8), מכשיר ברמת API 4 לא יכול לגשת למשאבי ה-drawable שלכם והאפליקציה קורסת. במקרה הזה, כדאי להגדיר את notnight כמשאבי ברירת המחדל, ולכן צריך להחריג את המאפיין הזה ולהוסיף את משאבי ה-drawable ל-drawable/ או ל-drawable-night/.

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

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

איך מערכת Android מוצאת את המשאב המתאים ביותר

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

drawable/
drawable-en/
drawable-fr-rCA/
drawable-en-port/
drawable-en-notouch-12key/
drawable-port-ldpi/
drawable-port-notouch-12key/

נניח שההגדרה של המכשיר היא:

הלוקאל = en-GB
התמצאות המסך = port
צפיפות הפיקסלים במסך = hdpi
סוג מסך המגע = notouch
שיטת הקלט העיקרית של הטקסט = 12key

מערכת Android משווה את תצורת המכשיר למשאבים החלופיים שזמינים, ובוחרת משאבי drawable מתוך drawable-en-port.

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

איור 2. תרשים זרימה שמראה איך מערכת Android מוצאת את המשאב שהכי מתאים.

1. הסרת קובצי משאבים שסותרים את תצורת המכשיר.

   הספרייה drawable-fr-rCA/ נמחקת כי היא סותרת את הלוקאל en-GB.

   drawable/
   drawable-en/
   drawable-fr-rCA/
   drawable-en-port/
   drawable-en-notouch-12key/
   drawable-port-ldpi/
   drawable-port-notouch-12key/
   

   יוצא מן הכלל: דחיסות הפיקסלים במסך היא הקריטריון היחיד שלא נפסל בגלל סתירה. למרות שדחיסות המסך של המכשיר היא hdpi,‏ drawable-port-ldpi/ לא מבוטל כי כל דחיסות המסך נחשבות להתאמה בשלב הזה. למידע נוסף, ראו סקירה כללית על תאימות מסך.

2. מחפשים ברשימה את התנאי הבא בסדר העדיפות (טבלה 2). (מתחילים עם קוד הקטגוריה של המוֹכר).
3. האם אחד ממאגרי המשאבים כולל את התנאי הזה?
   • אם לא, חוזרים לשלב השני ומסתכלים על התנאי הבא. בדוגמה הזו, התשובה היא 'לא' עד שמגיעים לפרמטר להגדרת שפה.
   • אם כן, ממשיכים לשלב 4.
4. מסירים ספריות של משאבים שלא כוללות את המסווג הזה. בדוגמה הזו, המערכת מסירה את כל הספריות שלא כוללות פרמטר להגדרת שפה:

   drawable/
   drawable-en/
   drawable-en-port/
   drawable-en-notouch-12key/
   drawable-port-ldpi/
   drawable-port-notouch-12key/
   

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

5. חוזרים על שלבים 2, 3 ו-4 עד שנשארת רק ספרייה אחת. בדוגמה הזו, כיוון המסך הוא המסנן הבא שיש לו התאמות. לכן, משאבים שלא מציינים כיוון מסך נפסלים:

   drawable-en/
   drawable-en-port/
   drawable-en-notouch-12key/
   

   הספרייה שנותרה היא drawable-en-port.

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

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

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

הערה: העדיפות של התנאי (בטבלה 2) חשובה יותר ממספר התנאים שתואמים בדיוק למכשיר. בדוגמה הקודמת, בשלב הרביעי, הבחירה האחרונה ברשימה כוללת שלושה מסננים שתואמים בדיוק למכשיר (הכיוון, סוג מסך המגע ושיטת הקלט), ואילו drawable-en כולל רק פרמטר אחד שתואם (שפה). עם זאת, לשפה יש עדיפות גבוהה יותר מאשר לשאר התנאים, ולכן המערכת תסיר את drawable-port-notouch-12key.