Hey Tim, I recently did some work on the shrink view behavior for iOS. Most of the changes were pulled into the official plugin and the rest is here: https://github.com/cjpearson/cordova-plugin-keyboard
I don't know how your css animation looks, but using shrink view may have some of the same issues. I was trying to have the webview shrink as the keyboard appears, but the animation wasn't quite right. From what I could tell, the web view itself could be animated, but as soon as you start the animation, its content shrinks completely. A few people suggested solutions on Stack Overflow, but none of them worked for me. http://stackoverflow.com/q/27923648/754604 I ended up settling for the jumpy behavior and cutting out the native animation code. There may be a way to make it work using autolayout constraints instead of resizing the frame, but I believe Cordova avoids autolayout and I'm not sure what the repercussions of introducing it would be. Hope this helps Connor On Wed, Apr 22, 2015 at 9:56 AM, Carlos Santana <csantan...@gmail.com> wrote: > Hi Tim, thanks for offering help. > There are was a recent discussion in the mailing list about keyboard plugin > for iOS [1] > And Shaz posted a Blog post on the maintenance of the keyboard plugin as a > Cordova core plugin. [2] > > As some of the committers have express we think that the kyeboard plugin is > better to be a 3rd party plugin. > So I think improving the ionic keyboard plugin will be the preferred > solution, and since it's open source the better > Oh by the way ****Attention*** we moved plugins to npm [3], so grab the npm > name space for your plugin (i.e. cordova-plugin-keyboard) before some troll > does :-) > > Kerri created some examples to provide a good UX using the ionic keyboard > plugin [4], I encourage to take a look and see how the plugin can be > enhanced, and maybe some of the examples incorporated into the ionic ui > framework (i.e. directive) > > Take care and looking forward on more discussions and contributions from > ionic team ! > > [1]: http://markmail.org/thread/7vcswxfkqr67amee > [2]: > > https://shazronatadobe.wordpress.com/2014/07/09/cordova-keyboard-plugin-maintenance-update/ > [3]: > > http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html > [4]: https://github.com/kerrishotts/cordova-keyboard-example > > > On Tue, Apr 21, 2015 at 4:19 PM, Tim Lancina <t...@drifty.com> wrote: > > > Awesome, thanks guys! Yeah honestly one way to solve this particular > > problem I think is to just shrink the native view like the original > Cordova > > keyboard plugin. Speaking of which, is the Cordova keyboard plugin still > > kind of in limbo? Michal suggested to us last year that the Ionic > keyboard > > plugin use it as a dependency, but we were a lot smaller as a team and > had > > other priorities in building the framework. Now that we're a little > bigger > > and would like to invest more in the ecosystem as a whole, is there still > > any interest in having us contribute back to the official Cordova plugin? > > Or is it maybe too little too late. > > > > On Mon, Apr 20, 2015 at 7:46 PM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > > > I think Jesse pretty much covered it. > > > > > > I would be surprised if you could get web animations to be in sync with > > > native animations like the keyboard. If you are to try, I think you'd > get > > > closest by attaching a timestamp to the event you're sending to JS, and > > use > > > requestAnimationFrame to animate. CSS animations don't guarantee that > > they > > > will start right away I don't think. > > > > > > That said - yes, you should just experiment with whether using > > > stringByEvaluatingJavaScriptFromString helps at all. If it doesn't help > > > anyways though, there's no point in using it. > > > What can go wrong? > > > - possibility of deadlock, esp when JS callback tries to do an alert() > > > - does not optimized calls to exec() made from within the callback > > > - will not work out-of-the-box with WKWebView. > > > > > > On Mon, Apr 20, 2015 at 5:40 PM, Jesse <purplecabb...@gmail.com> > wrote: > > > > > > > I think you are best off to experiment and see what you can get > working > > > > consistently. The focus lately has been on the wkwebview bridge, > which > > > is > > > > entirely new, while the current webview implementation is a > collection > > of > > > > workarounds for various issues. > > > > > > > > If you can distill this down to a simple project that demonstrates > the > > > > issue, I would be happy to have a look. > > > > > > > > > > > > > > > > > > > > @purplecabbage > > > > risingj.com > > > > > > > > On Mon, Apr 20, 2015 at 3:25 PM, Tim Lancina <t...@drifty.com> wrote: > > > > > > > > > Whoops should probably have subscribed to the mailing list! > Apologies > > > if > > > > > this screws up the thread. > > > > > > > > > > Thanks for your response Jesse. The problem is knowing when to > start > > > the > > > > > css animation, hence why it would be best to be able to fire an > event > > > > > indicating the keyboard is about to show as quickly as possible. > If > > > you > > > > > wait for the run-loop, the animation will be behind by an arbitrary > > > > amount > > > > > by the time it receives the event. This isn't the end of the > world, > > it > > > > > just isn't as smooth and simultaneous as native. > > > > > > > > > > In the case of the keyboard plugin, all it does is trigger an event > > on > > > > the > > > > > document indicating the keyboard will show/hide. So if I'm > > > understanding > > > > > correctly, it would be better to leave the default evalJS > > > > > scheduledOnRunLoop:YES call because the handlers for those events > > fired > > > > by > > > > > the plugin could in theory result in more calls to native, correct? > > > > > > > > > > I suppose we could fire one event immediately, with the stipulation > > > that > > > > > handlers for the event shouldn't trigger any native calls, and > > another > > > > > marginally slower, 'safe' event that could be used in most > > > circumstances. > > > > > > > > > > If I'm making any false assumptions or overlooking something, > please > > > let > > > > me > > > > > know! > > > > > > > > > > Best, > > > > > Tim > > > > > > > > > > On Mon, Apr 20, 2015 at 4:45 PM, Josh Bavari <jbav...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > From: Jesse <purplecabb...@gmail.com> > > > > > > Date: Mon, Apr 20, 2015 at 1:39 PM > > > > > > Subject: Re: Question about bypassing the run-loop wait/entire > > bridge > > > > for > > > > > > plugins on iOS > > > > > > To: "dev@cordova.apache.org" <dev@cordova.apache.org> > > > > > > > > > > > > > > > > > > If you can be sure that your calls into js will not result in > more > > > > calls > > > > > > back to native, then it is probably fine. Delegating back to the > > main > > > > > > thread may have similar performance trouble though ... > > > > > > > > > > > > For this specific case, can't you use a timed css animation that > > > > matches > > > > > > the keyboard animation? > > > > > > > > > > > > > > > > > > > > > > > > @purplecabbage > > > > > > risingj.com > > > > > > > > > > > > > > > > > > On Mon, Apr 20, 2015 at 12:18 PM, Tim Lancina <t...@drifty.com> > > > wrote: > > > > > > > > > > > > > Hey Andrew, > > > > > > > > > > > > > > Just had a quick question about plugins on iOS. For the > keyboard > > > > > plugin > > > > > > > we're using evalJS to fire an event when the keyboard shows, > > which > > > by > > > > > > > default waits for the run loop to cycle before executing any > JS. > > > My > > > > > > > question is, would terrible things happen if we didn't wait, or > > > even > > > > > just > > > > > > > went straight stringByEvaluatingJavaScriptFromString? I can > see > > > from > > > > > the > > > > > > > commented code ( > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVCommandDelegateImpl.m#L83 > > > > > > > ) > > > > > > > that there are certain scenarios where it looks like you need > to > > > > wait, > > > > > > but > > > > > > > was wondering if those are extreme edge cases or regular > > > occurrences. > > > > > > > > > > > > > > The reason I'm asking is that we had someone bring up an issue > on > > > the > > > > > > Ionic > > > > > > > issue tracker about getting the keyboard plugin to fire quickly > > > > enough > > > > > so > > > > > > > they could animate an element along with the keyboard animation > > > like > > > > on > > > > > > > native. The issue is here: > > > > > > https://github.com/driftyco/ionic/issues/3537, > > > > > > > but I was hesitant to give them a definitive answer on either > > > > bypassing > > > > > > the > > > > > > > wait or not. It would also be nice to update the plugin if > > > bypassing > > > > > the > > > > > > > wait isn't an issue in most cases. > > > > > > > > > > > > > > Cheers, > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > "Clear thoughts produce clear results." > > > > > > Josh Bavari > > > > > > Application Developer > > > > > > Phone: 405-509-9448 > > > > > > Cell: 405-812-0496 > > > > > > Email: jbav...@gmail.com > > > > > > > > > > > > > > > > > > > > > > > > -- > Carlos Santana > <csantan...@gmail.com> >
