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>
