I've been banging my head against the wall for the whole day now, and i need some help :(
The problem is, that i have a WebApp that was designed for 640x960.
We didn't have time to write css for each screen size, so i've used initial-scale, maximum-scale, minimum-scale in the viewport meta tag to scale the app to different screen sizes.
The problem is, that in Android 4.4, no matter what i do, it always scales the app up, but never down!
I mean if i use a value of 0.7, the app is scaled up. If i use a value of 1.3, it is scaled up again :/
I've tried to change the targetSdkVersion to different versions to get the old behavior, but with no luck.
Can someone help me?
UPDATE:
So i ended up using style="zoom: <value>%" on the body tag. I calculate the percentage based on the difference between the current device screen size and the resolution my app was designed for. Now everything fits.
A viewport of
<meta name="viewport" content="width=640, initial-scale=1">
should make your fixed layout always fit (see MDN for more on the viewport meta tag).
You could be bumping in some of the following:
the contents can't be scaled down more than 'overview scale' (that is, such that your content is narrower than the screen). This is by design - making it smaller only results in rendering white to the sides so why bother. If you want this behaviour you'd need to add padding to the content,
you've specified the layout height of the WebView to be WRAP_CONTENT - this makes the WebView ignore the viewport meta tag, don't do that - set it to MATCH_PARENT or a fixed size,
you're using certain WebSettings:
setUseWideViewport (which overrides the viewport meta tag) or
setInitialScale (which can alter the size of the viewport).
The best way to check if it's the content's fault or the WebView's fault is to see if the page works in Chrome on Android:
if it works in Chrome on Android but not in the WebView then set targetSdkVersion to 19 and try disabling WebSettings, changing your layout to fixed size, etc.. to see what's causing the problem. Maybe start from the other end - by making a super trivial WebView app that just loads the page - confirm that works and then slowly introduce changes to see which one causes the problem,
if it doesn't work in Chrome on Android then problem is the difference in viewport meta tag support between pre-KK WebView and Chrome on Android - this means you'll have to fix your content,
If you're still stuck post a zip that contains sources with a repro (doesn't have to be the full app, just the minimum to demonstrate the problem) and I can try and help you more from there.
Just had a run through of this after not quite being sure of the answer myself.
http://www.gauntface.co.uk/blog/2013/11/29/desktop-site-and-the-viewport/
You want a viewport without an initial-scale if you only want the webpage to fit the WebView's width.
Things that will affect the WebView:
Ensure you have setUseWideViewport() enabled so the page can be larger than the devices width: http://developer.android.com/reference/android/webkit/WebSettings.html#setUseWideViewPort(boolean)
Ensure you targetSDKVersion=19 to ensure you aren't getting any compatibilities for the old webview
If you want to prevent the user from zooming in or out, use user-scalable=no in the viewport rather than set a min and max.
Related
I have an web app that's basically just displaying mobile website in an Android Webview, with some native bits for handling notification & navigation headers.
The issue is, when I change the Display Size setting (under Display) in an Android phone to anything smaller than Default, the content will be squeezed to the right side and left a blank space. I did a check with dev tool, and somehow the CSS's width is set to 66.67% of parent's by Android (in default it's 100%) & a minor left padding is also added. However, if the Display Size setting is larger than default, there is none / very minor style degradation.
The interesting part is when similar app is made in iOS (just display mobile site), there's no issue at all after changing the Display Size. So I'm pretty certain that the fix is limited to Android.
Is there any guidance to add code to anticipate these changes, or at least, completely disable the Display Size setting's effects?
*Edit:
What I've tried & failed:
Setting "width=device-width, initial-scale=1" in the website
Set loadWithOverviewMode and useWideViewPort to true
Combination of both of them
Solution is simple actually: there's a piece of old CSS code in the website that overrides CSS values when the width of the display is above certain threshold.
For a while now, I'm facing a problem with height: 100% (or 100vh) on Chrome for Android.
Here, I have a page, and a blue div with height: 100vh. The yellow block has height: 50vh.
When I scroll down, the address bar goes away, which makes the viewport size change! So everything that was based on that, changes, too, as you can see here:
.
Everything increases 55px, which is the exact size of the address bar. This is so annoying.
I temporarily fixed it by height() on load, but it is jQuery, so it makes my website unnecessarily slow.
How do you deal with it?
Unfortunately, there's no satisfying way to deal with this today. The good news is that because of that, I've changed this behavior so that 100vh is static and the size of the viewport when the URL bar is hidden (matching Safari). See the Chrome Bug for details. This is currently in Canary channel and would ship in M50.
There's an unfortunate detail: height:100% refers to the viewport when the URL bar is shown but 100vh fills the viewport when the URL bar is hidden (See my explainer for more details)! I did this for compatibility with Safari but we're looking at ways to make this more rational so the M50 target may slip in preference of shipping something more sane.
In the mean time, if you can't wait and you want your page elements to remain statically sized, I'd recommend explicitly sizing a position: absolute box as your root based on window.innerHeight and using percentage based heights for the children. It's not ideal but hopefully will get better soon :)
UPDATE: This is shipping in Chrome M56 - you can currently try it out in Beta.
I am currently using Apaxy (an Apache directory browser). The theme looks beautiful on PC, but on mobile, it's a little too zoomed out. Is there any way I could force-zoom in if a mobile device is detected?
For a little more detail, this is what I mean:
What actually happens: http://imgur.com/xGNjdk2
What I would like to happen: http://imgur.com/8yTJkOJ
I can't seem to figure out a way to do this using viewport, but maybe I'm just not thinking.
You can use the viewport meta tag to set an initial-scale: https://developer.mozilla.org/en/docs/Mozilla/Mobile/Viewport_meta_tag
However, setting an initial scale will load the page "off-center" since it'll start off zoomed into the top left corner. I think what you really want is to set width=device-width in the viewport meta so that the page lays out into a size appropriate for the screen size.
e.g. <meta name="viewport" content="width=device-width">
I am facing a curious problem with the last update of Android (4.4) : my CSS rendering is visible at screen for the user which means that my webview content is very thin before to adapt to the width:100% of the CSS.
I am using an android.webkit.WebView to display an html string like this :
webView.loadDataWithBaseURL(null, html, "text/html", "utf-8", null);
This webview has the following size set :
90% of screen width for webview width
WRAP_CONTENT for webview height
The CSS is built to fit the webview width, the height will then adjust itself. There is no absolute width or height set in the css.
When I display my webview (which is already fully loaded as I used onPageFinished callback to know the loading is finished), the CSS starts to be rendered. This is surprising me as I thought it should be rendered when I loaded the webview.
The problem is that for the user, a very small white line is displayed and then this line adjust itself to match the webview settings.
If I fix the width in the CSS, I don't have any rendering problem. But I cannot do that as I want to match all screen sizes.
There was no problem before Android 4.4 as there was nothing displayed on screen until CSS was fully rendered.
By the way, I was using the setPictureListener() method from the webview. I know that this method is deprecated (and obsolete for a while), but it was the only way to know when the webview had really finish to be "drawn" on screen. If I use this method in Android 4.4, it is called many time and this error comes up in DDMS :
W/UnimplementedWebViewApi(23891): Unimplemented WebView method run called from: android.os.Handler.handleCallback(Handler.java:733)
I don't know if there is a direct relationship, I don't think so as even not using this method, my CSS is not rendered correctly.
I tried many things :
use javascript onload to make the body visible
use a chrome client on the webview and wait for progress to be at 100% to make my webview visible
use a webview client and wait for onPageFinished to make my webview visible
use a postDelayed of 500 ms when using the PictureListener to make my webview visible
use all layer type choices : HARDWARE / SOFTWARE / NONE
make my webview parent firstly INVISIBLE / GONE and then VISIBLE
but nothing worked.
It seems like the CSS is rendered only when the webview is visible for the user.
I cannot show source code as it is for professional purpose so I would only like different point of view on where I could be searching (or if someone has already see this curious error in DDMS)
Has someone an idea on how to wait for the CSS to be rendered in the webview before to display this webview ?
Many thanks
I managed to fix this problem.
I had a display: table; in the style of the main div of my HTML and removing this makes my rendering looks good.
As it was working well with Android previous version, I am not able to determine if it is a bug of the webview, or a problem in my CSS.
By the way, thanks for having a look at my problem
I am developing a mobile site, so I'm using CSS to make things as liquid as possible.
I'm having an odd difficulty. Within a div container, I have a <p> that is supposed to fill the width of the div. I've tried width:auto, width:100%...nothing seems to work on Android Browser. Here are examples:
iOS (Correct):
Android (Incorrect; not fully spreading; added more text than iOS version so you can see what I'm talking about):
Both screenshots taken from respective emulators.
Here is the odd thing, though... If I give the class applied to these <p>'s a background color, the Android browser then allows the <p> to fill the full width of its parent div (looks identical to iOS). The really odd part, though, is that if I make the background color transparent (I thought I had it tricked lol), then it goes back to doing as shown in the example.
So, I have a <p> only properly referencing its CSS if it has a background-color applied... am I stupidly overlooking something, or is this some issue with Android Browser? Any ideas how to fix it?
Thanks for your time.
While it may not be the best solution, I finally just made an "invisible" transparent png and set it as the <p>'s background, and that fixed the issue... if you can call it fixing. :) I have to assume it is some kind of error in Android's Browser, as I tried this in every browser, desktop and mobile.
It is the intended behavior of Android phones. It will enhance the readability of copy text, since you are not forced to scroll sideways if you pinch zoom the page.
It can be managed on your own phone maybe in the browser's settings, but that is not the solution you want.
It can be 'fixed' by the workaround of applying a background-image to the element you want.
This can be done with a base64 encoded data url:
background: url(data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7);
In your mobile browser's settings, look for something called "Auto Fit Pages" and disable it. This setting (in Android) is ON by default. Turn it off and your text will flow as it should.
the div or any element above this could be the issue.
if you give fixed width to the p element, does it work well ?