cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Connor Pearson <cjp...@gmail.com>
Subject Re: Question about bypassing the run-loop wait/entire bridge for plugins on iOS
Date Wed, 22 Apr 2015 15:43:07 GMT
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 <csantana23@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 <tim@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 <agrieve@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 <purplecabbage@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 <tim@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 <jbavari@gmail.com>
> > > wrote:
> > > > >
> > > > > >
> > > > > > ---------- Forwarded message ----------
> > > > > > From: Jesse <purplecabbage@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 <tim@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
> <csantana23@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message