CODEWITHSUNDEEP
androidblackberry-playbookkindle-fire
Manfred Moser
Manfred Moser

Reputation: 29912

7in tablets in Android - screen size qualifiers

I encountered a weird behaviour when starting to test my app on some 7in Android models and I would like to find out if others are finding the same problem and what people recommend as a fix.

Here are the details:

The application has full tablet support, which is triggered with qualifiers for the layouts. xlarge devices get the tablet mode with multiple fragments being displayed on the screen.

For newer Android versions there are also some values that set variable that change the UI on the flow using the sw600dp qualifier as well as the xlarge one.

The problem:

I am now testing on the Kindle Fire and the RIM BlackBerry Playbook and also want to support the upcoming Google Nexus Tablet (or whatever it will be called) and other 7in form factor devices.

Both the playbook as well as the fire have a 7in screen and a 1024x600 screen resolution.

However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.

Both the tablet as well as the standard UI work fine, but imho the tablet mode is nicer and is fine to be used on the 7in device. However if I push the layout into the large qualifier to also get that tablet mode on the fire I will also get it e.g. on the Note or other quite a bit smaller devices.

With Android 4x I can use the sw600dp and other qualifiers but what about older versions? I assume a 7in device is supposed to behave like a tablet but what about e.g. the Note..

What are best practices for this scenario? Are my observations with the playbook reporting xlarge correct?

Upvotes: 1

Views: 754

Answers (1)

CommonsWare
CommonsWare

Reputation: 1006799

However the playbook seems to trick Android into thinking it is a xlarge device, while the fire does not do that.

Device manufacturers are the ones who choose which buckets a device goes in with respect to size and density. This goes double for manufacturers like RIM and Amazon, who do not want the Play Store and therefore do not have to abide by any particular compatibility requirements the Play Store dictates, so they are welcome to thumb their noses at Google's guidance.

What are best practices for this scenario?

I can't tell you "best".

However, if there are specific devices for which you wish to override some layouts to use a specific size, here's what I would try (assuming the layout you would be using for normal cases is known as R.layout.main):

Step #1: Create res/layout/main_funky.xml as a symlink or hardlink to res/layout-xlarge/main.xml (and likewise for -land, etc.).

Step #2: In your Java code, wherever you refer to R.layout.main (e.g., onCreateView() of a Fragment), decide whether to load R.layout.main or R.layout.main_funky depending upon android.os.Build data to detect these oddball devices by model. Since R.layout.main_funky is one of your normal main layouts, all of your code that depends upon widgets should be unaffected by this choice.

Step #3: In your particular case, add MMPD (magic Maven pixie dust) to steps #1 and #2... :-)

Are my observations with the playbook reporting xlarge correct?

I bought a Playbook, determined that RIM's distribution model is... unpleasant, and did the bare minimum to have a book chapter on it. I haven't tried to see if it is -large, -xlarge, or something else.

That being said, the NOOK Tablet IIRC suffers from this (claiming to be -xlarge rather than -large).

I would expect a Google Nexus tablet, if such a thing comes to fruition, to correctly honor size buckets, plus be running a new enough Android version that -sw600dp and kin will work.

Upvotes: 3

Related Questions