Actually, that would work better than other bridges so far. How would this work with the supported online/offline event, and would this affect XHRs and other network behaviour that is happening on an interval?
On Thu, Aug 9, 2012 at 2:15 PM, Andrew Grieve <[email protected]> wrote: > 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 >> >>>>> >>
