[Input Requested] Handling Downloads on Froyo (2.2)
jdover at mozilla.com
Tue Feb 25 17:52:24 PST 2014
I’ve been working on offloading our downloads to use Android’s built-in download manager to gain quite a few benefits (which for brevity’s sake I won’t cover here, but you can follow the progress in bug 816318 (https://bugzilla.mozilla.org/show_bug.cgi?id=816318)), but most importantly a more consistent Android experience that users are used to.
Unfortunately, the DownloadManager system service was not available until Gingerbread so we have a few alternatives for Froyo devices that I’d like some input on:
1) Use our existing implementation that uses nsIDownloadManager
We have an existing download mechanism that works that we can fall back to for Froyo devices. We can continue shipping this as a fall back until Froyo usage (currently ~2%) has decreased enough that we drop support all-together.
There’s also been work on bug 901360 (https://bugzilla.mozilla.org/show_bug.cgi?id=901360) to transition to the newer Downloads.jsm backend that desktop uses that we could land. Benefits include putting downloads on a background thread.
2) We lift Froyo’s Download content provider from source
Froyo does have a Downloads content provider (http://androidxref.com/2.2.3/xref/packages/providers/DownloadProvider/src/com/android/providers/downloads/DownloadProvider.java) that we could possibly use similar to how it is used here (http://androidxref.com/2.2.3/xref/packages/apps/Browser/src/com/android/browser/BrowserActivity.java#2900). This would make the download for us, and then we would need to build a simple activity that simply lists the downloads and allows for opening and deleting. Unfortunately, the content provider is only available to system-level application due to a system permission (http://androidxref.com/2.2.3/xref/packages/providers/DownloadProvider/AndroidManifest.xml#10) required, so we would need to pull the entire source and get that working ourselves.
3) Combo: use nsIDownloadManager (or Download.jsm) as a backend for a Java-based view
We could continue to use our current backend implementation (including wesj’s fancy notifications) and build an activity that retrieves the download list from Gecko, removing our HTML-based view. This would provide a more consistent experience in line with what we will do on the newer devices.
My gut says we steer away from (2) as it could be a lot of code to maintain to support such a small portion of our users that already have a working implementation. But from there, I’m not sure if building a native view is quite worth the effort if we already have something that works?
Joshua Dover (jdover)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mobile-firefox-dev