The Apple HIG has some guidelines, but essentially say "handle it properly" so that's no help. I would look at how the stock iOS apps handle it. The native ones do move down the UI, but Safari is different. Check out CB-10796, I added some screenshots.
In short -- Safari, does *not* resize the webview (it is fullscreen) On Sun, Mar 6, 2016 at 12:01 PM, julio cesar sanchez <[email protected]> wrote: > Yesterday I closed an issue because I think the plugin is working as > expected, but the user reopened it saying that I'm wrong, so I want to know > if it really works as expected or if only I expect it to work the way it > works. > The issue is this one: https://issues.apache.org/jira/browse/CB-10796 > > He is using the default value: > <preference name="StatusBarOverlaysWebView" value="true" /> > > That means the webview has the full screen size and the statusbar overlays > it. > I think we can all agree on that. > > The problem appears when the in-call or hotspot status bar appears as it > has 40 point height on iPhones. > > The user thinks that the webview should be pushed 20 points down (not 40) > because that's how it works when the plugin isn't installed or he uses > 1.0.1 version of the plugin. > > I think it shouldn't be pushed as StatusBarOverlaysWebView is true, so the > webview should be full screen, it doesn't matter if the statusbar is 20 or > 40 points. > > So, what should happen? > > 1. The webview is pushed 20 points down as the user wants > 2. The webview ins't pushed down and remains full screen as I think it > should work. > 3. The webview is pushed 40 points down as the statusbar is 40 points (I > think most native apps do this) > > > > If using StatusBarOverlaysWebView false the webview is pushed 20 points > down so the app is not hidden under the statusbar, or 40 points if the > in-call or hotspot statusbar is present --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
