Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.223.175 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAE82UFYn2sUkGghWP57KXV1M-C+SGgZ5sanWQWexmgserPycVQ@mail.gmail.com>
References: 
 <CAE82UFYn2sUkGghWP57KXV1M-C+SGgZ5sanWQWexmgserPycVQ@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Mon, 30 Mar 2015 20:32:41 -0400
Message-ID: 
 <CABiQX1VvLnm8av8L5LOPj6qMZ5J8kBMUkzc86dCoutAFyXROzg@mail.gmail.com>
Subject: Re: Keyboard plugin
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec50fdfbbbdcf2405128abd78

--bcaec50fdfbbbdcf2405128abd78
Content-Type: text/plain; charset=UTF-8

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
>

--bcaec50fdfbbbdcf2405128abd78--