نظرة عامة على مراجع التطبيقات

والموارد هي الملفات الإضافية والمحتوى الثابت الذي تستخدمه التعليمات البرمجية الخاصة بك، مثل الصور النقطية وتعريفات التنسيق وسلاسل واجهة المستخدم وتعليمات الرسوم المتحركة والمزيد.

قم دائمًا بتصدير موارد التطبيق مثل الصور والسلاسل من التعليمات البرمجية الخاصة بك، حتى تتمكن من الحفاظ عليها بشكل مستقل. أيضًا، وفر موارد بديلة لتكوينات أجهزة معينة عن طريق تجميعها في أدلة موارد ذات اسم خاص. وفي وقت التشغيل، يستخدم 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 التي تحدد الرسوم المتحركة لأطفال ما قبل سن المراهقة. ويمكن أيضًا حفظ الرسوم المتحركة للخصائص في هذا الدليل، ولكن يُفضّل استخدام دليل animator/ للتمييز بين النوعين من خلال الرسوم المتحركة الخاصة بالخصائص.
color/ ملفات XML التي تحدد قائمة حالة من الألوان. لمزيد من المعلومات، راجع مورد قائمة حالات الألوان.
drawable/

ملفات الصور النقطية (PNG أو .9.png أو JPG أو GIF) أو XML التي يتم تجميعها في الأنواع الفرعية التالية للموارد القابلة للرسم:

  • ملفات الصور النقطية
  • تسع رقاقات (صور نقطية يمكن تغيير حجمها)
  • قوائم الولايات
  • الأشكال
  • صور متحركة قابلة للرسم
  • رسومات أخرى

لمزيد من المعلومات، يُرجى الاطّلاع على الموارد القابلة للرسم.

mipmap/ ملفات قابلة للرسم لكثافات رموز مشغّل التطبيقات لمزيد من المعلومات حول إدارة رموز مشغّل التطبيقات باستخدام مجلدات 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 خاص به، يمكنك تسمية الملف كما تريد ووضع أنواع موارد مختلفة في ملف واحد. ومع ذلك، للتوضيح، قد ترغب في وضع أنواع موارد فريدة في ملفات مختلفة. على سبيل المثال، إليك بعض اصطلاحات اسم الملف للموارد التي يمكنك إنشاؤها في هذا الدليل:

لمزيد من المعلومات، يُرجى الاطّلاع على موارد السلاسل ومورد الأنماط والمزيد من أنواع الموارد.

xml/ ملفات XML عشوائية يمكن قراءتها في وقت التشغيل من خلال طلب البيانات من Resources.getXML(). ويجب حفظ ملفات ضبط XML المتنوعة هنا، مثل إعدادات البحث.
font/ ملفات الخطوط التي تتضمّن إضافات، مثل ملفات TTF أو OTF أو TTC أو XML التي تتضمّن عنصر <font-family> للحصول على مزيد من المعلومات حول الخطوط كموارد، يمكنك الاطّلاع على إضافة خط كمورد XML.

تنبيه: يجب عدم حفظ ملفات الموارد مباشرةً داخل دليل res/. تسبب خطأ في برنامج التحويل البرمجي.

لمزيد من المعلومات حول الأنواع الفردية من الموارد، يُرجى الاطِّلاع على نظرة عامة على أنواع الموارد.

الموارد التي تحفظها في الأدلة الفرعية المحددة في الجدول 1 هي مواردك الافتراضية. أي أنّ هذه الموارد تحدد التصميم والمحتوى التلقائيَين لتطبيقك. ومع ذلك، قد تتطلّب الأنواع المختلفة من الأجهزة التي تعمل بنظام التشغيل Android أنواعًا مختلفة من الموارد.

على سبيل المثال، يمكنك توفير موارد تنسيق مختلفة للأجهزة التي تحتوي على شاشات أكبر من العادي للاستفادة من مساحة الشاشة الإضافية. يمكنك أيضًا توفير موارد سلسلة مختلفة تترجم النص في واجهة المستخدم لديك بناءً على إعداد لغة الجهاز. لتوفير هذه الموارد المختلفة لتهيئة الأجهزة المختلفة، يلزمك توفير موارد بديلة بالإضافة إلى مواردك الافتراضية.

توفير مصادر بديلة

توفِّر معظم التطبيقات موارد بديلة لدعم عمليات إعداد أجهزة محدَّدة. على سبيل المثال، يمكنك تضمين موارد بديلة قابلة للرسم لكثافات شاشات مختلفة وموارد سلاسل بديلة للغات المختلفة. أثناء وقت التشغيل، يرصد نظام 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. أسماء مؤهلات التهيئة.

الإعدادات قيم المؤهِّل الوصف
مركز عملائي وMNC أمثلة:
mcc310
mcc310-mnc004
mcc208-mnc00

تمثّل هذه السمة رمز البلد للجهاز الجوّال (مركز عملائي)، متبوعًا برمز شبكة الجوّال (MNC) من شريحة SIM في الجهاز. على سبيل المثال، يعرض mcc310 الولايات المتحدة على أي مشغّل شبكة جوّال، وmcc310-mnc004 في الولايات المتحدة على Verizon، وmcc208-mnc00 يعرض فرنسا على Orange.

