High resolution app backgrounds? - android

and i would like to have a nice high resolution background for it.
If i mind galaxy S4 and galaxy Note3, they have 1080 x 1920 px screens.
That means my 1080 x 1920 px background will be 3 MB.
What!?? Yes. My whole app should be 3 MB not only one drawable piece.
So my question is, how developers solve this? I would like to have a nice textured well designed background, if it would be flat design, there wouldnt be problems like this.
And okay.. lets say Galaxy S4 and Note3 have really big amount of memory and fast processor and i use that 3MB background, but... what happens when somebody would like to use my app with a low budget device? Maybe its cannot even show that big image.
Any ideas about this?

If you are worried about other devices you should simply define different resources along with the correct size qualifiers, like stated in the Android guidelines.
smallestWidth sw<N>dp
Examples: sw600dp sw720dp
The fundamental size of a screen, as
indicated by the shortest dimension of the available screen area.
Specifically, the device's smallestWidth is the shortest of the
screen's available height and width (you may also think of it as the
"smallest possible width" for the screen). You can use this qualifier
to ensure that, regardless of the screen's current orientation, your
application's has at least <N> dps of width available for it UI.
...
Basically you can define a drawable-sw<N>dp for each family of screens you want to support, putting in there targeted pictures as you need.

I think you need to change the resolution of your image. I created a 1024 x 768 PNG background image and its size was only around 300kb.
Check your image resolution. I recommend 72 pixels/inch. I'm not sure if there's any other softwares, but you can check and change your resolution on Adobe Photoshop if you go to Image -> Image Size. You might need to uncheck 'Resample Image' I think.

Related

How to test android app on all screen sizes

