Third Party WebViews on Android

I’ve gone over the Android WebView numerous times throughout the years, complaining about performance, and about various browser bugs that never seem to be fixed. In addition, there have been numerous people implementing third party WebViews using bundled versions of Chromium, and in Mozilla’s case, a bundled version of Gecko. That being said, until now you would have to use a whole new fork of Apache Cordova, which often were behind existing versions of Chrome.

On the Apache Cordova project, we decided that it’s not a good idea to get into the browser business, and instead that we should allow people to have a choice in web rendering engines so that they can be installable like plugins. We’re not quite there yet, but that was the thought process behind this new proof-of-concept.

Corodva Android: https://github.com/infil00p/cordova-android/tree/pluggable_webview
Crosswalk Example Engine: https://github.com/infil00p/cordova-crosswalk-engine (requires the crosswalk core library)

Currently only have Crosswalk implemented to work with this, but hopefully GeckoView will soon be added as well, as well as a Chromium view from Google that’s decoupled from the default WebView. There are some downsides to this approach, such as:

  • Third Party Libraries make applications larger – A crosswalk version of Mobile Spec currently weighs in at 54.95 MB
  • Third party webviews aren’t always on – Android WebView is already initalized, and is starts quickly. A third party webview may be slower to start.
  • Third Party webviews have their own bugs

The goal of this change is to promote choice and to allow for users to use whichever rendering engine they feel works best for their project. Despite the flak that the Android WebView currently gets, there are a LOT of projects where it’s far more appropriate than Crosswalk. Ideally, we would like to see more choices for developers.

Introducing Cordova 3.0.0 for Android

Once again, it’s time for another release of Cordova, this time Cordova 3.0.0.  This is a major update and a major departure from the previous release in that there is only a single built-in plugin, the App plugin, which deals with Android-specific methods such as allowing the user to override the back button and clear the cache.  All the other plugins are now broken out into their own repositories.   More details can be found here.

In addition, the workflow has changed for producing an application.  Instead of downloading the applications, Cordova can now be downloaded using the Node Package Manager (npm).  This is an optional change, since many users who have existing projects, and existing Java code may choose to not use this system.  We’re also using other tools, such as plugman, to help with this task.

To take an existing Cordova-Android project to 3.0.0, you can run the update script to replace the JAR and the Javascript file, but then you also have to install the existing plugins that you may be using, such as geolocation.  Information for plugman can be found here.  This does require checking out the plugins, and this may be extra work, but it does offer the benefit of not having to ship a bunch of extra APIs with your app that you’re not using, such as Device info or Accelerometer.

If you’re not keen on upgrading to 3.0.0, we still are supporting and backporting fixes to 2.9.0.  However, we feel that the ability to control which APIs that you ship with your application is a worthy enough change that you’ll want to upgrade to this new version.

Introducing Cordova 2.9.0 for Android

We just finished the last minor release of the 2.x series of Apache Cordova, Apache Cordova 2.9.0.  This release features the following changes and fixes:

  • No more dependencies on Apache Commons-Codec
  • CB-3902: Market URIs now work every time in the WebView
  • Pre-Honeycomb Devices will no longer get errors with WebResourceResponse
  • Wait for Emulator works with the Android CLI scripts
  • Strange issue with Javascript being improperly executed through loadUrlIntoView causing crashes has been resolved

This was mostly a maintenance release, and no new features were added.  Right now, we’re going to be moving most of our features to 3.0 and beyond, and that this branch will only have bug fixes.  Also, since this is the last 2.x minor release, any future releases on the 2.9 branch will be patch releases only (2.9.1, 2.9.2, etc).

Once again, this is the LAST RELEASE before 3.0.0, and 3.0.0 will be radically different than 2.x.  While we hope that people migrate to the new 3.0 version of Cordova, we do understand that people will want to use this for a while.  I recommend moving all plugins to the new CordovaPlugin API so that they work with 3.0 and beyond.

config.xml changes for iOS and Android

Ever since PhoneGap 2.0, we have been trying to migrate to the W3C Widget Specification so that Apache Cordova’s configuration would be more in line with the configuration found in PhoneGap Build, just to provide one example. The new format that we will be migrating to for PhoneGap 3.0 may be a surprise, but it’s relatively easy to migrate to the new format.

widget vs cordova:

Since we are adopting the widget specification, the document must be a widget document, as specified as this header:

<widget xmlns = "http://www.w3.org/ns/widgets"
id = "io.cordova.helloCordova"
version = "2.0.0">

There are other tags such as description, and author that are mostly ignored by the current Android implementation. The first relevant tag is the access tags for whitelisting:

Whitelisting:

Currently, we only whitelist http and https sites, and we do not support specifying a port in the whitelist. The whitelist looks like this:

<access origin="cordova.apache.org"/>

or

<access origin="*.apache.org"/>