إذا كان الجهاز يستخدم اتصال لاسلكي (أي أنه هاتف بروتوكول GSM)، يتم الحصول على قيم "مركز عملائي" و"MNC" من شريحة SIM.

يمكنك أيضًا استخدام "مركز عملائي" وحده، على سبيل المثال، لتضمين موارد قانونية خاصة بكل بلد في تطبيقك. وإذا كنت تريد التحديد استنادًا إلى اللغة فقط، استخدِم مؤهل اللغة والنص البرمجي (اختياري) والمنطقة (اختياري) بدلاً من ذلك. إذا كنت تستخدم مؤهِّل "مركز عملائي" و"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 (المستوى 24 من واجهة برمجة التطبيقات) إمكانية استخدام علامات اللغة BCP 47 التي يمكنك استخدامها لتأهيل الموارد الخاصة باللغة والمنطقة. تتكوّن علامة اللغة من تسلسل من علامة فرعية واحدة أو أكثر، وتعمل كل علامة منها على تحسين أو تضييق نطاق اللغة التي تحدّدها العلامة الشاملة. لمزيد من المعلومات عن علامات اللغة، راجِع علامات تحديد اللغات.

لاستخدام علامة لغة BCP 47، عليك إجراء سلسلة من b+ ورمز لغة ISO 639-1 مكوّن من حرفَين، ويمكنك اختيار إضافة علامات فرعية إضافية مفصولة بعلامة +.

يمكن أن تتغيّر علامة اللغة خلال فترة تشغيل تطبيقك في حال تغيير المستخدمين لغتهم في إعدادات النظام. للحصول على معلومات حول كيفية تأثير ذلك في تطبيقك أثناء وقت التشغيل، يُرجى الاطّلاع على تغييرات إعدادات الاسم المعرِّف.

للحصول على دليل كامل لأقلمة تطبيقك بلغات أخرى، يُرجى الاطّلاع على مقالة أقلمة تطبيقك.

يمكنك أيضًا مراجعة الطريقة getLocales() التي تقدّم قائمة محددة باللغات. تشمل هذه القائمة اللغة الأساسية.

اتجاه التصميم ldrtl
ldltr

اتجاه تنسيق تطبيقك. تعني ldrtl "layout-direction-right-to-اليسار" (تنسيق الاتجاه من اليمين إلى اليسار). ldltr تعني "layout-direction-left-to-right" والقيمة الضمنية التلقائية.

يمكن أن ينطبق هذا على أي مورد، مثل التخطيطات أو العناصر القابلة للرسم أو القيم.

على سبيل المثال، إذا أردت توفير تنسيق محدّد للّغة العربية وتنسيق عام لأي لغة أخرى من اليمين إلى اليسار، مثل الفارسية أو العبرية، يمكنك استخدام أدلّة على النحو التالي:

res/
  layout/
    main.xml (التنسيق التلقائي)
  layout-ar/
    main.xml (تنسيق خاص باللغة العربية)
  layout-ldrtl/
    main.xml (أي لغة تُكتب من اليمين إلى اليسار باستثناء العربية، لأنّ مؤهِّل اللغة "ar" يكون لها أولوية أعلى)

ملاحظة: لتفعيل ميزات التنسيق من اليمين إلى اليسار لتطبيقك، يجب ضبط SupportsRtl على "true" وضبط TargetSdkVersion على 17 أو أعلى.

تمت الإضافة في المستوى 17 من واجهة برمجة التطبيقات.

أصغر عرض sw<N>dp

أمثلة:
sw320dp
sw600dp
sw720dp
وما إلى ذلك.

أقصر بُعد لمساحة الشاشة المتاحة للتطبيق. على وجه التحديد، يُعدّ smallestWidth في نافذة التطبيق أقصر من الارتفاع والعرض المتاح للنافذة. يمكنك أيضًا اعتباره "أصغر عرض ممكن" للنافذة. يمكنك استخدام هذا المؤهل بحيث يتوفر لتطبيقك عرض <N> بكسل في الثانية على الأقل لواجهة المستخدم.

على سبيل المثال، إذا كان التنسيق يتطلّب في جميع الأوقات أن يكون أصغر بُعد له من مساحة الشاشة 600 وحدة بكسل مستقلة الكثافة (dp) على الأقل، يمكنك استخدام هذا المؤهِّل لإنشاء موارد التنسيق في دليل res/layout-sw600dp/. ولا يستخدم النظام هذه الموارد إلا عندما يكون أصغر بُعد للشاشة المتاحة هو 600 وحدة بكسل مستقلة الكثافة (dp) على الأقل، بغض النظر عمّا إذا كان الجانب 600 بكسل مستقل الكثافة هو الارتفاع أو العرض الذي يلاحظه المستخدم. يمكن أن يتغيّر أصغر عرض في حال تغيير حجم النافذة أو تغيير العرض أو الارتفاع المتاحَين أو تغيير موضعها، ما قد يؤدي إلى تغيير الأجزاء الداخلية للنظام.

من المفيد استخدام أصغر عرض لتحديد الحجم العام للشاشة، لأنّ العرض غالبًا ما يكون العامل الدافع في تصميم التصميم. غالبًا ما يتم تمرير واجهة المستخدم رأسيًا، ولكنها تفرض قيودًا صارمة إلى حدّ ما على الحدّ الأدنى للمساحة التي تحتاج إليها أفقيًا.

