Hey
I've been working on the CordovaWebView branch, and I think we need to
discuss where to put the CallbackServer and PluginManager in the new
implementation. I'm OK with it being in the view, but I did have it in the
Client before, and I'm wondering what people's thoughts are on that. Also,
si
BUMP! Are we all on board with doing this?
Joe
On Tue, Mar 27, 2012 at 1:15 PM, Joe Bowser wrote:
> Hey
>
> I've been working on the CordovaWebView branch, and I think we need to
> discuss where to put the CallbackServer and PluginManager in the new
> implementation. I'm OK with it being in th
Sorry for late reply Joe!
Looks great! As for outstanding issues as per your wiki article [1], I
would say move everything WebView related, as well as Cordova-specific
such as the plugin manager, into CordovaWebView.java. My thinking here is
that, none of scaffolding necessary to enable device API
I really haven't had time to look at this in detail, but agree that
anything related to the webview should be in CordovaWebView. As Fil
mentioned, that includes the history, plugin manager, whitelisting, &
authentication + callback server.
I assume that overriding chrome/view clients so the user
On Wed, Mar 28, 2012 at 9:09 PM, Bryce Curtis wrote:
> I really haven't had time to look at this in detail, but agree that
> anything related to the webview should be in CordovaWebView. As Fil
> mentioned, that includes the history, plugin manager, whitelisting, &
> authentication + callback serv
Yes, I meant providing your own classes that inherit from our
CordovaChrome/WebView classes.
>From what I've observed recently, addJavascriptInterface is still broken in
the emulator and on some (maybe small subset) of real phones.
On Thu, Mar 29, 2012 at 1:53 PM, Joe Bowser wrote:
> On Wed, Ma
On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis wrote:
> Yes, I meant providing your own classes that inherit from our
> CordovaChrome/WebView classes.
>
> From what I've observed recently, addJavascriptInterface is still broken in
> the emulator and on some (maybe small subset) of real phones.
>
I
+1 science
On Thu, Mar 29, 2012 at 4:33 PM, Joe Bowser wrote:
> On Thu, Mar 29, 2012 at 2:01 PM, Bryce Curtis wrote:
>
>> Yes, I meant providing your own classes that inherit from our
>> CordovaChrome/WebView classes.
>>
>> From what I've observed recently, addJavascriptInterface is still broken
OK, I published a test app on Google Play. I'll post the link once it
actually shows up. I want people to download and run it on their Android
2.3 devices to see if we can find any that crash! If so, it'll be recorded
in the Error Report. That way we can finally know is this is a real bug or
so
Very cool idea, Joe! Hopefully we will get a good response/sample size
with no failures.
On Thu, Mar 29, 2012 at 7:18 PM, Joe Bowser wrote:
> OK, I published a test app on Google Play. I'll post the link once it
> actually shows up. I want people to download and run it on their Android
> 2.3
Great idea Joe. I've got a Samsung Galaxy S running 2.3.5 so lemme
know when it is up.
But wait, isn't this a job for the PhoneGap Device Wall!
http://phonegap.com/2012/03/29/phonegaps-new-device-wall/
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Mar 29, 2012 at 8:18 PM, Joe Bowser w
We don't have enough crap Android devices running 2.3. This is to also
help us buy devices for the device wall. The application can be found here:
https://play.google.com/store/apps/details?id=com.infil00p.phoneTest
On Fri, Mar 30, 2012 at 7:11 AM, Simon MacDonald
wrote:
> Great idea Joe. I've
Installed and it looks like everything worked.
Simon Mac Donald
http://hi.im/simonmacdonald
On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser wrote:
> We don't have enough crap Android devices running 2.3. This is to also
> help us buy devices for the device wall. The application can be found her
Congrats! Your phone didn't come out of a vending machine!
On Fri, Mar 30, 2012 at 8:22 AM, Simon MacDonald
wrote:
> Installed and it looks like everything worked.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
>
> On Fri, Mar 30, 2012 at 11:02 AM, Joe Bowser wrote:
> > We don't have eno
Works here!
If exec is getting futzed with, it'd be great if at the same time, support
was added for synchronous return values when calling Java -> JavaScript.
I'm working on the android port of true native, and I'm either going to
need this support in cordova directly or in my own code.
On Fri,
The problem is that there is no mechanism for this on Android that doesn't
disrupt the UI thread.
On Fri, Mar 30, 2012 at 1:50 PM, Matthew Schulkind wrote:
> Works here!
>
> If exec is getting futzed with, it'd be great if at the same time, support
> was added for synchronous return values when c
What do you mean by disrupt exactly?
I've seen one potential solution where you basically make the javascript
call with loadUrl and then wait for a addJavascriptInterface method to be
called from the result. This waiting can happen on a non-ui thread. The
biggest problem is how long do you wait fo
Looks like addJavascriptInterface is still broken on 2.3.x emulator (not
sure about other versions). 2.3 seems to be the only version with an x86
image for using with kvm, so I expect lots of people (including me) are
using it for development. Probably best to stay away from
addJavascriptInterface
If it only is broken on the emulator, I would argue that's not a good
enough reason to stay away from using it. I would recommend that people
get a device. It's not like the devices are prohibitively expensive.
(Under $150 on DealExtreme was the cheapest I saw a 2.3 device, probably
cheaper on Cr
I'm new to android, so maybe I'm not looking in the right place, but the
only x86 image I see is for Android 2.3.3 (API 10).
Is there any gain with addJavascriptImplementation other than cleaning
things up? It'd be a shame to make things more difficult for a large number
of people for no material
I agree that emulators are not a good enough reason to implement a workaround.
Is it possible to detect these conditions and simply tell the user it
won't work?
Cheers,
Jesse
Sent from my iPhone5
On 2012-04-01, at 12:21 PM, Matthew Schulkind wrote:
> I'm new to android, so maybe I'm not look
>I agree that emulators are not a good enough reason to implement a
>workaround.
>Is it possible to detect these conditions and simply tell the user it
>won't work?
+1 to this
>
>Cheers,
> Jesse
If the problem is limited to a version of the emulator, then it's not
unreasonable to suggest that a developer simply test on another version
that works. Similarly, if that particular version must be used, then I
would expect the developer to use a real device. We could list the
emulator versions
23 matches
Mail list logo
