I have a WebView that always displays in landscape mode. It displays a website that has been set up so that the content is always fully visible (i.e. no vertical or horizontal scrollbars) as long as the user's resolution is at least 800 x 600. If I load this WebView on a tablet that has a resolution of 1024 x 600, I have to scroll vertically in order to see the whole thing (since Android's built-in navigation bar at the bottom takes up 48 pixels of vertical space). Similarly, if I load this WebView on a phone that has a resolution of 640 x 360, I have to scroll both horizontally and vertically in order to see the whole thing. Finally, if I load this WebView on a tablet that has a resolution of 1280 x 800, I don't have to scroll in either direction (which is good), but the website looks too small because there's so much extra space around the 800 x 600 design.
How can I make this website scale to fit on any of these three devices? In other words, keeping in mind that Android's built-in navigation bar at the bottom takes up 48 pixels of vertical space, the tablet that has a resolution of 1024 x 600 should scale the WebView to 92% so that the 800 x 600 design fits and the tablet that has a resolution of 1280 x 800 should scale the WebView to 125.3% so that the 800 x 600 design fits.
I've read about using the CSS zoom property to do the scaling, but have seen problems with this. An example is with the way text gets rendered sometimes. I think scaling the WebView natively rather than with CSS might make it perform better.
You can make sure you won't scroll "sideways" by setting a viewport meta-tag. Scaling it vertically to fit is usually going to be a bad idea - is your layout really sufficiently flexible to handle every aspect ratio on every device? If you simply want do display something "at the bottom" used CSS fixed positioning instead.
Related
I am trying to render a view to a PrintedPdfDocument. The size of the page, as expected, is in units 1/72nd of an inch. So, for an A0 size page (width = 33.11 in), document.getPageWidth() returns 2384 (33.11 * 72). The page canvas width equates one pixel to one 1/72nd of an inch unit - so, pageCanvas.getWidth() returns 2384. This is true on different devices. So far so good.
The problem I am facing is that on different devices, the generated PDF document for the same view looks different. On some devices it is stretched on the PDF page, and on somes devices it renders as it should.
What could be the issue here? Isn't the generation of the PDF supposed to be device independent? I noticed that pageCanvas.getDensity() is different on different phones. Why does the phone screen density impact the density of the PDF page canvas?
Given that the numerically document.getPageWidth() in 1/72nd of an inch == pageCanvas.getWidth() in pixels, shouldn't pageCanvas.getDensity() always be 72 DPI? On some phones it is 320 (where it shows correctly) and on others it is 420 (where the view is rendered stretched).
A bit stuck here, so would really appreciate any pointers. Thanks in advance!
I found a way to work around this problem.
I still don't know why pageCanvas.getDensity() is set to the display density instead of the density of the PDF Page (72dpi). My guess is that it may be because some views may incorrectly use display metrics of the screen when drawing to a canvas, even when the canvas is not the screen - but this is just my guess.
Regardless of why pageCanvas.getDensity() is set to screen density, the way I worked around it was by computing the page dimensions (which is in dp) using the screen density. So, if I want to draw to an A0 page (which is 33.11 inches wide), I set the width of the page (when creating the PrintedPdfDocument) to 33.11 * 420 = 13906 dp, instead of the recommended 33.11 * 72 = 2384 dp. This way, when the views draw to the canvas that has 420 dpi density, the resultant page is the required 33.11 inches wide.
This is working perfectly and the created PDF page now looks the same regardless of the device where it was created. The only side effect is that Adobe Acrobat thinks the pages are 33.11 * 420 / 72 inches wide instead of 33.11 inches wide. But this doesn't really matter practically, since we can shrink the pages to fit an A0 paper while printing.
In researching android image sizes for different sized screens/densities etc., I've found an absolute tonne of things, a lot of which may be deprecated, and a lot of which may not be relevant to my situation, so I thought I'd ask for general advice.
My basic question is how big should I make my background image in pixels, or inches or centimetres? Probably pixels would be best.
My app is in locked in landscape mode, I don't need to worry about orientation.
I'm using a vector image, so I don't need to worry about scaling and quality issues
So, I want my background image to fit onto a ten inch tablet, so that it fills the whole screen with no scrolling.
On phones, I want the height(which would be the width in portrait mode) to match the height of the screen, and my image will be in a horizontal scroll view, so scrolls left and right in landscape mode.
So, do I need to do the whole creating different image resources for different dpi's thing, or will one do? What size should I make it?
I will also be lining up textviews with specific parts of the image, so presumably I'll need different layouts, as the lining up of textviews relative to the image will probably vary from screen size to screen size, resolution to resolution,bigger textviews for bigger screens etc. How do I implement this?
Thanks
Vector images should be used for icons only. In your case i'd just use a drawable & make sure you have different images for the different densities. Then create different layouts for phone and tablet. You should use a scrollview on the layout for the phone
The google pixel is a good representation of an android phone: It has a 1080 x 1920 resolution at 441 dpi. Then from the the android developer docs:
xxhdpi ~ 480dpi
you can scale the 1080 x 1920 down by the (3:4:6:8:12) ratios. if you image
has a different aspect ratio make sure that that the width or the height matches with 1080 x 1920 depending on the orientation of the device
This is a problem of supporting multiple Android device screen resolutions. The App is fixed in portrait orientation and there are three parts of the App,
A top bar (fixed height, say 100px at full HD 1080 resolution)
Main body (dynamic height)
My approach is to build the App with 1080 x 1920 natively, and let the app scale down for the target device screen.
** Since the main body is having dynamic height, the scale would be simply (target width/1080)
* I have also worked out the height for the main body in different resolutions, whether there is a soft home button bar or not, I can work out the exact height to use in px.
I have tried two ways doing the scale, but both of them got some problems.
=== Method 1 ===
- Scale the top bar and put at the top (no prlblem, 50 px in this case)
- Let the main body to auto fill with "0dip" + "weight = 1" (problem described below)
Problem: If doesn't matter the order of applying the parameters, the scale is always applied after the 0dip and weight is set and to fit the screen size, so in a non-1080x1920
situation, the main body would actually be scaled down further. e.g. say if the device is 540 x 960, and the main body part is supposedly occupying a 490 x 960 area. Having the
"0dip" + "weight = 1" with a scale factor of 0.5 in this case supposedly to scale from the 1080 size, the actual main body would actually shown as a 245 x 480 area in the main of
the 490x960 space allocated for it. In a full HD case, whether it is 1080 x 1920 (without the soft home bar) or 1080 x 18xx (with the soft home bar), since the scale factor is "1"
(no scale), the auto fill is working perfectly across different screen height. When it is not 1080, the scale is applied at the
(You may like to say, then, just don't scale the main body part, then the screen occupying is perfect, however, then items are shown at the 1080 size, so you only see part of the
content, 25% top left part in this case)
This then lead me to my 2nd method
=== Method 2===
- Scale the top bar and put at the top (no prlblem)
- Set the main body area to be 1080 x 1920 at layout, then at run time, work out the actual target width and height, set the area to the size for scaling, scale it accordingly then
calculate a margin to bring the part in correct position
Say if the target screen is 800 x 1205 (1280 - 75 the soft home button bar)
The scale = 0.74074074 (800/1080)
Top Bar will take 74 px in this case
Main body would supposedly have 1131 px
After scale before the margin was applied, the main body is only partially shown with a black padding on the left and top, I was assuming it was center placed in a 1080 x 1920
space, so to work out the margin to bring it in cirrect position, i got the fomula below
Left moving px = (1080 - TargetWidth) / 2 => always working correctly with different screen res
Up moving ps = (((1920 - TargetHeight) / 2) - TopBar Height ) => not working, got a weird padding from screen to screen Note that the TargetHeight is the full height including the TopBar to be occupied
I did a screen pixel analysis first, I found that in this 800 x 1205 case, the black space at the top between the top bar and the main body was 306
That obviously has something to do with the top bar 74 pixels, together the top space was 380
However, consider the full target height was 1205, with 2 x 380, that is 1965 pixels, and i can make the formula work for this screen if I add 45 pixel to the calculation.
BUT, when the resolution changes, the gap is different, that amount of extra pixel is just random....
=========================
My questions
Are there better ways to achieve what I am intended to achieve?
Is there a way to use "0dip" + "weight = 1" + apply a scale which doesn't cause 2x shrink?
What is the mystery margin amount there, or maybe i have missed something and could have get it right with some correction?
Thanks, any help would be very much appreciated.
Now I'm making wallpaper image for android tablet devices like Motorola Xoom or Galaxy Tab.
In android phones, typically wallpaper image size is 2 * screenWidth x screenHeight, but in Motorola Xoom it doesn't seem right because it automatically centered and scaled in weird way.
Is there anyone who knows about the exact image size for these devices or mechanism of wallpaper manager?
Thanks
If you have a Super TFT screen like the newer HTC phones, your phone has good (not great) black levels, sharp lines, and fairly good colors. Something with some black will be good, but don’t overdo is as you might notice some bluish tones when the brightness is cranked up. You can however do more intricate images thanks to the high sharpness of the screen. For regular LCDs, just avoid a lot of black and it should look fine.
Ideally,
the Height of the wallpaper should match with the height of the device (or some multiple)
the width can be anything more than the width of the device (keeping the aspect ratio and point 1 in mind)
The android launcher will automatically center the image and then divide the image across all its home screens, let us illustrate this with an example:
Say if there are 3 homescreens, the screen will focus at the center right away and if you flick towards the left or the right, it will scroll to that screen. In other words it the homescreen wallpaper will move 2 times.
(Taking that logic forward, if we have 5 screens, we will be able to move 4 times, if there are n screens, one is able to move n-1 times!)
This is how the formula works:
device_screenwidth + (number_of_homescreens - 1) x distance_moved =
image_width
Say we have an image with height = 800 pixels and width 1280 pixels, applying the formula
=> 1280 + (3-1) x distance_moved = 2000
=> distance_moved = (2000-1280)/2 = 720/2 = 360
in other words, the central 1280 pixels of the walpaper are displayed first, but every time you flick left or right the walpaper shifts by 360 pixels at a time.
This is how the wallpaper is displayed over the 3 screens:
screen 1: 0 to 1280 pixels
screen 2: 360 to 1640 pixels (1280 + 360) (This is the default home screen)
screen 3: 720 to 2000 pixels (1640 + 360)
That is how an image/wallpaper with a width of 2000 pixels and a height which is the same as that of the device (800) is mapped across 3 home screens on a device with a resolution of 800x1280 pixels
I have a basic linear layout, with image view that display photos, textviews that show text etc...and when I test my whole app on my android 2, there is never any part of the screen that doesn't show. But when I test it in the QVGA emulator, half the view is off the screen. Now, some of my text is defined to a certain size.
I never use px (only dip) in any of my xml. I use fill_parent, wrap_content where it is needed and never fix a height or length. Could it be with my text, I use say, textSize = 22dip? I couldn't find documentation on why that would not work in all sizes.
Could it be that some apps need to be programmed to those screen sizes? Or am I missing something?
Thanks!
DIP actually doesn't help in fluid layout design. DIP tries to make sure things will looks the same size across different screen density. (imagine the concept of Point in typography)
Without your code and/or screenshot of what happen, it is hard to judge what happens to your program, but 22dip text size is possibly one of the reason which:
22dip text in HDPI will become: 22 * 240 / 160 = 33 pixel
22dip text in LDPI will become: 22 * 120 / 160 = 16.5 pixel
If your setting on QVGA is HDPI, then it is actually 33 pixel tall for a letter, which consumes more than 1/10 of the screen height.
By the way, your 16:9 wide screen (vertical) may fit everything in one screen without scroll, while QVGA is only 3:2 screen, even though everything is in proportion, something would be hidden away for sure.