ويشكّل العرض المتاح أيضًا عاملاً رئيسيًا في تحديد ما إذا كان يجب استخدام تنسيق أحادي اللوحة مع الهواتف أو استخدام تصميم متعدد الأجزاء للأجهزة اللوحية. وبالتالي، ننصحك على الأرجح بشأن أصغر عرض ممكن على كل جهاز.

يأخذ أصغر عرض للجهاز في الاعتبار زخارف الشاشة وواجهة مستخدم النظام. على سبيل المثال، إذا كان الجهاز يحتوي على عناصر ثابتة لواجهة المستخدم على الشاشة تشغل المساحة على طول المحور الذي بأصغر عرض، سيُعلن النظام أنّ أصغر عرض يكون أصغر من حجم الشاشة الفعلي، لأنّ هذه الوحدات هي وحدات بكسل للشاشة غير المتوفرة لواجهة المستخدم.

بعض القيم التي قد تستخدمها هنا لأحجام الشاشات الشائعة:

  • 320، للأجهزة التي تتضمن إعدادات شاشة، مثل:
    • 240x320 ldpi (هاتف QVGA)
    • 320×480 mdpi (هاتف محمول)
    • دقة عالية تبلغ 480×800 (هاتف عالي الكثافة)
  • 480، للشاشات مثل 480×800 mdpi (الجهاز اللوحي/الهاتف المحمول)
  • 600، للشاشات مثل 600×1024 mdpi (الجهاز اللوحي مقاس 7 بوصة)
  • 720، للشاشات مثل 720×1280 mdpi (الجهاز اللوحي مقاس 10 بوصة)

عندما يوفّر تطبيقك أدلة موارد متعدّدة تتضمّن قيمًا مختلفة للمؤهِّل smallestWidth، يستخدم النظام الدليل الأقرب إلى smallestWidth الخاص بالجهاز (بدون تجاوزها).

تمت الإضافة في المستوى 13 من واجهة برمجة التطبيقات.

يمكنك أيضًا الاطّلاع على السمة android:requiresSmallestWidthDp، التي تحدّد الحد الأدنى من smallestWidth الذي يتوافق معه تطبيقك، بالإضافة إلى حقل الإعدادات smallestScreenWidthDp الذي يحتوي على قيمة smallestWidth للجهاز.

لمزيد من المعلومات عن التصميم للشاشات المختلفة باستخدام هذا المؤهِّل، يُرجى الاطّلاع على مقالة إتاحة أحجام الشاشات المختلفة.

العرض والارتفاع المتاحان w<N>dp
h<N>dp

أمثلة:
w720dp
w1024dp
h720dp
h1024dp
وما إلى ذلك.

يُحدِّد الحد الأدنى لعرض الشاشة أو ارتفاعها المتاح (بوحدات dp المحدّدة من خلال قيمة <N>) والذي يتم استخدام المورد عنده. تتم مقارنة قيم الإعداد هذه بعرض وارتفاع شاشة العرض الحاليين عندما يتغيّر اتجاه الجهاز بين الوضع العمودي والأفقي، أو عندما يتم طي الجهاز أو طيه، أو عندما يدخل النظام في وضع النوافذ المتعددة أو يخرج منه. في وضع النوافذ المتعددة، تعكس القيم عرض وارتفاع النافذة التي تحتوي على التطبيق، وليس عرض شاشة الجهاز وارتفاعها. وبالمثل، بالنسبة إلى الأنشطة المضمّنة، ترتبط القيم بعرض الأنشطة الفردية وارتفاعها، وليس بعرض الشاشة وارتفاعها. لمزيد من المعلومات، يمكنك الاطّلاع على تضمين الأنشطة.

غالبًا ما يكون العرض والارتفاع المتاحان مفيدَين في تحديد ما إذا كان يجب استخدام تنسيق متعدد الأجزاء، حتى في الأجهزة اللوحية، لا تحتاج غالبًا إلى استخدام تنسيق المضاعفات نفسه للاتجاه العمودي كما هو مطلوب في الوضع الأفقي. وبالتالي، يمكنك استخدام هذه الإعدادات لتحديد الحد الأدنى للعرض و/أو الارتفاع المطلوبَين للتنسيق، بدلاً من استخدام معرّفَي حجم الشاشة واتجاه الاتجاه معًا.

عندما يوفّر تطبيقك عدة أدلة موارد بقيم مختلفة لعمليات الضبط هذه، يستخدم النظام أقرب عرض (بدون تجاوز) عرض شاشة الجهاز الحالي. يتم تحديد الأقرب إلى من خلال إضافة الاختلافات بين عرض الشاشة الفعلي والعرض المحدّد إلى الفرق بين ارتفاع الشاشة الفعلي والارتفاع المحدّد، مع وجود قيمة 0 للارتفاعات والعرض غير المحدّدة.

تستبعد القيم المساحة التي تشغلها المساحات الداخلية للنافذة، لذلك إذا كان الجهاز يحتوي على عناصر ثابتة في واجهة المستخدم على حواف الشاشة، تكون قيم العرض والارتفاع أصغر من أبعاد الشاشة الحقيقية، حتى عند عرض التطبيق من الحافة إلى الحافة باستخدام Window.setDecorFitsSystemWindows أو WindowCompat.setDecorFitsSystemWindows.

