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 > > > > > >
