Проблема, которую я испытываю, указывает на то, что выбранный ресурс bucket для данного действия layout XML несовместим с ресурсами, выбранными из папки values, несмотря на то, что одни и те же квалификаторы ресурсов используются в каждом наборе папок.
Пример
После размещения некоторого кода регистрации в моей абстрактной родительской активности приложения я вижу, что при запуске моего приложения над эмулятором типа Nexus 7 (Android 4.1) наименьшая ширина действительно равна 600dp, папка layout-sw600dp-* используется для извлечения UI для активности, но папка, используемая для values, - values-large-*. Я ожидал, что это будет values-sw600dp-*, таким образом предоставив мне жизненно важную информацию о том, в каком ресурсе ведется работа.
Код, выполняющий ведение журнала в родительской активности моего приложения для всех android.app.Activity s
protected void onCreate(final Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
final Configuration config = getResources().getConfiguration();
Log.i(this.getClass().getSimpleName(), String.format("Smallest width is [%s]", config.smallestScreenWidthDp));
configurationContext = SupportedDeviceConfiguration.fromResourceQualifer(getString(string.resourceQualifier));
Log.i(this.getClass().getSimpleName(), String.format("Running under the [%s] configuration context.", configurationContext.getResourceQualifier()));
...
Выход из журнала при запуске этого кода на устройстве типа Nexus 7;
[Logging fluff] Smallest width is [600]
[Logging fluff] Running under the [layout-large-land] configuration context.
Я знаю, о чем вы думаете, откуда взялся этот макет? Читайте дальше...
Фон
Я пробовал подход, описанный здесь , который позволит мне проверять ведро ресурсов, которое будет использоваться во время выполнения. По сути, подход, который я реализовал, имеет следующую структуру квалификаторов ресурсов:
- res
+ layout // Default portrait layout.
+ layout-land // Default landscape layout
+ layout-large-land // pre 3.2 phablet landscape layout (Galaxy Note at v2.3.3)
+ layout-xlarge-land // pre 3.2 tablet landscape layout
+ layout-xlarge-port // pre 3.2 tablet portrait layout
+ layout-sw520dp-port // post 3.1 phablet portrait layout (Galaxy Note at v4.0.3)
+ layout-sw520dp-land // post 3.1 phablet landscape layout
+ layout-sw600dp-port // post 3.1 mini-tablet portrait layout (Nexus 7)
+ layout-sw600dp-land // post 3.1 mini-tablet-landscape layout
+ layout-sw700dp-port // post 3.1 tablet portrait layout
+ layout-sw700dp-land // post 3.1 tablet landscape layout
- values // Contains the root strings.xml
strings.xml
- values-land
default-config.xml
- values-large-land
default-config.xml
- values-xlarge-land
default-config.xml
- values-xlarge-port
default-config.xml
- values-sw520dp-port
default-config.xml
- values-sw520dp-land
default-config.xml
- values-sw600dp-port
default-config.xml
- values-sw600dp-land
default-config.xml
- values-sw700dp-port
default-config.xml
- values-sw700dp-land
default-config.xml
Таким образом, по сути, отборочные values отражаются от классификаторов layout. Под каждой из values-* папок я определил один XML файл с именем device-config.xml с контентом;
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="resourceQualifier">layout-{qualifier of values folder}</string>
</resources>
Итак, например, папка values-sw600dp-land device-config.xml содержит одну строку со значением layout-sw600dp-land. Цель здесь заключается в том, чтобы мой код оставался в синхронизации с макетами ресурсов, отображаемыми на экране. Это необходимо для того, чтобы мой код не удалял "поиск по id" некоторого элемента, который не существует на отображаемом макете из-за вовлеченной недвижимости.
(Необязательно) Более глубокие рассуждения о том, почему я делаю это
Более глубокие рассуждения о желании узнать, что ведро используется во время выполнения, проистекают из осознания того, что мой код с одним фрагментом для всех конфигураций становился все труднее управлять с помощью разнообразной логики на основе коммутатора, которая была не прозрачной и часто дублированные функции из других макетов... мне казалось, что мне нужен какой-то Fragment Inheritance... который, если вы будете следовать ссылке, точно что я сделал. Недостатком этого является то, что мне нужно знать, с какого экрана я работаю, прежде чем инструктировать фреймворк для создания экземпляра x, y или z, безопасный, зная, что созданный фрагмент никогда не будет синхронизирован с макетом предназначено для раздувания. Это наследование работает и позволяет гораздо более управляемый стек фрагментов (Sonar тоже счастливее).
Резюме
Однако мне мешало это очевидное несоответствие между папкой папок и папками значений, которую выбирает фреймворк. Каждый из них имеет одинаковые квалификаторы, поэтому почему активность, использующая XML-интерфейс layout-sw600dp-land UI, не использует ресурс values-sw600dp-land? Я надеюсь, что у меня что-то не так, потому что это было самое сложное из потенциальных решений, размещенных в обсуждении SO, с которым я связан выше.