ولا يتم أخذ زخارف الشاشات العمودية التي تكون غير ثابتة (مثل شريط حالة الهاتف الذي يمكن إخفاءه عند وضع ملء الشاشة) في الاعتبار هنا، كما لا يتم استخدام زخارف النوافذ مثل شريط العناوين أو شريط الإجراءات، لذلك يجب أن تكون التطبيقات جاهزة للتعامل مع مساحة أصغر إلى حدٍ ما مما تحدّده.

ملاحظة: يختار النظام المورد الذي يتطابق في كلّ من العرض والارتفاع. لذلك، يُفضَّل بشدة المورد الذي يحدّد كلا الخيارين على أحدهما الذي يحدّد أحدهما فقط. على سبيل المثال، إذا كان عرض الشاشة الفعلية 720 وحدة بكسل مستقلة الكثافة × 1280 بكسل مستقل الكثافة، وكان أحد الموارد مؤهَّلاً باستخدام w720 بكسل مستقل الكثافة ومورد آخر مؤهّلاً بالتنسيق w700dp-h1200dp، يتم اختيار المورد الثاني حتى لو كان الخيار الأول مطابقًا تمامًا لما تم تحديده.

تمت الإضافة في المستوى 13 من واجهة برمجة التطبيقات.

ويمكنك أيضًا الاطّلاع على حقلَي الإعداد screenWidthDp وscreenHeightDp، واللذين يتضمّنان عرض الشاشة وارتفاعها الحاليين.

لمزيد من المعلومات عن التصميم للشاشات المختلفة باستخدام هذا المؤهِّل، يُرجى الاطّلاع على مقالة إتاحة أحجام الشاشات المختلفة.

حجم الشاشة small
normal
large
xlarge
  • small: شاشات بحجم مماثل لشاشة QVGA منخفضة الكثافة. يبلغ الحدّ الأدنى لحجم التصميم لشاشة صغيرة حوالي 320x426 وحدة بكسل مستقلة الكثافة. ومن الأمثلة على ذلك كثافة منخفضة QVGA وVGA عالي الكثافة.
  • normal: الشاشات التي لها حجم مشابه لشاشة HVGA متوسطة الكثافة. الحد الأدنى لحجم التصميم للشاشة العادية هو وحدة بكسل مستقلة الكثافة (dp) تبلغ حوالي 320x470. ومن الأمثلة على هذه الشاشات، شاشات WQVGA منخفضة الكثافة، وكثافة متوسطة من HVGA، وكثافة عالية من WVGA.
  • large: الشاشات التي لها حجم مشابه لشاشة VGA متوسطة الكثافة. ويبلغ الحدّ الأدنى لحجم التصميم للشاشات الكبيرة 480x640 وحدة بكسل مستقلة الكثافة تقريبًا. ومن الأمثلة على ذلك شاشات VGA وWVGA متوسطة الكثافة.
  • xlarge: الشاشات التي تكون أكبر بكثير من شاشة HVGA التقليدية المتوسطة الكثافة يبلغ الحدّ الأدنى لحجم التصميم للشاشة الكبيرة جدًا 720x960 وحدة بكسل مستقلة الكثافة تقريبًا. وفي معظم الحالات، تكون الأجهزة ذات الشاشات الكبيرة جدًا كبيرة جدًا بحيث لا يمكن حملها في الجيب، وعلى الأرجح هي أجهزة مصمّمة على طراز الأجهزة اللوحية. تمت الإضافة في المستوى 9 من واجهة برمجة التطبيقات.

ملاحظة: لا يعني استخدام مؤهِّل الحجم أنّ الموارد مخصّصة فقط للشاشات بهذا الحجم. في حال عدم توفير موارد بديلة ذات مؤهلات تتطابق بشكل أفضل مع الإعدادات الحالية للجهاز، يمكن للنظام استخدام الموارد التي تكون أفضل مطابقة.

تنبيه: إذا كانت جميع مواردك تستخدم مؤهِّلاً للحجم أكبر من الشاشة الحالية، لن يستخدمها النظام، وسيتعطّل تطبيقك في وقت التشغيل. ويحدث ذلك على سبيل المثال إذا تم وضع علامة على جميع موارد التنسيق باستخدام المؤهِّل xlarge ولكن يحتوي الجهاز على شاشة ذات حجم عادي.

تمت الإضافة في المستوى 4 من واجهة برمجة التطبيقات.

يمكنك أيضًا الاطّلاع على حقل الإعداد screenLayout الذي يشير إلى ما إذا كانت الشاشة صغيرة أو عادية أو كبيرة.

لمزيد من المعلومات، يُرجى الاطّلاع على نظرة عامة على توافق الشاشة.

جانب الشاشة long
notlong
  • long: الشاشات الطويلة، مثل WQVGA وWVGA وFWVGA
  • notlong: ليست شاشات طويلة، مثل QVGA وHVGA وVGA

تمت الإضافة في المستوى 4 من واجهة برمجة التطبيقات.

يعتمد هذا تمامًا على نسبة العرض إلى الارتفاع للشاشة (تكون شاشة long أعرض). لا يتعلق هذا باتجاه الشاشة.

راجِع أيضًا حقل إعدادات screenLayout الذي يشير إلى ما إذا كانت الشاشة طويلة أم لا.

