cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Connor Pearson" <cjp...@gmail.com>
Subject Re: Keyboard plugin
Date Mon, 20 Apr 2015 16:33:30 GMT
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 <kerrishotts@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 <kerrishotts@gmail.com>
> Reply: Kerri Shotts <kerrishotts@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 <agrieve@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 <cjp822@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
>>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message