I am struggling with the selection of font sizes in my Android app. I have a number of real devices, different sizes, different OS versions, different manufacturers, phones and tablets.
The text looks good on all of those devices.
However, when I run the app in the emulator, the fonts are often too large. Obviously, this has to do with the display size and resolution settings for my virtual devices. So I have been toying around a bit with different instructions I could find on the web including a virtual device repository and the Samsung skins. Still, I don't seem to get a good match between real and virtual devices. As an example, the Nexus 5 virtual device preconfigured shows the fonts are monstrous. Font sizes I use are between 10sp for small text and 26sp for very large headers.
I could now configure the emulator such that my app looks great but then I really can't be sure what users will see on their real hardware. What is the right approach for gaining enough confidence that my app looks good in the real world?
Since you are using sp as unit for font sizes, the fonts are scaled according to your user's preferences. If you don't want to allow your fonts to be scaled you should use dp as unit for font sizes.
But I wouldn't recommend doing this because this limits accessibility for users with impaired eyesight.
Related
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
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.
Having some experiences with iOS. I now look venturing into Android devices. One of obvious differences between iOS devices and Android devices is the Android hardware's specs.
I am interested in to find out your experiences in programming perspective in the two platforms. And only specifically to programmings that will utilize hardware on Android devices such as WiFi, bluetooth, camera, microphone, etc. and to be compatible with different Android devices manufactures.
Android gives you an sdk for working with any hardware module.
Camera, bluetooth, wi-fi, gps.
So the implementation of camera app will be same for any phone.
For exmaple there is a difference where some devices mount sdcard. By default it is /mnt/sdcard. But Samsung uses a different path. But you can use GetExternalStorageDirectory() to return the correct directory regardless of device.
The biggest problem of android is screen sizes. You have a bunch of sizes from 2" to 10-12"(There is bigger and smaller devices..) Also you have a bunch of resolutions and densities.
By the standards it is small, normal, large, xlarge screens with ldpi, mdpi, hdpi densities.
You have to create a layout for each screen size, and all of your pics should be in three sizes(for each density). Also fonts size in sp, and UI elements size in dp. It is density independent measures.
Doesn't sound very hard. But some manufacturers are trying to be on the top - and creating some small size screens with enormous resolution and density. So it will be a big problem to create proper layout.
Using Adobe AIR for Android, I'd like to find a way to distinguish a phone from a tablet. The closest I can find is detecting the dpi. (My phone dpi is 254, my tablet is 149) but is that going to be reliable or is there a better way?
(I've been using stackoverflow for a while but this is my first post - yippee!!)
but is that going to be reliable
Absolutely not. A T-Mobile G1 would be a tablet by that measure.
is there a better way?
Frankly, you should not be caring whether an Android device is a telephone, tablet, television, toaster, telescope, or toilet.
You should be caring about characteristics and capabilities.
For example, if you are thinking about tablets in terms of screen size, use <supports-screens> and the -large and -xlarge resource sets (e.g., res/layout/ for normal stuff and res/layout-large/ for larger screen sizes).
Or, if you are thinking about tablets in terms of whether or not you can place a phone call, use <uses-feature> and hasSystemFeature() on PackageManager.
Whether a device is a tablet or not could mean...
One.... Is it running the Honeycomb tablet version (Android 3.0) ? You can use System.getProperty() to get this information.
or
Two....Is it tablet sized? i.e. is the screen a larger size? But bear in mind some tablets are not that big. Best way to handle these is separate resources for each device size.
I'd say in general it's a bad idea to try to define Android tablets into specific groups, as there are many varieties now and a LOT more are coming. So usually best to build your app so it handles different screen sizes, different OS versions, and different features being available or absent (e.g. GPS, keyboard etc).
cdotspace, don't worry about the real dpi, you only need to get virutal dpi:
int virtual_dpi=webview1.getResources().getDisplayMetrics().densityDpi;
Virutal dpi means dots per virtual inch.
For example, the htc desire hd's real width is 2.21 inches, but its virutal width is still 2 inches, the galaxy tab 10.1's real width is 5.35 inches(portrait orient), but its virtual width is 5 inches.
int portrait_width_pixel=Math.min(this.getResources().getDisplayMetrics().widthPixels, this.getResources().getDisplayMetrics().heightPixels);
int dots_per_virtual_inch=this.getResources().getDisplayMetrics().densityDpi;
float virutal_width_inch=portrait_width_pixel/dots_per_virtual_inch;
if (virutal_width_inch<=2)
{//is phone
}
else
{//is tablet
}
I want to make sure that devices with 10,1" and 1024x600 under 2.1/2.2(e.g. Archos 101) are using the correct layout.
Are they large and ldpi?
Also, how can I simulate them using the android emulator?
In the end, the choices of screen size and screen density are up to the manufacturer. Hence, nobody here can answer you definitively.
A 10.1" diagonal screen should be large and probably should be ldpi, though it is possible it will be declared mdpi based upon the apparent density given the distance one would typically hold a 10.1" tablet from one's face.
Bear in mind that ARCHOS' devices do not ship with the Android Market AFAIK, and hence do not necessarily pass the various compatibility tests. As a result, ARCHOS could do all sorts of stuff that would be unexpected.
Also, how can I simulate them using the android emulator?
The Android SDK is not well-suited for testing a 10.1" LCD at this time. I would expect better instructions and support for such sizes in Android 3.0.
For now, set the resolution and density for the AVD when you create it. In this case, you would want to specify 120dpi (ldpi) for the density. Android should put it in the large screen size bucket for you, given those values. Leastways, that basic approach works for getting large WVGA devices.