شاشة دائرية round
notround
  • round: شاشات مستديرة، مثل الجهاز المستدير القابل للارتداء
  • notround: الشاشات المستطيلة، مثل الهواتف أو الأجهزة اللوحية

تمت الإضافة في المستوى 23 من واجهة برمجة التطبيقات.

يمكنك أيضًا الاطّلاع على طريقة الإعداد isScreenRound() التي تشير إلى ما إذا كانت الشاشة مستديرة أم لا.

مجموعة ألوان واسعة widecg
nowidecg
  • widecg: الشاشات ذات مجموعة ألوان واسعة، مثل Display P3 أو AdobeRGB
  • nowidecg: يعرض مجموعة ألوان ضيقة، مثل sRGB

تمت الإضافة في المستوى 26 من واجهة برمجة التطبيقات.

يمكنك أيضًا الاطّلاع على طريقة الإعداد isScreenWideColorGamut() التي تشير إلى ما إذا كانت الشاشة تحتوي على مجموعة ألوان واسعة.

نطاق عالي الديناميكية (HDR) highdr
lowdr
  • highdr: شاشات ذات نطاق ديناميكي عالي
  • lowdr: شاشات ذات نطاق ديناميكي منخفض أو عادي

تمت الإضافة في المستوى 26 من واجهة برمجة التطبيقات.

يمكنك أيضًا الاطّلاع على طريقة الإعداد isScreenHdr() التي تحدّد ما إذا كانت الشاشة تتضمن إمكانيات النطاق العالي الديناميكية.

اتجاه الشاشة port
land
  • port: الجهاز في الاتجاه العمودي (العمودي)
  • land: الجهاز في الاتجاه الأفقي (أفقي)

يمكن أن يتغيّر هذا الوضع خلال فترة بقاء التطبيق في حال تدوير المستخدم للشاشة. للحصول على معلومات حول كيفية تأثير ذلك في تطبيقك أثناء وقت التشغيل، يُرجى الاطّلاع على التعامل مع التغييرات في الإعدادات.

يمكنك أيضًا الاطّلاع على حقل ضبط orientation الذي يشير إلى الاتجاه الحالي للجهاز

وضع واجهة المستخدم car
desk
television
appliance
watch
vrheadset
  • car: يتم عرض الجهاز في قاعدة إرساء السيارة.
  • desk: يتم عرض الجهاز في قاعدة إرساء مكتبية.
  • television: عرض الجهاز على التلفزيون
  • appliance: يعمل الجهاز كجهاز، بدون شاشة
  • watch: يعرض الجهاز شاشة ويتم ارتداؤه في المعصم.
  • vrheadset: يتم عرض الجهاز في سماعة رأس مزوّدة بتقنية الواقع الافتراضي.

تمت الإضافة في المستوى 8 من واجهة برمجة التطبيقات، وإضافة التلفزيون في المستوى 13 من واجهة برمجة التطبيقات، بينما تمت إضافة الساعة في الإصدار 20 من واجهة برمجة التطبيقات.

للحصول على معلومات حول كيفية استجابة تطبيقك عند إدخال الجهاز في قاعدة الإرساء أو إزالته منه، يمكنك الاطّلاع على المقالة تحديد حالة الإرساء ونوعها ومراقبتها.

ويمكن أن يتغيّر هذا الوضع خلال فترة تشغيل تطبيقك إذا وضع المستخدم الجهاز في قاعدة إرساء. يمكنك تفعيل بعض هذه الأوضاع أو إيقافها باستخدام UiModeManager. للحصول على معلومات حول كيفية تأثير ذلك في تطبيقك أثناء وقت التشغيل، يُرجى الاطّلاع على التعامل مع التغييرات في الإعدادات.

الوضع الليلي night
notnight
  • night: ليلاً
  • notnight: وقت اليوم

تمّت الإضافة في المستوى 8 من واجهة برمجة التطبيقات.

يمكن أن يتغير هذا أثناء تشغيل تطبيقك في حال إبقاء الوضع الليلي على الوضع التلقائي (التلقائي)، وفي هذه الحالة يتغير الوضع بناءً على الوقت. يمكنك تفعيل هذا الوضع أو إيقافه باستخدام UiModeManager. للحصول على معلومات حول كيفية تأثير ذلك في تطبيقك أثناء وقت التشغيل، يُرجى الاطّلاع على التعامل مع التغييرات في الإعدادات.

