I'm a visual designer creating a UI for an app for an android tablet. The resolution of the tablet is 1024x600 with a density of 160 - I'm building the UI in photoshop on a 1024x600 72dpi canvas - Is this right? I've seen some previews on the device and the graphics that are super crisp on my monitor are kinda fuzzy on the device. I would have expected them to be even crisper.
The app wont need to support any other devices so its not a question multiple resources -
Can anyone shed some light as to best way to approach? This is my first mobile project so still learning the ins and outs ; )
Guides from Samsung. Bet you also developing for that?
If your UI is in 1024x600 pixels (in photoshop), it should be no problem. I think the problem may come from a few other issue:
density of 160 is called mdpi in Android, make sure you put the pictures to drawable-mdpi folder;
Are you sure your picture/graphics isn't stretched by the Android layouts? For example, you may have a button in 100x100 px, but in the layout, it is defined like "fill_parent" or "120dip", then, it is stretched and not in native density. The native density for 160 dpi, will be exactly the same as pixel size, (1dip = 1px in 160dpi), so, your button should be "100dip" (or simply use absolute size to get rid of this trouble)
I think you may do a simple test, making a 1024x600 px image (PNG), and put this as the background of the activity, and set the activity to be full screen without title bar. It shouldn't have any problem in showing in this way.
One last word, I actually do my final layout in Fireworks, it has better pixel level control in terms of small UI graphics. But photoshop should also able to do the job.
Related
I developed my app on a Samsung GT-P7510 (10.1" WXGA 1280x800 pixels). When I download to the Nexus 7 (7" 1280x800 pixels) the buttons that I use appear to be about the same physical size. The Nexus buttons are about 95% of the Samsung buttons. The rest of the screen seems to work OK- the text is in the right location and is proportionately smaller because that is defined in terms of screen height.
All my button sizes are defined using "dp" settings in the XML layout files. I would have expected that with the same pixel ratio the buttons would scale. I am obviously misunderstanding this. What setting would I use to get the buttons to scale?
Why do you think Android should scale your app without anything that you tell it to do?
"dp" simply makes things look the same across devices with different densities (higher density makes use of more pixels) . It won't make things larger or smaller, and it's a good thing since you don't want text to be either huge or too small to be able to read.
For text, BTW, it's usually better to use "sp" so that the user might be able to change its size (because people might have eyes problems to read small letters).
If you wish to scale things, you can either create your own mechanism (like this one) or use openGL .
Sorry but i cant understand how i can draw a right picture for the right android phone size.
I readed the android documentation, and they say for i just think in screen size and density and not in resolution, so what size should have my picture?
For example,if i have a phone with size 1000x400(stupid example),and want a button(40x40) that will be in middle,what size should i do?? 40x40?? But in documention they say for dont look for resolution :\
Im confuse...
ps: The documention link Android multiple screens
Basically you'll have to realize that although resolution, screen size and screen density are separate attributes, they are still somewhat related. If your button is 40x40 as you mentioned, and that's the size you find looks good in the center on a hdpi(high density) device, you will have to scale it so that it fits accordingly on mdpi(medium density) and xhdpi(extra high density) devices. What I like to do is use PhotoShop or another graphical editor and resize my assets so that they fit on whatever density devices I'm trying to target. I make sure to always use *WRAP_CONTENT* for my height and width attributes and never fixed values.
Also, if you do not include these scaled alternatives in your res/drawable folders..you're basically saying that you're relying on the system to scale them for you, which can be a gamble. So I always go with resizing my assets so that I include a version for all densities. The link you posed explains everything pretty well
I'm writing a game for Android and can now test it on a second device, the Nexus 1. The game uses fix pixel-values, just using bigger cutouts of the background for high-res devices. So I thought there would be no problems. Somehow, however, the nexus 1 is making a specific image bigger than it should be (261*66 instead of 174*44). The picture itself as a resource is 174*44, so it's being stretched. Why? What can I do against it?
Edit:
Spritesheet = BitmapFactory.decodeResource(res,
R.drawable.bird_spritesheet);
Is the used code.
Edit 2:
Is there no way to tell the software to just use the size the picture is? I don't want to bloat my software by adding multiple pictures (/drawable-hdpi/ answer).
The pictures are supposed to be smaller on bigger screens.
what drawables folder to you have the picture in? If you put a copy of it in drawables-hdpi I think it will show up real size. It is really better to set things up in such as way that the final size in pixels it ends up is unimportant. Using pixels values is going to ensure that your app looks wrong on at least some of the screen sizes out there.
Because Android runs on multiple screen sizes and you use device independent pixels (DIPs), images get scaled to ensure they look the same on all devices. To avoid this, you can provide alternative resources for high density screens (in your case) and for low density screens.
More info about screens here
I have an app developed for a Droid (phone). In the app, I use:
Bitmap b = BitmapFactory.decodeResource(getResources(), R.drawable.bg);
To set the background bitmap in the application. The bitmap is sized 480x800
which is the WVGA screen size of the Droid (without status or title bar).
Two questions:
When I rotate the phone, the Droid goes into landscape mode and the background no longer fits correctly. How do I tell the App it needs to use landscape mode when I'm not using a layout?
Second, when I run this app on the Xoom, it picks the mdpi drawable which is nowhere near the size of the Xoom screen. How do I define a second mdpi drawable that has a 1280x800 size? I think if I were using layouts, I would create a layout-xlarge directory and place a 1280x800 background in the imageview of that layout, correct?
Thanks!
Update *:
Thanks for the great answers! I upvoted everyone.
I updated the code to use drawable-xlarge-port/drawable-xlarge-land for the Xoom and drawable-port-mdpi/drawable-land-mdpi for the Droid.
I'm not using layouts as I needed to draw directly onto the activity canvas and not sure how to use setContentView() from within the class where I extend View and hook into onDraw() in order to do the animation (would need to be a separate posting).
If I can figure out how to rotate the image myself I could indeed do away with the drawable-*-land and *-port directories.
You can target drawables, not just layouts. You want drawable-hdpi-large-long-land for the first situation (assuming you're letting the system handle rotation events and recreate your activity), and drawable-mdpi-xlarge for the second.
Of course it's futile to try to ship with a separate image for every conceivable phone resolution; partially because there's a lot you'd need, and partially because some targets aren't differentiable (the 854x480 and 800x480 phones out there are all hdpi-large-long, for example, despite the 54px difference). Try to use a scaleable image, a stretchable 9patch, or an image you can just fix at the top-right corner (you can define stretch behaviors using an XML-defined bitmapdrawable).
When I rotate the phone, the Droid
goes into landscape mode and the
background no longer fits correctly.
How do I tell the App it needs to use
landscape mode when I'm not using a
layout?
If you alreay detect the rotation, then the Device class is the way to go.
Second, when I run this app on the
Xoom, it picks the mdpi drawable which
is nowhere near the size of the Xoom
screen. How do I define a second mdpi
drawable that has a 1200x800 size?
You can use various image folders dependending on the resolution of the device: ldpi, mdpi, hdpi or xhdpi. You should take a look at the following page for proper support of various resolutions and screen sizes.
That's just about right. You can mix in portrait, landscape, and other modifiers, too. Don't forget to use them with your drawables as well as your layouts (and any other resource directory, for that matter). If it's the same layout and different drawables, then you only need to apply it to the drawable, for instance.
You'll want to look at the documentation for resource directories and make use of the size and orientation directory modifiers.
For example:
drawable-land-mdpi
drawable-xlarge-land
layout-port-mdpi
and such
For more information, see:
http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
http://developer.android.com/guide/practices/screens_support.html#qualifiers
I always used the standard emulator when testing and thought it was about time to see what it looked like in a higher res/density setting. I ran my application using WVGA854 which has a density of 240 (rather than the 160 I usually used). The result is my application sitting as its old size in the center of the screen. I don't specifically hardcode the application size anywhere that would produce this (except for background images, but there are other things like x,y positions that are still limited by the old size). What gives? I move over the high res images into the correct folders but it still appears to be forcing my app to a smaller size? The background below is set to 854 width in the HDPI (and MDPI folder) but it is still cutting it off? Using a surfaceView to draw the bitmaps.
Add the <supports-screens> element to your manifest, saying that you support large screens.