Summary time! Options for going JS->Native 1) Use prompt() (synchronous, can return values) 2) Use addJavascriptInterface() (synchronous, can return values) 3) URL interception (async)
Notes: -We are currently using #1. -According to trigger.io's blog<http://trigger.io/cross-platform-application-development-blog/2012/02/24/why-trigger-io-doesnt-use-phonegap-5x-faster-native-bridge/>, #2 is much faster but has issues on the 2.3 emulator. Going Native->JS 1) Poll using 1) from above. (async) 2) Poll using 2) from above. (async) 3) Use loadUrl (breaks keyboard) (async) 4) Trigger an online/offline event and have JS pull in value using a sync JS->Native option (async) 5) Use a local server and hanging gets (async & complicated) Notes: -We currently use a combination of #1 and #5 -#3 is faster and simpler but breaks keyboard focus Optimizations: 1) When doing any synchronous JS->Native calls, batch pending Native->JS commands with the current command's return value. 2) Batch all pending messages together when sending/pulling them (local server currently sends one at a time I think) Andrew's hopes: -JS->Native: Use #2, but leave the option to use #1. Use #2, except when on the 2.3 emulator (not sure if this is detectable) -Native->JS: Use #3+#4 so that we don't have a hard-to-get-right local server and we don't need to do polling -Implement all optimizations -Implement optimization #1 on iOS as well (except the other way around) I was planning on doing this after I close out CB-593. -Have a benchmark that can compare different messaging techniques (I just added one for iOS, should do same for Android) Andrew On Thu, Aug 9, 2012 at 6:03 PM, Jesse <[email protected]> wrote: > I published an app over the weekend for Android, and in the process I ran > an experiment. I am planning on branching to demo this, but don't have time > right now, so I thought I would explain it. > > I created a WebView, gave it an external interface via > addJavascriptInterface > > In JS, I simply had an interval firing continuously to pass any commands to > native, and the native side returned any pending results. > > There was no interference with the keyboard and the html text field > maintained focus through hundreds of calls. > > This method is absolutely simple, and can be used to move data in both > directions, with the 1 caveat that JS must pull the data from native, > because Java pushing to JS causes the issues we encountered previously. > > When I have time I will distribute a branch to demo ... > > Thoughts on this approach? > > > On Thu, Aug 9, 2012 at 2: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 > > >> >>>>> > > >> > > > > > > -- > @purplecabbage > risingj.com >