كثافة وحدات بكسل الشاشة (نقطة لكل بوصة) ldpi
mdpi
hdpi
xhdpi
xxhdpi
xxxhdpi
nodpi
tvdpi
anydpi
nnndpi
  • ldpi: شاشات منخفضة الكثافة؛ حوالي 120 نقطة لكل بوصة.
  • mdpi: متوسط الكثافة (على شاشات HVGA التقليدية)؛ حوالي 160 نقطة لكل بوصة.
  • hdpi: شاشات عالية الكثافة؛ حوالي 240 نقطة لكل بوصة.
  • xhdpi: شاشات عالية الكثافة؛ حوالي 320 نقطة لكل بوصة. تمت الإضافة في المستوى 8 من واجهة برمجة التطبيقات.
  • xxhdpi: شاشات عالية الكثافة جدًا؛ حوالي 480 نقطة لكل بوصة تمت الإضافة في المستوى 16 من واجهة برمجة التطبيقات.
  • xxxhdpi: استخدامات عالية الكثافة للغاية (رمز مشغّل التطبيقات فقط: راجِع إتاحة كثافات وحدات بكسل مختلفة) حوالي 640 نقطة لكل بوصة تمت الإضافة في المستوى 18 من واجهة برمجة التطبيقات.
  • nodpi: يُستخدم لموارد الصور النقطية التي لا تريد تعديل حجمها لمطابقة كثافة الجهاز.
  • tvdpi: شاشات في مكان ما بين mdpi وhdpi، وحوالي 213 نقطة لكل بوصة. ولا تُعتبَر هذه مجموعة كثافة "أساسية". فهو مُعدّ لأجهزة التلفزيون بدقة 720p، ومعظم التطبيقات لا تحتاج إليه. استخدِم "xhdpi" للوحات تلفزيون بدقة 1080p، أمّا بالنسبة إلى لوحات التلفزيون بدقة 4K، استخدِم "xxxhdpi". تمت الإضافة في المستوى 13 من واجهة برمجة التطبيقات.
  • anydpi: يطابق جميع كثافات الشاشة ويكون له الأولوية على المؤهلات الأخرى. وهذا مفيد للرسومات المتجهة القابلة للرسم. تمت الإضافة في المستوى 21 من واجهة برمجة التطبيقات.
  • nnndpi: تُستخدم هذه السمة للتعبير عن كثافات غير عادية، حيث يكون nnn قيمة كثافة شاشة لعدد صحيح موجب. ولا يتم استخدام هذه الطريقة في معظم الحالات. ويقلل استخدام مجموعات الكثافة العادية بشكل كبير من أعباء التوافق مع كثافات شاشات الأجهزة المختلفة في السوق.

هناك نسبة تحجيم 3:4:6:8:12:16 بين الكثافات الأساسية الست (مع تجاهل كثافة tvdpi). إذًا، الصورة النقطية 9×9 في 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 الذي يشير إلى توفّر أسلوب إدخال النص الأساسي.

إصدار النظام الأساسي (مستوى واجهة برمجة التطبيقات) أمثلة:
v3
v4
v7
وما إلى ذلك.

مستوى واجهة برمجة التطبيقات المتوافق مع الجهاز على سبيل المثال، v1 للمستوى 1 من واجهة برمجة التطبيقات 1 (الأجهزة التي تعمل بالإصدار 1.0 من نظام التشغيل Android أو الإصدارات الأحدث) وv4 للمستوى 4 لواجهة برمجة التطبيقات (الأجهزة التي تعمل بالإصدار 1.6 من نظام التشغيل Android أو الإصدارات الأحدث). لمزيد من المعلومات حول هذه القيم، يُرجى الاطّلاع على مستند مستويات واجهة برمجة تطبيقات Android.

ملاحظة: بعض إصدارات Android لا تتوافق مع بعض المؤهِّلات. يؤدي استخدام مؤهِّل جديد إلى إضافة مؤهِّل إصدار النظام الأساسي بشكل ضمني حتى تتمكّن الأجهزة القديمة من تجاهله. على سبيل المثال، يتضمّن استخدام مؤهِّل w600dp تلقائيًا مؤهِّل v13، لأنّ مؤهِّل العرض المتاح كان جديدًا في المستوى 13 من واجهة برمجة التطبيقات. لتجنّب حدوث أي مشاكل، أدرِج دائمًا مجموعة من الموارد التلقائية (مجموعة من الموارد بدون مؤهلات). لمزيد من المعلومات، يُرجى الاطّلاع على القسم حول توفير أفضل توافق مع الأجهزة مع الموارد.

قواعد اسم المؤهِّل

في ما يلي بعض القواعد المتعلّقة باستخدام أسماء مؤهِّلات الإعداد:

  • يمكنك تحديد مؤهِّلات متعددة لمجموعة واحدة من الموارد، مع الفصل بينها بشرطات. على سبيل المثال، يسري drawable-en-rUS-land على الأجهزة التي تستخدم اللغة الإنجليزية الأمريكية في الاتجاه الأفقي.
  • يجب أن تكون المؤهِّلات بالترتيب المذكور في الجدول 2.
    • خطأ: drawable-hdpi-port/
    • إجابة صحيحة: drawable-port-hdpi/
  • لا يمكن دمج أدلة الموارد البديلة. على سبيل المثال، لا يمكنك إضافة res/drawable/drawable-en/.
  • والقيم غير حساسة لحالة الأحرف. يحوِّل برنامج تجميع الموارد أسماء الأدلة إلى أحرف صغيرة قبل المعالجة لتجنّب المشاكل في أنظمة الملفات غير الحساسة لحالة الأحرف. والهدف من استخدام أي حرف كبير في الأسماء هو فقط توفير إمكانية القراءة.
  • يمكن استخدام قيمة واحدة فقط لكل نوع مؤهِّل. على سبيل المثال، إذا كنت تريد استخدام نفس الملفات القابلة للرسم لإسبانيا وفرنسا، لا يمكن أن يكون لديك دليل باسم drawable-es-fr/. بدلاً من ذلك، عليك البحث عن دليلَي موارد، مثل drawable-es/ وdrawable-fr/، واللذين يحتويان على الملفات المناسبة. ومع ذلك، لا يلزمك تكرار الملفات في كلا الموقعين. بدلاً من ذلك، يمكنك إنشاء عنوان بديل للبريد الإلكتروني لمورد معيّن، كما هو موضّح في قسم إنشاء موارد عناوين بديلة.

