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.
Related
I'm developing an app that's intended for high-end devices only. It already only supports API 17+ but I've noticed some older devices that run API 17 that I'd like to exclude. My question is:
What's the best way to filter out older devices that still run a relatively new Android version?
I'd like to avoid manually excluding specific devices in Google Play.
Filtering based on screen density
One thing that I'd certainly like to do is filter on screen density (I'd like to support only hdpi and higher). I've read the compatible-screens article but I don't really like the solution presented there because:
According to the article: "You should use it only as a last resort, when the application absolutely does not work with specific screen configurations."
I'll get a large list of combinations in my manifest (if I support hdpi, xhdpi, xxhdpi and xxxhdpi with screen sizes medium, large and xlarge I'll already have 12 combinations).
What if a new screen density (e.g. xxxxhdpi) or a new screen size (e.g. xxlarge) is added? To support those I'd have to update my manifest every time a new bucket is added.
It seems strange to me that I can't just specify that I want to support hdpi and higher in a single line in the manifest.
Filtering based on device features
I've also considered filtering on some feature that only high-end devices have, so I read the uses-feature article. However, it seems that I can only filter on things like bluetooth, camera and wi-fi and not on anything more indicative of a high-end device like hardware acceleration.
You just can't filter out specific device(s) using the AndroidManifest.xml file itself except the screen size/density etc. say if you need to filter out a specific handset/tablet for a specific vendor then is will not be possible using the manifest file only.
"What is the best way to filter out older devices that still run a relatively new Android version?"
Solution: There are options in Google Play Developer Console by which you can filter specific devices (handsets/tablets/models etc) according to vendor and model number for a particular app you have published.
To do this goto the APK section of your app:
Now click either on See List or Manage excluded devices the usage is very easy and self explanatory. This show show something like this:
Now All you need to do is just click on the button and it will be added to the Excluded Devices.
Hope it helps :)
After finishing the programming part of my app I want to test it with the Android Emulator.
I tried to make my app density independent an now I want to test it with different emulator devices. Which resolutions and screen sizes should I test? Do you have a list of virtual devices, which you use to test your application before releasing?
Which api-Levels should I test? (My application uses bluetooth).
Thanks for your help.
Basically the correct answer here is to 'test every possibility'.
But this of course would be a huge job.
I usually take the Nexus devices as base lines, which will guide you through most of the possible and populair sizes.
Android versions you should check every one of them, starting with the version you want to support as lowest. Every version can react differently to not only your layout and styles, but also handle your java code differently .
You can find the Nexus devices and their sizes at http://developer.android.com/distribute/promote/device-art.html
Be sure to press 'Older devices'
In addition to this, you could try to get your hands on some populair devices from other manufacturers like Samsung and HTC, since they also have a hand in changing the way your layout and styles will behave.
There is no magic bulletproof answer.
You can use this Platform Versions to glean some information about what are the most common API lvls, and device densities being used.
But ultimately the answer to your question depends largely upon your target audience and the devices that they carry. The best case scenario is to test on as many different configurations as possible =) starting of course with the most widely used.
If you are designing an application, which is density specific, then you should test on all the possible densities. To test your application on various density device, you should have base device for each density for e.g Samsung Nexus - xhdpi, HTC One(hdpi) and similarly one base device for mdpi, ldpi. If you are also supporting Tablets have base device Tablets supporting different densities.
Additionally, you can avoid scaling with respect to device density by setting the following parameter in the manifest file supports-screens android:anyDensity=false
In our Android we use different layouts for different screen resolutions, using the resource selection mechanism described at
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
This works great, except for some devices which report the wrong screen size.
In particular we would want to use the same resolution on the Kindle Fire and the Nook Tablet. These have 600x1024 screens and thus should report themselves as having "large" screens. The Kindle Fire does so, but the Nook Tablets picks the "xlarge" resources:
http://nookdeveloper.zendesk.com/entries/20814001-emulator-loads-xlarge-layout
I can detect that the application is running on a Nook Tablet, and add a special case for it, but I have not found how I can force the resource selection mechanism to pick up resources for a certain screen size.
The simple solution (that you're probably not looking for) would be to not have an XLarge set of resources available for the Nook release. This causes both Nook devices to load the same resources. That's what I did, but since I didn't have a great set of XLarge changes this wasn't a big deal for me.
Sadly, Android didn't fix this issue until 3.2, which has minimum width selectors rather than the old bucket system. Nook is hanging tight at 2.3.4, though, so you'll need to roll your own if you want a better size selection system.
Personally, I haven't targeted 10" tablets as much as 7" tablets, because the top sellers are currently the Kindle Fire and Nook devices. The high profile of Nook may make it worth creating a separate build.
I'm developing an Android app that absolutely needs to support Android 2.1+ devices, including tablets and phones.
The tricky part is I want to be able to provide roughly the same user experience on Android 2.x tablets as on bone fide Honeycomb tablets. I'm planning on using the Compatibility package so that Fragment support is always available, but...
The problem I've got at the moment is I've bought a Hannstab for testing, and discovered that it reports to apps that it has a "large" screen, despite actually being 10.1 inches. This would technically make it "xlarge", but of course that category was not included in Android 2.2 (which it runs), hence it's "large". I originally intended to just use resource qualifiers and treat all xlarge devices as tablets, and everything else as phones but now I realise I can't do that.
Would it be so bad to treat all xlarge and large screened devices as tablets? This would include Dell Streaks and other 5 to 7 inch screen devices as I understand it.
Is there a better alternative? I haven't really got my head around fragments properly yet so a fragments-based solution might be obvious to someone who has.
I've noticed that typically, apps I install on my Hannspad use their normal phone UI, with the exception of Evernote which uses a specific tablet interface - I wish I knew how they'd done that.
The new "Smallest Width" resource qualifier introduced in Android 3.2 would solve this problem by doing away with the generalised screen size buckets altogether. Presumably I could copy this approach by writing code to work out the screen width in dp and then adding fragments to the activity as appropriate. Is that wise? I'd rather avoid that kind of work if it's going to be a pain.
Cheers
Would it be so bad to treat all xlarge and large screened devices as tablets?
If your question really is "is it OK to use the same layouts, etc. for -large and -xlarge devices", that certainly can work. It's certainly where I would start.
Bear in mind that device manufacturers really are the ones who determine what is -large or not. It would not surprise me to find some manufacturers creating 5" devices to categorize them as -normal, because they feel that -normal apps tend to work better on their devices than do -large apps.
I've noticed that typically, apps I install on my Hannspad use their normal phone UI, with the exception of Evernote which uses a specific tablet interface - I wish I knew how they'd done that.
Probably using -large/-xlarge resources. I don't know if they are using fragments or not.
In terms of screen sizes, fragments really are for cases where the -large/-xlarge UIs are basically a bunch of -small/-normal sized UIs snapped together like LEGO(R) blocks. In Evernote's case, their -large/-xlarge UI does not fit that pattern, so they may or may not have used fragments.
Fragments offer some other advantages for memory management and configuration changes (e.g., screen rotation), so you might consider using fragments even if you are not sharing fragments between major groups of screen sizes.
Is that wise?
If possible, I would hold off on making that decision until Ice Cream Sandwich ships and we start seeing how some of this stuff will play out on smaller-screen devices.
I have reviewed the content of some of the currently best Android apps (not to mention that I often check the content of apps I personally or professionally use) and I see that they DO NOT support small screens. I do not mean they they literary do not support them by excluding them in the Manifest file. It's just that the directory LDPI is almost empty (except launcher icon and maybe a few other icons) and that layout-small directory does not even exist.
So the question is, should we bother to support the small screens when nowadays Android devices start from MDPI/NORMAL to up?
The whole point of Android is to be compatible with different hardware characteristics so I would tend to say "yes" it's important to consider low res targets.
Although, doing some research it's true that there are less and less ldpi devices. This article shows interesting results:
UPDATE:
watch that article on Android developer website for more up to date figures:
http://developer.android.com/resources/dashboard/screens.html
That, of course, depends on how compatible you want your application to be. If you want it to support older, smaller screens, then yes; otherwise, no. This sounds more like a business decision than a technical one.
I think you may be confusing density and screen size, as you're using the terms interchangeably.
Just because you have a small screen size, does not mean it has to be low-density. There are screens that register themselves as "small" to android, that are considered HDPI, based off their resolution.
Also, if you have MDPI images, it'll work just fine on devices reporting as "small", as most of that is based off the design of your layout and how well it flows across multiple screen sizes.
As you can see on the Android screen grid, small <> ldpi. http://developer.android.com/guide/practices/screens_support.html#testing
In closing, just because you aren't including LDPI images doesn't mean you don't support small screens.
This question, to me, comes down to time vs. reward. According to http://developer.android.com/resources/dashboard/platform-versions.html, a little over 3% of the market base are still running pre-2.1 phones. If Ice Cream Sandwich does what its supposed to do, hopefully these conversations will go the way of the dodo.
At this point very few people have those kinds of devices, and therefor most don't support it. However, those who do support it have a much greater chance of being used by that small percent, simply because no one else is selling to them.
If it makes sense for you app, and you have the time and energy to put into making it compatible, why not? On the other hand you shouldn't try to shoehorn something in and cause it to become a worse product for it.
Also they have released the ability to have multiple APKs based on different requirements, so we can develop apps targeted to earlier phones, without interfering, or adding code and resources, to our higher targeted apps.