After talking to some of the team leads, as well as feedback from others, we have decided to put a HOLD on this project. We will not be moving to the System Downloader in the short term.
Some reasons: 1. Maintaining two code paths is not a good use of our resources. We have plenty of other work that feels like higher priority. 2. Maintaining two code paths adds complexity. Complexity leads to bugs. Froyo's days are numbered. We can wait it out. 3. We have not fully thought out the security implications. We need to make sure we don't step in something. 4. We do not see people asking us to improve the downloader. Although I have seen people ask to change the download folder, but I digress. We need to focus on higher value tickets. We can plan on some cleanup of our existing Downloads: 1. Move forward with the Downloads.jsm backend 2. Rework the Download Manager UI (along with the Add-on Manager UI) Finkle ----- Original Message ----- > 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 ), 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 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 that we could possibly use > similar to how it is used here . 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 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
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
