I am currently repacking my Android application for the Blackberry playbook but I am having some issues with the layout.
I have a custom layout for the Nexus 7 which I would like to use on the Playbook. This layout is contained in layout-sw600dp. I know this folder naming convention only came into place in Android 3.0+ and as the Playbook uses Android 2.3.3 this is not used.
The playbook currently seems to be using resources in the layout-xlarge folder. Layouts in this folder are geared towards 10 inch tablets and look poor on the Playbook.
Is there anyway I can test if the device is a Playbook and make it load the same layouts as the nexus 7 without changing the xlarge layouts.
I am using layout-xlarge-v9 (by version of gingerbread, which should(1) not be in any xlarge tablet)
Edit to add a note about qualifier precedence and version qualifier
You need to use the version qualifier at the end.
layout-xlarge-v9
layout-xlarge-land-v9
Also, this gets version 9 and higher, so your old layout-xlarge should be now:
layout-xlarge-v11
layout-xlarge-land-v11
I agree on being annoying that it considers itself xlarge
(1) should, because honeycomb was designed for that, but you may find some low-end Android tablets that do, but probably you don't care that much about that segment
Related
I am having some problems with layouts in my android application. I have created multiple android resource directories, for multiple android devices. The problem stands when I try to test my app on a nexus 5 emulator the screen's layout is out of bounds, it is disproportionate completely. In my app all the layouts for the layout-xxhdpi-1080-1920 seem completely alrigth, the problem arises when I start my app in an nexus 5 emulator. It seems that the emulator picks a different layout size and not the one is it supposed to.
And I also have one question reqarding layout creation. Is the any better way to cover as much android devices as possible, instead of making all layout resolutions: for example: -mdpi-460x800 , xhdpi-720x1290, xhdpi-1080x1920, and so on ... It really takes about more than 18 layout directory types and it is quite a lot.
I already looked at all the documentation Supporting different screens.
You could cover almost every android device in the world. To do this you need have device specific resources.
for android versions earlier than 3.2
layout-ldpi
layout-mdpi
layout-hdpi
layout-xhdpi
for android version 3.2 and higher
layout-sw360dp
layout-sw420dp
layout-sw600dp
layout-sw720dp
This is just an representative example, more information here in android docs
If I write a message today is for getting details about the folder tree layouts in android.
I want to warn you now, I have read all the pages of the official documentation regarding support for different screen sizes, it is very complete, but in my opinion not really human-readable. So please, don't just copy a link to the documentation.
My question is simple:
What is the best combination of layouts folders to ensure maximum support for different screen sizes ?
Before Honeycomb, we had layout, layout-large, layout-xlarge, etc ... That's OK, but now we have sw600dp, sw360dp, sw ... Arggh stooop !
In my case, I have to make an application for android and I need to ensure maximum support.
I have some devices on hand:
Galaxy Note 10.1
Galaxy Nexus
Nexus S
Nexus 7
And ... Samsung Galaxy Spica (GT-5700)
And here are my layouts folder now:
layout
layout-sw360dp (for Galaxy Nexus)
layout-sw600dp (for Nexus 7)
layout-sw720dp (for Galaxy Note 10.1)
layout-480x320 (for GT-5700)
(and layout-*-lands)
I'm really not sure of doing things right, I thought the Nexus S would pick the layout folder, but it takes the layout-480x320, why?
So I have some questions:
1. Am I in the right direction?
2. Is it always necessary to create folders layout-large, layout-xlarge ... ? If so what should I put inside?
3. I do think the folder layout-480x320 is not a good solution, but I try to do things well and not make this folder is not enough.
Could someone tell me clearly how to do things right?
Thank you!
What is the best combination of layouts folders to ensure maximum support for different screen sizes ?
That is impossible to answer in the abstract.
Am I in the right direction?
-layout-WxH has been deprecated for a couple of years.
Is it always necessary to create folders layout-large, layout-xlarge ... ?
No. If you are not concerned about Android 2.x -large or -xlarge devices (e.g., Kindle Fire, NOOK) or Android 3.1 devices (0.4% of the market as of November 2012), then skipping -large and -xlarge is perfectly fine.
However, -small may still be relevant for you, for devices with very small screen sizes (under 3" diagonal), if you are supporting such devices.
I do think the folder layout-480x320 is not a good solution
Correct.
I try to do things well and not make this folder is not enough.
Then design a more flexible UI for -layout.
For reference: http://developer.android.com/guide/practices/screens_support.html
The old style size quantifiers are "deprecated":
A set of four generalized sizes: small, normal, large, and xlarge
Note: Beginning with Android 3.2 (API level 13), these size groups are
deprecated in favor of a new technique for managing screen sizes based
on the available screen width. If you're developing for Android 3.2
and greater, see Declaring Tablet Layouts for Android 3.2 for more
information.
I was hoping that devices with 3.2+ would still use resources declared in drawable-large-mdpi, or layout-xlarge, but this doesn't seem to be the case.
I have a test project that contains a layout file for each of these sizes:
layout-sw600dp
layout-720dp
layout-xlarge
layout
On a 10" Motorola XOOM running Android 4.0.x, the device picks the layout in the layout-720dp folder. If that folder doesn't exist, it picks the layout in the layout-sw600dp folder! Why doesn't it pick the layout in layout-xlarge?
Even more strange, is I have drawables in these folders:
drawable-sw600dp-mdpi
drawable-xlarge-mdpi
The 10" Motorola XOOM from above, picks the image from drawable-sw600dp-mdpi. Why doesn't it pick the drawable in drawable-xlarge-mdpi?
Should we not expect the xlarge quantifier to work at all above Android 3.2?
Does this mean I have to duplicate all assets in the drawable-xlarge-mdpi folder, into the drawable-sw720dp-mdpi folder? (To support Android 3.0, 3.1 AND 3.2+?)
Hopefully I am just missing something simple here. Please advise.
From my understanding, for Android 3.2+, if you have at least one folder that uses the new size quantifiers then it assumes that you are using these new size quantifiers everywhere. So this is the reason why it ignores layout-xlarge or any other folder that uses the old quantifiers.
With regard to backward compatibility, you'll have to use in your project both types of quantifiers. The old ones will be used for API < 3.2 and the new ones for API >= 3.2. To avoid duplication, for the layouts you can use aliases. However, for drawables, I don't know of any solution to avoid duplication.
My app has different layouts and styles for xlarge screens. This is important because on phones it is only used in portrait and on tablets it is only used in landscape.
A user contacted me a few days ago because since I published the update with the tablets layouts he can't see some of the objects in my main activity (prior to this update I only had portrait layouts - also on tablets). He uses a 7 inch tablet running Android 2.3.3 and for some odd reason it is using the layouts and styles from the xlarge directories even thew it should use the default layouts and styles.
I tested it on the emulator and had the same problem. I then changed only the android version to 3.1 (did not change width, height and density) and it worked as expected - the default layouts were used.
I don't want to use version qualifiers (layout-xlarge-v13) because then users with old android versions that have an xlarge screen will get the wrong layouts. For android 3.2 and up I could use sw720dp but older versions will not use this so problem remains.
I am able to tell at run time that the device is not large enough for the xlarge layouts but what can I do in that situation? Is there a way to make it use the default resources?
Android doesn't give its blessing to any 7-inch tablets running Gingerbread or below since Honeycomb was released. This means your device must be either old, or non-CTS compliant. You are looking at an extremely small pool of devices that are: API level 7-10 (roughly), 7-10 inches in size, that live outside the main Android ecosystem.
If you want to support such devices, I would recommend that you make layout-large-v7 and layout-large-v11. Assume that these nonstandard tablets will select the first one, and design for low- or medium-density 1024x600-pixel displays.
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?
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.