بعد حفظ الموارد البديلة في أدلة تحمل اسم هذه المؤهِّلات، يطبِّق Android تلقائيًا الموارد المتوفّرة في تطبيقك استنادًا إلى إعدادات الجهاز الحالية. في كل مرة يتم فيها طلب أحد الموارد، يبحث Android عن أدلة الموارد البديلة التي تحتوي على ملف المورد المطلوب، ثم يعثر على المورد الأفضل مطابقة.

إذا لم تكن هناك موارد بديلة تتطابق مع إعدادات جهاز معيّنة، سيستخدم Android الموارد التلقائية المقابلة لها، وهي مجموعة الموارد لنوع معيّن من الموارد لا تتضمّن مؤهِّلاً للتهيئة.

إنشاء موارد بديلة

عندما يكون لديك مورد ترغب في استخدامه لأكثر من إعداد واحد للجهاز ولكنك لا تريد تقديمه كمورد تلقائي، لن تحتاج إلى وضع المورد نفسه في أكثر من دليل موارد بديل واحد. بدلاً من ذلك، يمكنك إنشاء مورد بديل يعمل كاسم مستعار لمورد محفوظ في دليل الموارد الافتراضي.

ملاحظة: لا تقدم بعض الموارد آلية يمكنك من خلالها إنشاء اسم مستعار لمورد آخر. على وجه التحديد، لا توفّر الصور المتحركة والقائمة والموارد الأولية وغيرها من الموارد غير المحدّدة في دليل 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>:

<?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. لمزيد من المعلومات عن الأنواع المختلفة، يُرجى الاطِّلاع على نظرة عامة على أنواع الموارد.
  • اسم المورد، وهو اسم الملف الذي لا يشمل الامتداد أو القيمة في سمة XML android:name، إذا كان المورد عبارة عن قيمة بسيطة، مثل سلسلة.

هناك طريقتان للوصول إلى مورد:

  • في الرمز: باستخدام عدد صحيح ثابت من فئة فرعية من فئة R، مثل:
    R.string.hello

    string هو نوع المورد وhello هو اسم المورد. هناك العديد من واجهات برمجة تطبيقات Android التي يمكنها الوصول إلى مواردك عند توفير معرّف مورد بهذا التنسيق. لمزيد من المعلومات، يُرجى الاطّلاع على قسم الوصول إلى الموارد في الرموز البرمجية.

  • في XML: باستخدام بنية XML خاصة تتوافق مع معرّف المورد المحدّد في فئة R، مثل:
    @string/hello

    string هو نوع المورد وhello هو اسم المورد. يمكنك استخدام هذه البنية في مورد XML في أي مكان يُتوقع فيه توفير قيمة في مورد. لمزيد من المعلومات، يُرجى الاطّلاع على القسم الوصول إلى الموارد من XML.

الوصول إلى الموارد في الترميز

يمكنك استخدام مورد في الرمز من خلال تمرير رقم تعريف المورد باعتباره معلَمة طريقة. على سبيل المثال، يمكنك ضبط 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 لإنشاء أسماء مستعارة. على سبيل المثال، يمكنك إنشاء مورد قابل للرسم وهو اسم مستعار لمورد آخر قابل للرسم:

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

يبدو هذا تكرارًا، ولكنه قد يكون مفيدًا جدًا عند استخدام مورد بديل. لمزيد من المعلومات، يُرجى الاطّلاع على القسم حول إنشاء موارد بديلة.

سمات نمط المرجع

يتيح لك مورد سمة النمط الإشارة إلى قيمة سمة ما في المظهر المطبق حاليًا. تتيح لك الإشارة إلى سمة النمط تخصيص مظهر عناصر واجهة المستخدم من خلال تصميمها لمطابقة الأشكال القياسية التي يوفرها المظهر الحالي، بدلاً من تقديم قيمة ثابتة. تشير الإشارة إلى سمة النمط بشكل أساسي إلى، "استخدم النمط الذي تحدده هذه السمة في المظهر الحالي".

للإشارة إلى سمة نمط، تكون بنية الاسم مطابقة تقريبًا لتنسيق المورد العادي، ولكن بدلاً من الرمز "at" (@)، استخدِم علامة استفهام (?). ويكون جزء نوع المورد اختياريًا. إذًا، تكون الصيغة المرجعية على النحو التالي:

