Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of kerrishotts@gmail.com
 designates 209.85.213.171 as permitted sender)
Date: Mon, 30 Mar 2015 23:05:19 -0500
From: Kerri Shotts <kerrishotts@gmail.com>
To: dev@cordova.apache.org
Message-ID: <etPan.551a1cff.6b8b4567.592f@Kerris-MacBook-Pro.local>
In-Reply-To: 
 <CABiQX1VvLnm8av8L5LOPj6qMZ5J8kBMUkzc86dCoutAFyXROzg@mail.gmail.com>
References: 
 <CAE82UFYn2sUkGghWP57KXV1M-C+SGgZ5sanWQWexmgserPycVQ@mail.gmail.com>
 <CABiQX1VvLnm8av8L5LOPj6qMZ5J8kBMUkzc86dCoutAFyXROzg@mail.gmail.com>
Subject: Re: Keyboard plugin
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="551a1cff_327b23c6_592f"

--551a1cff_327b23c6_592f
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I noticed this, actually, when working on one of my last books =E2=80=94 =
the fix (or, hack, rather) was to install the plugin from a specific comm=
it that didn=E2=80=99t bail if it thought iOS shrunk the view. It was fru=
strating at the time, but I have since changed my opinion of KeyboardShin=
ksView =3D true, on iOS anyway: that=E2=80=99s just not how most native a=
pps on iOS work.

Typically, the size of the view never changes when the keyboard appears =E2=
=80=94 if you have a view with a tab bar at the bottom of the view and th=
e keyboard pops up, the tab bar doesn=E2=80=99t animate upwards =E2=80=94=
 it stays behind the keyboard and never budges. Instead the content area =
compensates by allowing additional scrolling. If you have a translucent k=
eyboard (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=E2=80=99s not the way native apps usual=
ly behave.

I=E2=80=99m exploring various options, but I=E2=80=99m getting the most n=
ative behavior by using a combination of the ionic keyboard plugin with s=
crolling disabled while the keyboard is visible. Because the height of th=
e 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 hei=
ghts). This was broken in an earlier version of the plugin (wrong heights=
 returned), but as of the current version of the plugin, the heights appe=
ared to be reported correctly. It=E2=80=99s a bit more work on the dev=E2=
=80=99s part, and the plugin doesn=E2=80=99t 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=E2=80=99m working up some =
examples that I=E2=80=99ll post soon that demonstrate how it works.

So, my personal preference would be to keep this out of core =E2=80=94 if=
 a dev wants the shrinkView behavior, they can use a plugin that supports=
 it.


=46rom:=C2=A0Andrew Grieve <agrieve=40chromium.org>
Reply:=C2=A0dev=40cordova.apache.org <dev=40cordova.apache.org>>
Date:=C2=A0March 30, 2015 at 7:33:28 PM
To:=C2=A0dev <dev=40cordova.apache.org>>
Subject:=C2=A0 Re: Keyboard plugin =20

I definitely agree that KeyboardShrinksView makes a tonne more sense for =
=20
apps (as opposed to webpages), and it's what we use on Android. Shame the=
y =20
reversed the decision (I didn't actually realize that). =20

One reason to keep it as a plugin is that the logic seems to be hard to g=
et =20
right and so needs to be tweaked frequently. Plugins let you iterate fast=
er =20
than if it were built-in. =20

Still, I think we're hoping to reduce the number of plugins that we =20
maintain as a part of the core Cordova project, since we really don't do =
a =20
great job at giving them the attention that they deserve (just have a loo=
k =20
at all the unaddressed PRs against them). =20

One of the intended goals (at least IMO) of moving plugins to npm and =20
npm-style-naming, is to make less distinction between =22core=22 cordova =
=20
plugins and community-maintained plugins, so that the higher-quality =20
community-maintained plugins get more usage. =20

Interested in what others think. =20

On Mon, Mar 30, 2015 at 1:07 PM, Connor Pearson <cjp822=40gmail.com> wrot=
e: =20

> Hi All, =20
> =20
> It's been a while since the keyboard plugin was discussed. As I underst=
and =20
> it, the plugin was moved to Cordova labs after iOS 7 made =20
> KeyboardShrinksView the default behavior. Since iOS 7.1 and 8 have reve=
rsed =20
> this decision, could we revisit this=3F =20
> =20
> I've done some work to re-enable KeyboardShrinksView for iOS > 7.0 and =
fix =20
> some bugs, but is there any support for continuing to maintain this plu=
gin=3F =20
> If not, is there any way to merge the KeyboardShrinksView preference ba=
ck =20
> into cordova-ios=3F I think it's more commonly used and much more stabl=
e than =20
> the HideKeyboard=46ormAccessoryBar preference. As a Cordova user, our a=
pp =20
> depends on the shrink view behavior. Any thoughts=3F =20
> =20
> Thanks, =20
> Connor =20
> =20

--551a1cff_327b23c6_592f--