How about this for a possible work-around: When the keyboard is up, use WebView.setNetworkAvailable() to trigger an online/offline event in the JS, and then have the JS poll on online/offline events.
Demo of this working here: https://github.com/agrieve/incubator-cordova-android/commits/testbridge Andrew On Tue, Aug 7, 2012 at 10:09 AM, Simon MacDonald <[email protected]>wrote: > We need to do something as it would not be good if we missed an > online/offline event while the user was typing in a text field. > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Wed, Aug 1, 2012 at 7:10 PM, Joe Bowser <[email protected]> wrote: > > I like the latter. It really should be up to the developer of the > > plugin whether they're discardable or not. > > > > So, would this make sense to be an option in 2.1? > > > > On Thu, Jul 26, 2012 at 10:51 PM, Jesse MacFadyen > > <[email protected]> wrote: > >> We could add a lifecycle event, just like pause/resume so each plugin > >> could react accordingly. > >> ie FileTransfer would discard progress events, but queue the complete > event. > >> > >> As an alternative, plugin results could have a property which > >> indicates if they are discardable. > >> > >> Cheers, > >> Jesse > >> > >> > >> > >> On 2012-07-26, at 10:10 PM, Joe Bowser <[email protected]> wrote: > >> > >>> It depends. For accelerometer, it may not make sense since it would > >>> just plow a series of events over and over again, and we only care > >>> about the current acceleration, which would be fired on the interval. > >>> Basically, we still have the same problem, except that we break the > >>> native callout instead of the keyboard, which is the lesser of the two > >>> evils. If someone wants both to work, we'll have to either do polling > >>> or go back to the Callback Server. > >>> > >>> But yeah, it would be great if we can send something from Java back to > >>> Javascript without it blocking. > >>> > >>> On Thu, Jul 26, 2012 at 7:56 PM, Simon MacDonald > >>> <[email protected]> wrote: > >>>> Okay, I'm working off 4 hours of sleep so if what I say is not > coherent > >>>> bear with me. I looked over the code you posted up and it looks like > if you > >>>> are in a text field the request to loadUrl is lost. Does it make > sense to > >>>> queue up these requests and process them once the user is outside of > the > >>>> text field? > >>>> > >>>> Simon Mac Donald > >>>> http://hi.im/simonmacdonald > >>>> > >>>> > >>>> On Thu, Jul 26, 2012 at 6:44 PM, Joe Bowser <[email protected]> > wrote: > >>>> > >>>>> Hey > >>>>> > >>>>> So, on ICS and greater, it turns out that the routing table is > >>>>> fragile, so fragile in fact that you can't connect to localhost if > you > >>>>> don't have an internet connection of some sort. This is a problem > for > >>>>> us on Android because we need to connect to localhost to use the > >>>>> bridge and communicate with the Callback Server so that we can get > the > >>>>> callbacks. In my opinion, this is the straw that broke the camel's > >>>>> back, and this bug is far worse than the reason we moved to the > >>>>> CallbackServer to begin with. > >>>>> > >>>>> First, some history: > >>>>> > >>>>> Back in OSCON 2010, we talked to Justin at Google about how they > could > >>>>> help PhoneGap, and he mentioned that we shouldn't be using loadUrl > for > >>>>> sending Javascript over because it is linked to the Handler and can > >>>>> interrupt the UI thread. He suggested a callback server, which Bryce > >>>>> implemented. The callback server and sending commands over the > prompt > >>>>> happened at roughly the same six months, when Gingerbread was being > >>>>> rolled out. > >>>>> > >>>>> Now, in 2012, we are starting to have issues with the Callback Server > >>>>> approach, and we should examine why we did this in the first place. > >>>>> The test case for it is simple: > >>>>> > >>>>> 1. Put an input field on the accelerometer page on Mobile-Spec > >>>>> 2. Turn on Accelerometer > >>>>> 3. Try to type something > >>>>> > >>>>> What it will do is it will update the accelerometer values as you > type > >>>>> text. This is awesome, but I'm wondering if anyone is actually going > >>>>> to use this use case, and if it's OK to break this functionality in > >>>>> exchange for performance and stability. We currently have the > ability > >>>>> to use loadUrl("javascript:foo()") again by checking whether we have > >>>>> focus on a text field, which we can use with HitTestResult, which > >>>>> inspect's webkit's cursor. This would fix the bug that I call > >>>>> "Airplane, Airplane Crash" where you can crash our bridge by > switching > >>>>> your phone in and out of airplane mode over and over again. I have a > >>>>> test repository here, and it passes most of Mobile Spec. It would be > >>>>> nice to be able to have this as a configurable option to start. > >>>>> > >>>>> https://github.com/infil00p/callback-android/tree/testbridge > >>>>> > >>>>> Any thoughts? > >>>>> > >>>>> Joe > >>>>> >