?[<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، يتعطّل التطبيق إذا لم توفّر موارد تلقائية لأنّه لا يمكنه استخدام الموارد المحدّدة في المؤهِّل الجديد.

على سبيل المثال، إذا تم ضبط minSdkVersion على 4، وكنت مؤهلاً لاستخدام جميع الموارد القابلة للرسم باستخدام الوضع الليلي (night أو notnight، اللذَين تمّت إضافتهما في المستوى 8 من واجهة برمجة التطبيقات)، لن يتمكّن جهازا من المستوى 4 من الوصول إلى الموارد القابلة للرسم والأعطال. في هذه الحالة، قد تريد في هذه الحالة أن يكون notnight هو الموارد التلقائية، لذا عليك استبعاد المؤهِّل ووضع الموارد القابلة للرسم إما drawable/ أو drawable-night/.

باختصار، لتوفير أفضل توافق مع الأجهزة، يجب دائمًا توفير موارد افتراضية للموارد التي يحتاجها تطبيقك لأداء بشكل صحيح. ثم أنشئ موارد بديلة لتكوينات أجهزة معينة باستخدام مؤهلات التهيئة.

هناك استثناء واحد لهذه القاعدة: إذا كانت قيمة minSdkVersion في تطبيقك تبلغ 4 أو أكثر، لا تحتاج إلى موارد تلقائية قابلة للرسم عند توفير موارد بديلة قابلة للرسم تتضمّن مؤهل كثافة الشاشة. حتى في حال عدم توفُّر الموارد التلقائية القابلة للرسم، يمكن لنظام Android العثور على أفضل مطابقة من بين كثافات الشاشات البديلة وقياس الصور النقطية حسب الضرورة. مع ذلك، للحصول على أفضل تجربة على جميع أنواع الأجهزة، وفِّر رسومات بديلة للرسم لكل أنواع الكثافة الثلاثة.

طريقة عثور Android على المورد الأفضل مطابقةً

عندما تطلب موردًا توفّر له بدائل، يختار نظام Android موردًا بديلاً لاستخدامه في وقت التشغيل، وذلك بناءً على إعدادات الجهاز الحالية. لتوضيح كيفية اختيار Android لمورد بديل، افترض أن الأدلة القابلة للرسم التالية تحتوي على إصدارات مختلفة من نفس الصور:

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-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. أزِل أدلة الموارد التي لا تتضمّن هذا المؤهِّل. في هذا المثال، يزيل النظام التالي جميع الأدلة التي لا تحتوي على مؤهل لغة:
    drawable/
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    drawable-port-ldpi/
    drawable-port-notouch-12key/
    

    استثناء: إذا كان المؤهِّل المعنيّ هو كثافة وحدات بكسل الشاشة، يحدِّد Android الخيار الذي يتطابق إلى حدّ كبير مع كثافة شاشة الجهاز. بشكل عام، يفضّل نظام Android تصغير حجم الصورة الأصلية الأكبر حجمًا لتكبير الصورة الأصلية الأصغر حجمًا. لمزيد من المعلومات، يمكنك الاطّلاع على نظرة عامة على توافق الشاشة.

  5. كرر الخطوات من اثنين وثلاثة وأربعة حتى يظل دليل واحد فقط. في هذا المثال، اتجاه الشاشة هو المؤهِّل التالي الذي توجد له أي مطابقات. ولذلك، يتم استبعاد الموارد التي لا تحدّد اتجاه الشاشة:
    drawable-en/
    drawable-en-port/
    drawable-en-notouch-12key/
    

    الدليل المتبقي هو drawable-en-port.

على الرغم من أنه يتم تنفيذ هذا الإجراء لكل مورد مطلوب، إلا أن النظام يحسن بعض جوانبه. ومن ضمن هذه التحسينات أنّه بعد معرفة إعدادات الجهاز، قد يؤدي ذلك إلى استبعاد الموارد البديلة التي لا يمكن مطابقتها أبدًا. على سبيل المثال، إذا كانت لغة الإعداد هي الإنجليزية، لن يتم تضمين أي دليل موارد يحتوي على مؤهِّل لغة تم ضبطه على شيء آخر غير الإنجليزية مطلقًا في مجموعة الموارد التي يتم التحقّق منها (على الرغم من أنّ دليل الموارد بدون مؤهِّل اللغة يظل مضمَّنًا).

عند تحديد الموارد بناءً على مؤهلات حجم الشاشة، يستخدم النظام موارد مصممة لشاشة أصغر من الشاشة الحالية إذا لم تكن هناك موارد تتطابق بشكل أفضل. على سبيل المثال، تستخدم الشاشة الكبيرة الحجم موارد الشاشة ذات الحجم العادي إذا لزم الأمر.

مع ذلك، إذا كانت الموارد الوحيدة المتاحة أكبر من الشاشة الحالية، لا يستخدمها النظام ولن يتعطّل تطبيقك إذا لم تتطابق أي موارد أخرى مع إعدادات الجهاز. ويحدث ذلك مثلاً إذا تم وضع علامة على جميع موارد التنسيق باستخدام المؤهِّل xlarge، ولكن الجهاز شاشة بحجم عادي.

ملاحظة: إنّ أولوية المؤهِّل (في الجدول 2) أكثر أهمية من عدد المؤهِّلات التي تتطابق تمامًا مع الجهاز. في المثال السابق، في الخطوة الرابعة، يتضمّن الخيار الأخير في القائمة ثلاثة مؤهلات تتطابق تمامًا مع الجهاز (الاتجاه ونوع الشاشة التي تعمل باللمس وأسلوب الإدخال)، في حين أنّ السمة drawable-en تتضمّن معلَمة واحدة فقط تتطابق مع (اللغة). ومع ذلك، تحظى اللغة بأولوية أعلى من هذه المؤهِّلات الأخرى، وبالتالي يتم استبعاد السمة drawable-port-notouch-12key.