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.
Related
As we all know that Google launch new feature of distributing android apk using android-app-bundle that has so many advantages.
So my question is, how my app will behave if I place all the images/resources in single folder like drawable-xxxhdpi. e.g. Lets say I have one application that uses 5 images. Instead of taking different sizes for different resolutions, I place all the images in single folder (drawable-xxxhdpi) assuming lets android handle it based on device resolution.
As we know that android-app-bundle generates different different apks based on resolutions, languages and so on.
So in that case what will happen to my app ? How APKs will be generated for different resolutions (Android itself re-scales images and generates bundle ?) What will happen to app, will it crash or working properly for smaller resolution devices ?
I know this is non- coding question but its technical question. I tried to search for this but not able to find exact answer of it.
I may help to others as well.
Your app will work the same as before: Play serves to a given device the files that the Android platform would have loaded if it had served the APK with all the files.
In other words, if an mdpi device would have loaded the resource res/drawable-xxxhdpi/icon.png, then that's what Play will serve to that device.
--
Also, slightly unrelated to your question, but note that there are some downsides to providing resources only in xxxhdpi (regardless of whether you publish an APK or an Android AppBundle):
The Android platform will have to rescale these images at runtime on lower resolution devices, thus taking some CPU time and making your app slightly slower.
Your app is bigger than it could be on lower resolution devices. If you provided also the same resource in mdpi, it would obviously be smaller, and that's what Play would serve to an mdpi device, thus making your app smaller for those devices.
Resource not found exception will be triggered in devices with lower resolutions
Good and very helpful question, I think your application will work fine on xxxhdpi devices but those devices which are mdpi or hdpi will face layout issues. I don't think so there would be any other issue than this.
I need to develop an Android application and I am a starter to this environment. Actually, we need to port our existing application written for iPhone with Objective-C to Android. We are targeting four devices for now: Samsung S2, S3, Note and Note 2. The application completely consists of custom images in its buttons and backgrounds. As from my experiences in iOS development, we designed 320x480 and 640x960 backgrounds for non-retina and retina devices and the system selected the correct ones provided we give appropriate #2x suffixes. I am trying to understand the Android's way of handling this. I have read the [Supporting Multiple Screens] (http://developer.android.com/guide/practices/screens_support.html) document, but I am still confused on a few things.
As far as understand, there are size and density categories named as small,normal,large and xlarge and ldpi, mdpi, hdpi, xhdpi. We need to generate appropriate bitmap resources and place them under correct "drawable-X-Y" folders. This looks like an advanced version of the #2x notation in iOS. But I don't get exactly how we should prepare background images. For example Note1 and Note2 have resolutions of 449x718dp and 431x767dp respectively if I calculated correctly and therefore they both fall into normal size category. If we prepare a background image for Note1, its screen ratio won't be the same for Note2 and the background image will have to be resized. So, the system does not handle different sized devices which fall under the same size and pixel density category. So, what I do not get is how this system allows us to reuse the same background image for similar devices under the same size-density category. Should we prepare separate background images, say, for Note1 and Note2? If so, what is the meaning of this categorization, am I missing something?
We are targeting four devices for now: Samsung S2, S3, Note and Note 2.
Unless you are controlling the distribution of the app, and can somehow limit it to run on those devices, then at best those are sample devices. If, for example, you are planning on distributing your app via the Play Store, your app will wind up on many others, with a range of screen sizes, densities, and resolutions. While you can perhaps limit the size/density combinations via <compatible-screens> elements in your manifest, there are still going to be a range of resolutions.
So, what I do not get is how this system allows us to reuse the same background image for similar devices under the same size-density category. Should we prepare separate background images, say, for Note1 and Note2?
In the case where you can limit the distribution of your app to those four devices, if you want to use android.os.Build to sniff on the device and choose a different image based upon the device model, you are welcome to do so.
In the case where you are distributing the app to a wider audience, where your app could run on arbitrary devices, you have no practical means of determining, up front, what all possible resolutions might be used. Hence, you have no practical means of creating custom images for each possible resolution. In this case, you will need to rethink the approach of your app, learning from the techniques that millions of other developers of desktop and Web apps have used for dealing with arbitrary resolutions.
It is better to use dp for your control sizes and use 9-patch for Android apps. Android SDK can not handle this kind of detailed categorization. the hdpi/mdpi large/xlarge screen can help to an extent, but your case I think there is no easy way. If you absolutely need to do separate images for each device, then you may consider to do layouts like this:s2_layout_actvity.xml, s3_layout_activity.xml, and in each of them use corresponding images. And detect what device you have before you call the setContentView.
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.
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 was looking at the source code of the open source Google IO App for android, and I relazied that they only have drawables in the "drawables-hdpi" (with only 2 exception out of 50 or so).
Reading the android guides and articles, I came to think that we need to support different screen sizes and resolution, but Google's IO app, which is supposed to reflect good GUI design patterns only has drawables for hdpi.
What is even more confusing to me is that it looks fine on my small low-dpi screen (SE Xperia X10 Mini).
Can someone please clarify my confusion.
This is a new answer because it cant be postet as comment due to its length... Android will take care of scaling. So it is not necessary to provide different screens if you just simple scale the images yourself. See this comment from Dianne Hackborn (Android framework engineer):
Sure, if you are actually generating different bitmaps for different densities, then you must be doing this because you want/need to carefully control their graphics. However my original point stands: if what you are doing is drawing your icons at one high resolution and then scaling those down automatically to generate lower dpi versions, it is well worth considering just letting the platform do the scaling for you.
Also keep in mind that for the new tvdpi density that is used on things like the Nexus 7, we strongly discourage developers generating their own bitmaps for it. Let the system take care of scaling those down (from the hdpi or higher density version you supply). This is what is happening for very nearly every single graphic you see on the stock software that comes with the Nexus 7. If it is good enough for what is shipping on the N7, it is probably good enough for you.
Source: https://groups.google.com/forum/?fromgroups#!topic/android-developers/-CMgbDIo0qA%5B1-25%5D
Android does a lot of work on its own in order to get stuff to look well on almost all screens.
Taken from: Supporting multiple screens
At run time, the platform provides
three types of support to your
application, to ensure the best
possible display on the current device
screen:
1) Pre-scaling of resources (such as
image assets)
2) Auto-scaling of pixel dimensions
and coordinates
3) Compatibility-mode display on
larger screen-sizes
Specifically, since that app only has hdpi images, it will downsize them to look well on a mdpi and ldpi screen.
The Google IO App was for the Google IO conference attendees. If you remember, all attendees received a HTC EVO at the conference that was pre-loaded with this app (in lieu of the traditional binder with maps and schedules). So since the EVO is a hdpi capable device, I'm guessing they didn't need to include icons that weren't hdpi.
As for why it looks good, blindstuff has that covered. They auto scale the icons down for smaller devices.