Idea for how to do this without messing up regular online/offline events: 1. Have JS addEventListenter() using the capture phase 2. Poll for messages in the handler. 3. If there is a message, stopPropagation on the event. 4. Reset the state of onLine (canceling propagation of this event as well)
On Thu, Aug 9, 2012 at 5:47 PM, Joe Bowser <[email protected]> wrote: > 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 > >> >>>>> > >> >
