That was a good read. Thanks for sharing, Kerri. I'll definitely have to try it out sometime.
Also, I'm sorry if I came off negatively. I do really appreciate all the Cordova team does. :) — Sent from Mailbox On Fri, Apr 17, 2015 at 3:22 AM, Kerri Shotts <kerrisho...@gmail.com> wrote: > Well, it’s been a while, but I finally found some time to work up some > keyboard avoidance examples. > Here’s a link to the post on the forum: > https://groups.google.com/d/msg/phonegap/1nRXfhI7JtQ/ENPL-MNIadYJ, and the > corresponding repository: > https://github.com/kerrishotts/cordova-keyboard-example. > From: Kerri Shotts <kerrisho...@gmail.com> > Reply: Kerri Shotts <kerrisho...@gmail.com>> > Date: March 30, 2015 at 11:05:28 PM > To: dev@cordova.apache.org <dev@cordova.apache.org>> > Subject: Re: Keyboard plugin > 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 >>
