I have an iOS app that uses unique textured backgrounds (think of a game title screen or something) on each of the screens that I am trying to port to Android. On iOS they knew the resolutions and just designed the backgrounds around those. Obviously that isn't possible on Android.
What is the best way to put a textured/non-repeatable background into Android that works on various screen sizes and aspect ratios?
The solutions I have thought of so far are:
Fit the shortest dimension and allow the image to go off the edge of the screen for the larger dimension
Make the background image large and center it, then make it stretch out beyond the edges when the resolution is smaller than the image
Stretch the image to just fit (this is ugly and I'd like to avoid it)
Create a different version of the image for each resolution. (This seems way beyond the scope of what is possible for this project.)
As far as I can tell in Android, 1. and 2. aren't possible out of the box because background images set the size of the view to match their size (you can't tell it to just extend beyond the edges, please correct me if I am wrong).
What solutions would you use in this situation?
Use an (match_parent) ImageView to simulate back ground image. (By adjusting the scale type of imageview you can get the result of point 1,2)
http://developer.android.com/reference/android/widget/ImageView.ScaleType.html
Use 9-patch image. You can specify which part of your image can be stretched. For your case I suggest adding a small "margin" to your image, and make it stretchable using 9-patch. Only the margin will be stretched, maintaining the aspect ratio of your image.
android developer 9-patch
Create a different version of the image for each resolution.
As you're probably aware, Android can run on a wide variety of devices with varying resolutions and screen densities. To be fully compatible with all of them takes a bit of graphics work; you need resources for each possible screen density (and in this case, resolution).
For full details, see Supporting Multiple Screens in the Android developer documentation.
Unless something has gone seriously wrong in your development process, you should have the original files (e.g. .psd) to work with when creating these resources.
Related
I have a JPEG photo which I want to use to as a background for one of the screens.
I want the behaviour to be simlar to the css backgroundSize: cover property. (Play with the following tool to see what I mean: https://davidwalsh.name/demo/background-size.html)
For iPhone, this issue is fairly easy, as you can literally have several different versions of the same image depending which iPhone the app is being installed on.
For Android, this is much more difficult as they have various different aspect ratios and resolutions.
Therefore my question is, how can I specify an image that covers the entire screen.
You can always fake this by adding the imageview inside a View and calculate the proper height/width you need to cover the screen (get the shortest side and scale it up and multiply the other side by the original ratio).
You could also use https://github.com/AndreaVitale/imageview that supports a cover mode
For Android, My suggestion is to use 9-patch Image instead of normal image. It will stretch it self to entire Screen, if you placed image as background
of Window it self as well as worked for ImageView perfectly.
Thank you.
I created an image to use for an android splash screen and it displays properly on my phone however when I open the app on a phone with a larger screen it pixelates. So I was wonder if I should create more than one image and if so what sizes should I set for other images because I know I can't use the same sizes as I used for the app icon?
If the images are pixelated
then you need to add larger images for each screen size under your
res folder. sizes depends on your target
or
scale the images. to be safe, make it bigger
it might help you: am I supposed to make images larger for tablets, or same size as handset?
you could probably use draw-9-patch to state which area of the picture can be extended.
Google draw-9-patch
I worked with two approaches so far:
Screen composition
One approach can be using a composition of brackground and a logo. You can have the logo as big as you need (for high resolution screens) and the background as a repeatable texture (it all depends on your design approach) or a gradient or other composition (less prone to pixelation errors).
As big as possible approach
If one image is your approach, you should do a research to know the currently most used and biggest android screen used (https://developer.android.com/about/dashboards/index.html). Knowing that one, you can design your image for that [high] resolution and set the scaleType as CENTER_CROP. With that, you will ensure that the image will be centered, inside the screen, keeping aspect ratio, and at its highest resolution [keep an eye about logos/graphics positions if you want to be sure that they remain visible even in thin screens).
For icons, the best way is Draw 9-patch
Otherwise, you need to scale the images into drawable-xx (res directory), here the explanation
I have an button like this. I was asked to use 9-patch for android development. I am wondering how 9-patch is useful in this case. I am under impression that 9-patch scaling is for rectangular or squared which are in rounded corners so that even content inside grows the container stretches without the distortion. Please help me understand the actual purpose of the 9-patch scaling for Android. Thanks.
The content is scalable, the edges will not be scaled, in typical usage.
They're generally used for backgrounds to buttons, or other screen decorations, where the scaled content can be scaled infinitely without losing resolution.
Ideally, they're used in addition to density-dependent resources where appropriate, so that the section of the resource (which you didn't explicitly state is scalable) isn't upscaled and subsequently pixelated.
Consider the splash screen for the Kindle app on Android, which features a silhouette of that boy reading against a tree. In a simplified version, the ground can be scaled horizontally infinitely, but if the boy was scaled, he'd appear skewed. So you could use a nine-patch and specify the section which can be scaled, and in which direction.
That's not enough though - if you only included a low resolution resource, the resource would still be scaled up initially if the device display was of a higher density. In this instance, the boy might look blurred from the upscaling, and is an example of when a higher resolution resource could have helped prevent the pixelation.
The way you've phrased the question suggests (to me) that you're asking whether 9-patch images can replace all drawable resources, like icons or resources with pictures in them, to which the answer is no. They're only to be used to scale sections of resources which feature a block of a single colour (i.e. sections which cannot be pixelated).
--
http://developer.android.com/guide/topics/graphics/2d-graphics.html#nine-patch
Please help me understand the actual purpose of the 9-patch scaling
for Android
There are many situations where you find yourself needing the same button style but in different sizes.
So in that case you will have to provide different size resources. But to avoid this, you can simplly provide a 9-patch image, which will be used irrespective of sizes.
Advantages of using 9-patch:
When used as background,image won't stretch and loose proportions in different screen sizes.
Saves memory.
9-patche images are small, reusable and scale nicely.
If you don' use 9-patch images, you will need to test on various sized screens.
9-Patch
A guide to 9-patch
I hired a designer to help me redesign the UI for my Android app. For each Activity he gave me an image for the background, which includes any static content like fancy frames for text content; plus images for the buttons, which must fit in to the background image in exact places, to fit into the frames in the background image.
However, since Android devices have different screen sizes and aspect ratios, it's easy to fit the background image by itself with android:scaleType="centerInside", but how can I get all the other images to fit in with background exactly, to the pixel? If they didn't have to fit in with the background, I would just set the exact width and height for each ImageButton, but depending on how the background scales (based on the screen size and ratio) they might end up not aligned correctly.
Thank you very much in advance.
Update:
Is there some way I can have an entire view (e.g. a RelativeLayout) scale inside the screen, like the way the image scales inside the ImageView with scaleType="centerInside"? If so, I would be able to set the RelativeLayout's size to the same as the background image, and put all of the other buttons / images in their places relative to the background image, and then just have the whole thing (the RelativeLayout containing all the other views) center inside the phone's screen.
Your approach is wrong (or at least bad), because android devices offer screens not only with different sizes but also with different densities. What you shall read now is Designing for Multiple Screens first. Then understand that non scallable bitmaped UI will rather not work as you imagine. You need to support screen sizes which means your UI elements (like i.e. buttons, lists, headers etc) shall scale. There's lot of possibilities to deal with this, one is using 9-patch bitmaps (randomly chosen tutorial on the 9-patch).
Also, please read this article: Supporting Multiple Screens
When desining UI it suffices to assume you design for mdpi density. Once your layout is done you create drawables for i.e. mdpi and hdpi (and put under the same names into res/drawable-mdpi and res/drawable-hdpi respecitvely). Layout files remains unchaged but framework would automatically pick right asset so your UI will look sharp as long as you provided drawables for that density. Please see Providing Resources article as well.
I have a client who wants me to build an Android version for their existing iPhone app. The design of the iPhone doesn't use any native iPhone elements. It's basically some sort of grid with containing images, buttons, text, etc. Of course it was easy to make the iPhone app because of the fixed pixels widths/heights. The basic grid that defines a screen is loaded via a XIB file, and I load the custom buttons in the right containers in the grid by specifying the exact coordinates.
Then comes Android...
Our client wants to target 3 specific tablets (1024x600). They have given us designs for a ~600x980 portrait version of the app. It is not recommended to use AbsoluteLayout in Android. What is the easiest way to make sure that I can scale it on different devices but that it will look like the given design on the 3 target tablets.
One idea I had (which I'm not sure about whether I can implement it) was:
Get screen width in pixels and height
Based on width/height ratio of the design, pad with bars on top/bottom or left/right
Still do an AbsoluteLayout based on this information
I'd rather not do it this way because it sounds involved and counter to the Android way of doing things. Another issue that is created by scaling is the following. There is a bar of buttons that have a lines separating them. These lines are 4 pixels wide. Obviously, when you start scaling, this is going to mess this up completely. I can't seem to find much information about this s
You probably want to start here:
http://developer.android.com/guide/practices/screens_support.html
But quick points are probably
Do not use an absolute layout. Your life will become terrible
Handle sizes in density independent pixels so they will scale properly on different devices
Use ninepatch images so that when images stretch they will stretch in the proper regions maintaining your 2px borders ect.
Take advantage of the different resource folders for images at different densities (drawable-mdpi vs drawable-hdpi) and layouts at different sizes (layout-small vs layout-large). The latter will allow you to have separate layouts for your tablet devices.
Best of luck :-)