cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tommy-carlos williams <to...@devgeeks.org>
Subject Re: Keyboard plugin
Date Tue, 31 Mar 2015 04:16:46 GMT
+1

Also, looking forward to these posts, Kerri.

:)

-- 
tommy-carlos williams

On 31 March 2015 at 15:07:29, Kerri Shotts (kerrishotts@gmail.com) wrote:

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