You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Tim Lancina <ti...@drifty.com> on 2015/04/20 21:18:33 UTC
Question about bypassing the run-loop wait/entire bridge for plugins
on iOS
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
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Tim Lancina <ti...@drifty.com>.
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 <cj...@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 <cs...@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 <ti...@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 <ag...@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 <pu...@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 <ti...@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 <jb...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > ---------- Forwarded message ----------
> > > > > > > From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Connor Pearson <cj...@gmail.com>.
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 <cs...@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 <ti...@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 <ag...@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 <pu...@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 <ti...@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 <jb...@gmail.com>
> > > wrote:
> > > > >
> > > > > >
> > > > > > ---------- Forwarded message ----------
> > > > > > From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Carlos Santana <cs...@gmail.com>.
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 <ti...@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 <ag...@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 <pu...@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 <ti...@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 <jb...@gmail.com>
> > wrote:
> > > >
> > > > >
> > > > > ---------- Forwarded message ----------
> > > > > From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
> > > > >
> > > >
> > >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Tim Lancina <ti...@drifty.com>.
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 <ag...@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 <pu...@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 <ti...@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 <jb...@gmail.com>
> wrote:
> > >
> > > >
> > > > ---------- Forwarded message ----------
> > > > From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
> > > >
> > >
> >
>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Andrew Grieve <ag...@chromium.org>.
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 <pu...@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 <ti...@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 <jb...@gmail.com> wrote:
> >
> > >
> > > ---------- Forwarded message ----------
> > > From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
> > >
> >
>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Jesse <pu...@gmail.com>.
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 <ti...@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 <jb...@gmail.com> wrote:
>
> >
> > ---------- Forwarded message ----------
> > From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
> >
>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Tim Lancina <ti...@drifty.com>.
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 <jb...@gmail.com> wrote:
>
> ---------- Forwarded message ----------
> From: Jesse <pu...@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" <de...@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 <ti...@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: jbavari@gmail.com
>
Re: Question about bypassing the run-loop wait/entire bridge for
plugins on iOS
Posted by Jesse <pu...@gmail.com>.
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 <ti...@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
>