incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: Another update to the Cordova View Branch: WebDriver Support
Date Thu, 19 Jan 2012 00:30:56 GMT

I added a couple of methods to the new CordovaView code, namely the ability
to put the assets in Jail.  There are numerous reasons that we'd want to do

1. This fixes the History Bug
2. This may make subsequent loading of the application pages faster
3. This allows us to use the HTML5 Video Tag on Android 4.x

For those of you who are unfamiliar with the jail, the Android jail is the
directory that the application has rights to.  It's where the offline
database files are stored, and is how Hydra works.  I could have lifted
that code, but instead re-wrote it and put it in the CordovaActivity.  We
may want to add it to the preferences so that you can enable putting the
app in jail on startup.  It also should be noted that clearing the cache
will also clear the application out, and a pristine app will appear from
the assets after the fact.

As usual, updates can be found here:


On Wed, Jan 18, 2012 at 11:50 AM, Joe Bowser <> wrote:

> No, but I did have to backport it and add a CallbackViewFactory. The
> latest version of WebDriver has the ability to extend custom views so that
> you can use selenium with it.  The thing is that the way you build
> WebDriver leads you to a dependency hell, where you have to include the
> jars from the latest version as well as the Android Web Driver that's
> shipped by Google.  Hopefully this gets fixed in the future so we can cut
> this down to one JAR instead of five small ones, and an external
> dependency.
> Also, in other news, I figured out what causes the failure of these URLS:
> file://android_asset/www/index.html#foo.  This code in in
> the Android Framework (around line 712):
> } else if (url.startsWith(ANDROID_ASSET)) {
>             url = url.replaceFirst(ANDROID_ASSET, "");
>             try {
>                 AssetManager assets = mContext.getAssets();
>                 return, AssetManager.ACCESS_STREAMING);
>             } catch (IOException e) {
>                 return null;
>             }
> So, when this gets passed the URL, it just takes out the android_asset
> portion, and then tries to find the file www/index.html#foo. Now, it should
> be trimming off everything that is after # or ?, however it's not.  Of
> course, it can't produce any strings, so when Chromium finally gets to it,
> it's all "WTF? Network Error!". We have the following solutions to this
> problem:
> 1. Copy all our assets to our private jail and access URLs that way
> 2. Maintain our own history
> 3. Fix Android's bug and distribute our own version of android.webkit
> I'm thinking that 1 may be the solution, but I'm going to look into this
> further.  At least we can say we test our stuff!
> On Wed, Jan 18, 2012 at 8:17 AM, Simon MacDonald <
>> wrote:
>> That's great news Joe. I had started looking into getting the
>> WebDriver working with PhoneGap back in December. Unfortunately, it
>> was horribly difficult to extend the WebDriver to take a PhoneGap
>> WebView. Looking at the stuff you were doing with CordovaView It
>> looked like it would be easier to extend the WebDriver but I didn't
>> get to it so I'm glad you did.
>> Did you need to change the WebDriver code at all?
>> Simon Mac Donald
>> On Tue, Jan 17, 2012 at 7:20 PM, Joe Bowser <> wrote:
>> > Hey
>> >
>> > I hacked together the ability to use WebDriver with Cordova.  After
>> > spending the day in dependency hell, I managed to get
>> Selenium/WebDriver to
>> > work on Android using a Custom Web View.  I have added a bunch of the
>> JARs
>> > required, some very brief instructions and an example test to the
>> > repository here:
>> >
>> >
>> >
>> > Now people can write tests for PhoneGap plugins using JUnit and
>> Selenium.
>> >  The best part about this is that once you copy WebDriver from the SDK
>> > directory to the libs, it all still works on the command line.  I'm
>> going
>> > to keep documenting the process at this point, but the ability to test
>> both
>> > the Java and the Web portions of the app at the same time is huge.  That
>> > being said, I don't like all the selenium dependencies, and I may have
>> to
>> > find a new home for the factory somewhere.
>> >
>> > Let me know if you have any questions about the tests.
>> >
>> > Joe

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message