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 >>>
