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)
_______________________________________________
mobile-firefox-dev mailing list
mobile-firefox-dev@mozilla.org
https://mail.mozilla.org/listinfo/mobile-firefox-dev
