O problema que estou enfrentando indica que o intervalo de recursos sendo selecionado para uma determinada atividadelayout XML é inconsistente com os recursos que estão sendo selecionados dovalues pasta apesar dos mesmos qualificadores de recursos exatos que estão sendo usados ​​em cada conjunto de pastas.

Exemplo

Depois de colocar algum código de log dentro da atividade pai abstrata do meu aplicativo, eu posso ver que, ao iniciar meu aplicativo em um emulador de tipo Nexus 7 (Android 4.1), a menor largura é de fato 600dp,layout-sw600dp-* pasta está sendo usada para buscar a interface do usuário para a atividade, mas a pasta que está sendo usada para ovalues évalues-large-*. Eu estava esperando que isso fossevalues-sw600dp-* fornecendo-me, assim, as informações vitais sobre o intervalo de recursos em que a atividade está sendo executada.

Código fazendo o registro na atividade pai de meu aplicativo para todosandroid.app.Activitys

  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()));
...

Saída de registro de quando eu executo este código em um dispositivo do tipo Nexus 7;

[Logging fluff] Smallest width is [600]
[Logging fluff] Running under the [layout-large-land] configuration context.

Eu sei o que você está pensando - onde é que issolayout-grande-terra derivação vem? Leia...

fundo

Eu estou experimentando uma abordagem descritaAqui o que me permitiria inspecionar o depósito de recursos em uso no tempo de execução. Essencialmente, a abordagem que implementei tem a seguinte estrutura de qualificadores de recursos;

- 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

Então, essencialmente, ovalues qualificadores refletem a dalayout qualificadores. Sob cada um dosvalues-* pastas eu defini um único arquivo XML chamadodevice-config.xml com conteúdo;

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="resourceQualifier">layout-{qualifier of values folder}</string>
</resources>

Então, por exemplo, ovalues-sw600dp-land pastadevice-config.xml contém uma única string com valorlayout-sw600dp-land. O objetivo aqui é que meu código permaneça em sincronia com os layouts de recursos exibidos na tela. Isso é necessário para que meu código não seja "encontrado por id", algum item que não exista no layout exibido devido à propriedade real envolvida.

(Opcional) Raciocínio mais profundo de por que estou fazendo isso

O raciocínio mais profundo para querer saber o intervalo que está sendo usado em tempo de execução nasceu da constatação de que meu código de fragmento único para todas as configurações estava se tornando difícil de gerenciar com várias lógicas baseadas em switch que não eram transparentes e muitas vezes duplicadas. outros layouts ... era como se eu precisasse de algum tipo deHerança de fragmento ... que se você seguir o link é exatamente o que eu fiz. A desvantagem disso é que preciso saber com qual tela estou trabalhando antes de instruir a estrutura para instanciar o fragmento x, y ou z, sabendo que o fragmento que está sendo criado nunca ficará fora de sincronia com o layout é destinado a inflar. Esta herança funciona e permite uma pilha de fragmentos muito mais gerenciável (o Sonar é mais feliz também, o que é legal).

Resumo

No entanto, tenho sido frustrado por essa aparente discrepância entre qual pasta de layout e pasta de valores que a estrutura seleciona. Cada um tem os mesmos qualificadores, portanto, por que uma Atividade não alavanca olayout-sw600dp-land UI XML usa ovalues-sw600dp-land recurso? Eu estou esperando que eu tenha algo errado, porque foi a mais brilhante das possíveis soluções postadas na discussão do SO com as quais eu me relacionei acima.