I noticed this, actually, when working on one of my last books — the fix (or, hack, rather) was to install the plugin from a specific commit that didn’t bail if it thought iOS shrunk the view. It was frustrating at the time, but I have since changed my opinion of KeyboardShinksView = true, on iOS anyway: that’s just not how most native apps on iOS work.
Typically, the size of the view never changes when the keyboard appears — if you have a view with a tab bar at the bottom of the view and the keyboard pops up, the tab bar doesn’t animate upwards — it stays behind the keyboard and never budges. Instead the content area compensates by allowing additional scrolling. If you have a translucent keyboard (like from the home screen), this is most apparent (you can still tell the content exists below the keyboard. So although convenient, it might also be why Apple removed this behavior in later iOS versions: because it’s not the way native apps usually behave. I’m exploring various options, but I’m getting the most native behavior by using a combination of the ionic keyboard plugin with scrolling disabled while the keyboard is visible. Because the height of the keyboard is passed to the event handler, I can then adjust the size of any scroll containers (either by adding padding or by adjusting their heights). This was broken in an earlier version of the plugin (wrong heights returned), but as of the current version of the plugin, the heights appeared to be reported correctly. It’s a bit more work on the dev’s part, and the plugin doesn’t work perfectly in all cases (having a hardware keyboard attached still returns an incorrect height). But the feeling is so much closer to native. I’m working up some examples that I’ll post soon that demonstrate how it works. So, my personal preference would be to keep this out of core — if a dev wants the shrinkView behavior, they can use a plugin that supports it. From: Andrew Grieve <agri...@chromium.org> Reply: dev@cordova.apache.org <dev@cordova.apache.org>> Date: March 30, 2015 at 7:33:28 PM To: dev <dev@cordova.apache.org>> Subject: Re: Keyboard plugin I definitely agree that KeyboardShrinksView makes a tonne more sense for apps (as opposed to webpages), and it's what we use on Android. Shame they reversed the decision (I didn't actually realize that). One reason to keep it as a plugin is that the logic seems to be hard to get right and so needs to be tweaked frequently. Plugins let you iterate faster than if it were built-in. Still, I think we're hoping to reduce the number of plugins that we maintain as a part of the core Cordova project, since we really don't do a great job at giving them the attention that they deserve (just have a look at all the unaddressed PRs against them). One of the intended goals (at least IMO) of moving plugins to npm and npm-style-naming, is to make less distinction between "core" cordova plugins and community-maintained plugins, so that the higher-quality community-maintained plugins get more usage. Interested in what others think. On Mon, Mar 30, 2015 at 1:07 PM, Connor Pearson <cjp...@gmail.com> wrote: > Hi All, > > It's been a while since the keyboard plugin was discussed. As I understand > it, the plugin was moved to Cordova labs after iOS 7 made > KeyboardShrinksView the default behavior. Since iOS 7.1 and 8 have reversed > this decision, could we revisit this? > > I've done some work to re-enable KeyboardShrinksView for iOS > 7.0 and fix > some bugs, but is there any support for continuing to maintain this plugin? > If not, is there any way to merge the KeyboardShrinksView preference back > into cordova-ios? I think it's more commonly used and much more stable than > the HideKeyboardFormAccessoryBar preference. As a Cordova user, our app > depends on the shrink view behavior. Any thoughts? > > Thanks, > Connor >