or

<access origin="apache.org" subdomains="true">

Content:

The start page is specified in this document, Cordova Android and iOS supports both local and remote documents:

<content src="index.html" />

or:
<content src="http://mysite.com/index.html" />

Preferences:

The preferences may or may not be platform-specific, and consist of name/value pairs. More information can be found in our Cordova Documentation:

<preference name="loglevel" value="DEBUG" />

Features:

Instead of specifying a plugin, we now specify features and the platforms that they are associated with, for example:

<feature name="Echo">
<param name="android-package" value="org.apache.cordova.Echo"/>
<param name="ios-package" value="CDVEcho"/>
</feature>

In the above example, we are migrating the Echo plugin over to Android and iOS. The feature is called Echo across all platforms, so this is the feature name. If you have a plugin that has a different name across platforms, each of them will need their own feature tags. The following child tags indicate where each type of package could be found. On Android, Cordova Plugins are Java classes, so the full class name, including the namespace belongs in the value. On iOS, Cordova Plugins are Objective-C classes, so you would only use the class name as the value.

There are additional features in the config.xml, but this should cover the basic ones that you will need when migrating from the old format. More information can be found in our documentation.

Death to setProperties

One pet peeve of mine with Cordova was the fact that to do certain things, you still had to set certain properties such as splashscreen, timeouts and other minor details. These APIs traditionally only had documentation at the top of DroidGap.java, which is not a really intuitive place for documentation. Also, having to edit Java code just to do basic things means that we kind of failed at the whole HTML/Javascript based app thing, so we decided to move everything to config.xml and to get rid of this so that things are easier.

So, we replaced things like:

super.setIntegerProperty("splashscreen", R.drawable.splash);

with:


<preference name="splashscreen" value="splash" />

Now, we already did this change, but you may have noticed that setIntegerProperty and the other setProperty methods still work, but if you ever looked at your logcat, you should see this message:


Setting integer properties in CordovaActivity will be deprecated in 3.0 on July 2013, please use config.xml

We’re not kidding. This is one of the things that will break when 3.0 comes out. If you haven’t moved your preferences to config.xml, do so now while you have the chance. We’re not going to do what we did with plugins and create a shim for this. We will have a full write-up about config.xml soon, but this is important, because if this change isn’t made, your application will break and we will close every bug related to this with “Won’t Fix”. Since config.xml is actually documented, we feel that this is a major improvement that’s been out in the wild for a while. setProperty was terrible, and should have been removed a while ago, and I’m really glad today that we’re able to move people over to this new way of setting Cordova properties.

Please keep reading the PhoneGap Blog for new updates about what is coming up for Cordova 3.0. We will have more posts landing there soon.

Introducing Cordova 2.8.1 on Android

A little less than two months ago, we improperly deprecated the Plugin API for Cordova Plugins. The reason for this was to move from the old architecture to the new one. However, it seems that once again that people ran into problems with this because we didn’t publish the changes on the blog, and only put them on our deprecation page in the wiki.

Because this change caught a lot of people by surprise, we’re going to re-introduce Plugin.java back for 2.8.1 and 2.9.0. We will not support these plugins in the upcoming 3.0 release, and we expect that plugin maintainers will update their plugins and conform to the new plugin spec that we are working on if they want users to actually use their plugins with new tools that are appearing in new releases. Currently there are way too many plugins that don’t work with the current version of Cordova. There will be more updates about the new updates to Cordova, but for those people who are unwilling or are unable to write the Java code required to upgrade plugins, we put it back. However, this is temporary and your old plugins WILL NOT WORK with Cordova 3.0.

Furthermore, the 2.9.0 release will be a long-lived release and will be the last release of 2.x Cordova. All versions of Cordova after 2.9 will have their plugins removed, and will depend on the new plugman tool. This is done so that apps that don’t need things like GPS or Accelerometer don’t have that extra code kicking around.

Finally, there is one other change in 2.8.1, which is the update script. The update script was created from the create script, and contained a major bug where it deleted projects that made it not suitable to be used by anyone, and unfortunately we didn’t catch it until now. It’s now been fixed and the update script should work, but I recommend reading the scripts before using them. Fortunately, it only affected Linux and MacOS X users, and Windows is unaffected by this change.

Cordova-Android 2.8.1 will be included in the 2.8 download package from phonegap.com, so I highly recommend downloading and updating to the latest version from 2.8.0 and lower.

What’s new for Cordova 2.8.0 on Android

As we’re ramping up to the 3.0.0 release of Cordova, there haven’t been massive sweeping changes on Cordova, but mostly minor ones. The major change is now that cordova.js no longer has a version, which should make upgrading the js easier. Here’s some more things that are new:

  • config.xml is now much noisier when you use the old tag
  • CordovaActivity is replacing DroidGap. This is actually a minor renaming, but we do plan on getting rid of the empty DroidGap class post-3.0 and this will break things. This is done to further discourage people from putting all the code in DroidGap and to give Android Developers a better idea of what DroidGap actually is.
  • 9-patch Splashscreens once again work on Android