I've created my app but I decided to test it on all screens to be adaptive. Maybe testing it in
MDPI(160dpi), HDPI(240dpi), XHDPI(320dpi), XXHDPI(480dpi) and XXXHDPI(640dpi) which corresponds to all screen sizes. However I tested my app on two devices support 320dpi. I thought that I get the same result but it don't. so don't know how to test my app on all screens. I'm confused.
I used Genymotion for emulators:
one with 720 * 1280 320dpi
screenshot
and other with 1200 * 1920 320dpiscreenshot
Please help me with that or if there's another way to do it let me know.
thanks in advance
(Bunch of explanation about why this is happening, I put my suggestions in the last section)
DPI isn't the same as size, it's just about how many pixels are packed into a certain area. The higher the DPI, the more pixels there are, meaning they're a lot smaller. So you can get fine detail, but it also means you need more of them to cover a physical distance or area on the screen.
Which is why Android uses dp instead of raw pixel sizes most of the time - the standard minimum touch-target size is 48dp, but how many actual pixels that is depends on the pixel density of the display. For mdpi displays it'll actually be 48 pixels, for xxxhdpi it'll be 4x that amount
It also means if you're doing your design work in dp, the pixel density of the screen doesn't matter - elements with a fixed size will always be broadly the same size on every screen (the mdpi etc buckets are like a "close enough" grouping, the devices in each group won't all have exactly the same DPI) because it's getting translated to the equivalent number of actual pixels. What testing does help with is checking your drawable assets look ok on different screen densities
So you have two devices with the same DPI right?
720 x 1280
1200 x 1920
Because they're the same DPI, those dimensions are converted to dp by the same factor. Let's work it out to be precise (but the exact numbers aren't important): 320 DPI is xhdpi according to that link up there, so 1dp = 2px. Let's convert those screen sizes to dp
360dp x 640dp
600dp x 960dp
It's the same situation but hopefully having those sizes expressed in dp helps you see the problem - when you're designing a layout, you're working with dp, right? The available space you have to work with is defined in dp, and one of those has a whole lot more space than the other! Putting a 300 dp-wide TextView in the layout would almost fill the first one horizontally, but it would only cover half of the second. That's gonna look pretty different!
This is why phones and tablets look so different - even if you have a relatively new phone, and an old Nexus 7 with a much lower resolution, the Nexus 7's screen is going to feel "bigger" and more "spacious". It's a physically larger device, so even though it's low-res, it's also low-density which means those pixels are spread across a larger area. Lower DPI means those pixels translate into more inches. And in the density-independent pixel (dp) system, that means you get way more dp to work with, more space for your layout. Which is what you want on a tablet, you don't want it to look and feel like a massive phone!
That's why it's different - basically one of your devices has more space to work with than the other, because it has more pixels, and the same DPI so those pixels aren't just used for finer detail.
As for testing, you need to look at different screen sizes - which is dependent on the resolution and the DPI. Basically pixels / DPI = size in inches. Do that for your two 320 DPI examples and you'll see one is a fair bit larger, physically, while having the same density
Probably the easiest way to do this, really, is to look at your layout in the design view, and change the Preview Device setting at the top. Some of the Phone devices are more "spacious" than others, newer ones are taller, so go through them and see how your layout changes. Try a Tablet one and see what a lot of extra space does. And if you go down to the Generic Phones and Tablets section at the bottom, there are a bunch of reference devices in there, some of which will be very cramped!
Once you've found a few useful ones, you can set up your emulator / virtual devices with each of their screen resolution / density combinations. I don't know about Genymotion, but the built-in AVD manager gives you a lot of those device definitions as templates when you create a new virtual device. You should at least be able to enter those settings yourself
Also when you publish an app on the Play Store, they'll automatically run it on a bunch of reference devices and give you access to a bunch of screenshots, so you can see if there are any problems with certain screen sizes and fix them before you launch

Android Tablet "dp" difference

I would like to create a adaptive UI for both mobile and tablet devices. I would like to know for example for mobile devices if I give android:textsize="2dp then how much I should give for tablet devices. I know I should give them in values-w820dp and appropriate folder but how to calculate the difference of this dp. I couldn't find any resource for this. Help me out.
(1) For most text, it's best to size it in sp units so it scales automatically relative to the user's text-size preference. Folks with lesser vision can pick larger text and then be able to read your app without eyestrain.
(2) If you need some text to appear in a fixed size, e.g. a big headline, then use dp units so it scales automatically relative to the screen's pixel density. (Pixel density is independent of the overall screen size. It's a high vs. low density thing, not a phone vs. tablet thing.)
But don't use size 2dp! That'd be unreadably tiny -- the height of 2 physical pixels of a 160 dpi screen.
(3) If you need some text that uses approximately a fixed proportion of the screen size, then it makes sense to either define screen-size-dependent parameters, e.g. in values-w820dp, or to size it in code.
(4) If you need some text in a fixed number of pixels tall even when the pixels are really tiny, e.g. to draw into a raster image, then use px units.
See Supporting Multiple Screens - best practices.
There are no strict rules here. You can have android:textsize="2dp on your tablet as well if you wish so. You can have a look at the following android developer page which tells how to support tablets and contains chapter called: 5. Adjust Font Sizes and Touch Targets

Supporting Multiple Screens in Android

I have developed an android app and its working fine in my mobile of resolution 240*320.But if I install in another mobile some like 240*400,480*800, etc all the view components are changing according to the screen resolution.
I also created a sub folders under the res like layout-small,layout-large,layout-xlarge this procedure is also working according to the screen resolution the xml files are been read by particular folder.But this is not working on a 240*400,240*432,etc.., these type of screen resolutions are not supporting by the above procedure
What should i do for achieving all the view components to be look same for all screen sizes.
Thank you
This stuff is hard. You may have read the documentation, but you haven't understood it.
Basically, you have to distinguish two important things.
Layouts (XML) are determined by the dp size of the device. Forget about 'resolution' and just think about device independent pixels (dp). The dp size of a device is roughly equal to its size in inches, if it had 160 dots per inch. So a 10" tablet is about 8"x160=1280 dp long, while a 4" phone is about 3"x160=480 dp long. Approximately.
Drawables (PNG and JPG) are determined by the pixel resolution of the device. To produce the identical icon on a device that is 320 dpi and for one that is 160 dpi you need twice as many pixels. A 64x64 icon on the first is only 32x32 on the second.
So you need to produce a range of XML files (layout or dimen) that scale according to the desired dp size and put them in folders with names like sw600dp (shortest width 600 dp) and sw320dp. (Search SO or the web for sw600dp and you'll find lots to read).
And you need to produce a range of PNG or JPG files that scale according to the pixel resolution and put them in folders with names like mdpi and hdpi (search for that too).
Simple enough, but hard to do well in practice. We can only hope that eventually Android will fix this mess but for now this is what we have.
First off, stop using the term resolution. That term is ambiguous.
In Android, one could easily have a phone with a small screen with very high pixel density and a large tablet screen with very low pixel density, and the so-called resulting resolution on both devices could still end up being equal.
i have read that many times and implemented according to that but read
my question properly. – user3851899 3 hours ago
I'm sorry, but believe us, we've parsed your question very thoroughly.
http://developer.android.com/guide/practices/screens_support.html
You've mentioned the term "resolution" five times and yet in the document you've read many times, below is the only part where resolution is even mentioned, and even then, it's to tell us that you should "not directly work with resolution".
Resolution
The total number of physical pixels on a screen. When adding support for multiple screens, applications do not work
directly with resolution; applications should be concerned only with
screen size and density, as specified by the generalized size and
density groups.
Furthermore, can you count the term density is mentioned in that document. It's mentioned 171 times! The fact is, you've missed the main key take away concept from that document.
The term resolution is not very useful for Android development. The concept of size is important for a large background image taking the entire width or the entire height of the screen and it's important for layout issues that take into account the entire height of the screen or the entire width of the screen, but it's not very important otherwise. And what's really important for developing on multiple screens (aside from the scaling font size) is really the density of the screen.
So I implore you, please read that document again. Hopefully, you'll begin to understand it, now that I've reset some of your assumptions.

Android ImageButton relative width

I'd like to ask about one of the hardest thing for me (as a programmer) in android. As I make software mostly without designer (to be honest - totally without a designer) I can't figure out the following:
When I draw a png I use px (not dp) as image width.
I drew a button image with the following sizes:
hdpi: 318x45
mdpi: 212x30
(6 to 4 ratio)
and I would like my button be 80% width of Galaxy s2 which is
Screen Size in Pixels: 480 Pixel x 800 Pixel Screen Size in dp: 352dp
x 587dp
But also I would like to have the same width (80%) for hdpi 10' tablet. Is it possible or I'm missing something?
And is it possible to make 80% but not more than XXX pixel width?
You just need to provide different size images for different screen sizes and densities. When you think about it there's only a few different formats you need to worry about. You will then just create an "80%" size image for each of those formats, place them in the seperate drawable folders, and use them accordingly.
The android docs on supporting multiplce screen size and providing alternative resources are actually pretty comprehensive on how to do this.
Otherwise I'm sorry you don't have a designer. My tip - make your icons originally in Adobe Illustrator if you have it that way you can easily scale them to whatever size you need. As vector images they won't lose quality so you can change the size all you want. When you're ready, just export for web and devices at the size break points and you should be fine.
You have to use the android:layout_weight attribute.
Details outlined in a similar question here

Android: Should my graphics by 480x800 or 480x854?

I'm wanting to target WVGA (480x800) and FWVGA (480x854) devices with my program. My question is: for my full screen background bitmaps which resolution should I make them?
There are a few ways you can attack this issue.
Make one background per aspect ratio and calculate which to use when the app starts. Find the aspect ratio by dividing the width by the height.
Make one background with filler on the sides and bottom for cropping, when you display the image resize it's dimension which has the largest difference from that of the screen's resolution to the exact screen resolution. This will cause the bottom or sides to get cropped a bit.
You could also use a combination of these strategies to create a couple backgrounds, one each for a range of aspect ratios, and then use the cropping strategy to take up the negligible difference.
Be flexible. Android can be run on many different devices, and it would be a very bad idea to limit yourself to certain resolutions. Instead, write your code so that it scales. (Keep it mind that you might have to crop the image if necessary, or live with different aspect ratios).
Just as food for thought... there are Android devices with 480x320, 240x320, 480x800, 480x854, not the mention the upcoming Samsung tablet at a higher resolution. Limiting yourself to a certain resolution would be bad.
Here is something from the SDK you may want to read up on too: http://developer.android.com/guide/practices/screens_support.html
EDIT: Assuming that you're focusing on those two resolutions -- I would say it depends on your image. Your best bet may be to go for 480x854 and design the image in such a way that it won't look bad if you lose 27 bytes on either side. If that's impossible, make it 480x800 and add black bars on either side if run on 480x854.
you can get any bitmap and convert it into a drawable using BitmapDrawable .Then you can set bounds to the drawable to match your screen background.
I've made my background graphics 480x864, the hdpi equivalent of WQVGA and thus as large as it gets. Since I center background graphics vertically, this will display nicely on QVGA, HVGA, WQVGA and WVGA, cropping a bit in most cases. To make sure that the important elements are always seen, I limit them to an area of 480x640 in the center.
To leave nothing to chance, I provide scaled down versions of the graphics at the same aspect ratio for MDPI and LDPI. Works great so far.

Categories

Resources