cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [Android] New Bridge: evaluateJavascript
Date Thu, 10 Mar 2016 23:48:40 GMT
I didn't say it was a private API what I meant is that based on what you shared that this Will
be a new public API another bridge people can use with the current API not broken. 

So a minor bump on the version is OK

- Carlos
@csantanapr

> On Mar 10, 2016, at 4:03 PM, Joe Bowser <bowserj@gmail.com> wrote:
> 
> Well, If they add the method, the latest version of their plugin should
> still work with older versions of Cordova.  So, is this really the same
> thing?
> 
> On Thu, Mar 10, 2016 at 12:18 PM, Simon MacDonald <simon.macdonald@gmail.com
>> wrote:
> 
>> I think we are okay bumping the minor for this change not the major.
>> 
>> I'm in favour of this bridge as long as we don't need to guard all the code
>> with reflection. Using reflection to call evaluateJavascript would negate
>> any performance bonus. So if we can use evaluateJavascript on Android 4.4
>> and above and then revert to LoadUrl on Android 4.3 and earlier for this
>> bridge I say we go for it.
>> 
>> I think we can give CrossWalk enough time so this doesn't completely screw
>> them over. Also, if we give them a heads up they can make it so the plugin
>> only installs on Cordova Android 5.1.1 and earlier.
>> 
>> 
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>> 
>>> On Thu, Mar 10, 2016 at 2:51 PM, Joe Bowser <bowserj@gmail.com> wrote:
>>> 
>>> On Thu, Mar 10, 2016 at 11:48 AM, Carlos Santana <csantana23@gmail.com>
>>> wrote:
>>> 
>>>> I don't think we need to bump major number, there is no public API
>> brake
>>> This isn't a private API.  This API is how third parties like Intel can
>>> make things like Crosswalk.
>>> 
>>> 
>>>> we are just added a feature, old stuff will still work.
>>> 
>>> Except that Crosswalk now has to implement evaluateJavascript on their
>>> XWalkEngine class.  At least this won't need a crap ton of reflection
>> code
>>> like the last API change.
>>> 
>>> 
>>>> 
>>>>> On Thu, Mar 10, 2016 at 2:41 PM Joe Bowser <bowserj@gmail.com>
wrote:
>>>>> 
>>>>> Well, since the problem is with ONLINE_EVENT having a race condition,
>>>>> earlier versions of Android would have to use the slower LOAD_URL
>> with
>>>>> known issues related to the input fields.  There's more testing that
>>>> needs
>>>>> to be done, obviously, but it's worth adding the third bridge in the
>>> next
>>>>> major release.
>>>>> 
>>>>> I'm just wondering how people feel about bumping another version.  I
>>>> don't
>>>>> think our users understand that we use semver at all, which makes
>>> things
>>>>> extremely frustrating.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Mar 10, 2016 at 11:30 AM, Carlos Santana <
>> csantana23@gmail.com
>>>> 
>>>>> wrote:
>>>>> 
>>>>>> But what about 4.3 and lower versions of Android? How do we support
>>>> them?
>>>>>> Do we use ONLINE_EVENT if we detect were are running on those
>>> versions
>>>> of
>>>>>> Android?
>>>>>> 
>>>>>> 
>>>>>> On Thu, Mar 10, 2016 at 1:36 PM Joe Bowser <bowserj@gmail.com>
>>> wrote:
>>>>>> 
>>>>>>> So, apparently some people are reporting that the ONLINE_EVENT
>>> bridge
>>>>>> that
>>>>>>> we currently use by default in Android has a race condition when
>>> you
>>>>>> start
>>>>>>> using more than one WebView in an application.  Even though we
>>>> decided
>>>>> to
>>>>>>> not support the case of having multiple webviews in an
>> Application,
>>>>> it's
>>>>>>> still being used this way.
>>>>>>> 
>>>>>>> Ideally, I would like to see us figure out how we can change
the
>>>> bridge
>>>>>>> modes so that we don't have so many static classes, or at least
>>>> change
>>>>>> them
>>>>>>> such that we're not tracing mutable states in static classes.
>>>> However,
>>>>>>> someone asked about evaluateJavascript and using that for the
>>> bridge.
>>>>> I
>>>>>>> implemented that really quick here:
>> https://github.com/infil00p/cordova-android/tree/building_bridges
>>>>>>> 
>>>>>>> Basically, this should get around the whole bridge state problem
>>>> since
>>>>>>> we're executing the JS on the right webview every time instead
of
>>>>> trying
>>>>>> to
>>>>>>> manipulate a static variable that may or may not correspond to
>> the
>>>>>> webview
>>>>>>> that we're using.  Also, the benchmarking on this initially seems
>>>>>>> comparable to ONLINE_EVENT.
>>>>>>> 
>>>>>>> There's also the fact that it's a lot less code than
>> ONLINE_EVENT,
>>>> due
>>>>> to
>>>>>>> the whole state thing.  The main thing that ONLINE_EVENT has
over
>>>>>>> evaluateJavascript is that it works on Jellybean (4.3 and lower).
>>>>>>> 
>>>>>>> This branch does add a method to the API, and Crosswalk would
>> have
>>> to
>>>>> add
>>>>>>> the same two lines of code to their WebView to allow
>>>> evaluateJavascript
>>>>>> to
>>>>>>> work there as well as it does here.  I did check to make sure
>> their
>>>> API
>>>>>>> does support it before I added it.
>>>>>>> 
>>>>>>> So, is this useful? Should we merge it in? Do we increment a
>> major
>>>>>> version
>>>>>>> number for this?
>>>>>>> 
>>>>>>> Joe
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message