Again, this is a relatively uneventful release, AFAIK. One thing that we didn’t do well was announce the updates to the Plugin API. These were updated earlier in the year, and should have been announced, however I’m having a difficult time finding the announcement. What I do recommend people do is check out Simon’s “Why don’t my plugins work in PhoneGap?” post. We’re getting better announcing what we are deprecating, but occasionally things like this happen, which I apologize for.

What’s new for Cordova 2.7.0 Android

Another month rolls by, and as usual, another release of Cordova happens. Some of the big highlights this month are as follows:

  • Camera.getPicture() is fixed for Picasa images
  • Plugin.java is deprecated for CordovaPlugin, plugins must be updated to support this change. This has followed our deprecation policy.
  • device.name has been removed, since it’s useless on most Android devices, and doesn’t make sense on iOS
  • Plugins can now intercept URLs with question marks, number signs and escaped spaces.
  • URL parsing is now more robust
  • localStorage is once again persistant, this breaks WebSQL on Android 4.x

The last change is the most irritating and is one that we’re currently struggling with. Many people use WebSQL in their applications. The problem with this is that it’s not a supported W3C specification, and as such is something that not every platform supports. On Android 3.x and up, the Android team made it so that file URIs can’t open databases. A workaround from the early days of Cordova was used to get around this issue, but there are numerous design issues, and this isn’t guaranteed to work the same way as WebSQL. This is why, for now, we recommend that people use the WebStorage APIs instead of WebSQL, because it is supported across platforms, and is much less likely to break. And even when WebStorage does break, we will fix WebStorage, even if it means breaking WebSQL.

There is a proposed fix for WebSQL where Cordova applications use a different URI scheme, but that may not be implemented until after 3.0 is released. In the meantime, we recommend that other alternatives be used, but we recommend WebStorage. We apologize for the inconvenience since this is something that is beyond our control.

Froyo and the Deprecation Policy

I am pleased to announce that in Apache Cordova 3.0, we will no longer be supporting Android 2.2 Froyo. While this probably doesn’t actually affect to many people, this does mean that we are going to be able to get rid of our one dependency. We’re already getting rid of support for Android 2.1 and Honeycomb in Cordova 2.7.0 as well.

What does this mean?

This means that things might still work for you, but if something breaks, we will close your ticket as “Won’t fix”. Most Android tablets have upgraded to Ice Cream Sandwich or later, so unless you have that rare Google IO Samsung Galaxy Tab 10.1 that you didn’t bother rooting, you’re probably not running this version of Android. Now, since Honeycomb and later versions of Android share a lot of the same properties, chances are that things may still work, but I wouldn’t bet on it. As far as Android 2.2 and lower, we plan on actually removing the commons-codec library. Right now, because we’re an Apache project, we have to have a script fetch that Apache project’s binary separately so that our image handling would work. Removing the dependency means that it’s one less binary we have to fetch and one less moving part.

Why the change in the Deprecation Policy?

When we decided to drop support for Android 2.1 and 3.x, we did the six month wait. This basically meant maintaining code that nobody was going to use for another six months because of policy. We felt that this was too limiting, and decided to move to it being released based instead. We didn’t feel that it added to the stability of the project, but we wanted to avoid the breakage that happened when we introduced CordovaWebView.

When will you be dropping Gingerbread?

We drop Android versions once they get below 5% of the user base. Gingerbread is still at 45%, and there are still new low-end Android devices that are sold with Gingerbread, so we will be supporting that for quite a while yet.

What’s new for Cordova 2.6.0 on Android

This the first time that I’ve done the “What’s new with Cordova” blog post. This release was mostly a bug fixing release, but we did manage to resolve many issues that were long standing with the Camera. This is mostly based on the GitHub changelog:

  • CB-1700: EXIF information is now preserved on images taken from the Camera and the Gallery
  • CB-1796: captureImage now can save a copy of the photo to the gallery
  • CB-2305: InAppBrowser now has an API for executing scripts and inserting CSS
  • CB-1933: Changed button labels to an array for notifications!
  • New Native to JS bridge for Binary Strings!

Also, this is the last release that will be supporting Android 2.1 and the Honeycomb releases. Cordova may still work with these versions of Android, but we will be closing all issues related to Android 2.1 and Android 3.x as “Won’t Fix”. We have first announced this change six months ago, and this shouldn’t affect most users since is currently only 1.8% of all Android devices currently in the wild. We are currently discussing deprecating Froyo as well, since it is only 4% of all Android devices, but any future changes to support will be discussed on the Apache Cordova developer list, and will be subject to our deprecation policy.