Carlos - Thanks for bringing me up to speed and for the heads up on the npm change. That is an awesome guide by Kerri.
Connor - Thanks for the info! Honestly our frustrations with the native resize were the main reason we decided on a different approach with the Ionic plugin. That being said, if it works in some situations maybe it's worthwhile adding in, so I'll take a look at your repo and see if I can get it working. Cheers, Tim On Wed, Apr 22, 2015 at 10:44 AM Connor Pearson <cjp...@gmail.com> wrote: > 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> > > >
