FWIW, I agree with the decision. --lucasr
----- Original Message ----- > From: "Mark Finkle" <[email protected]> > To: "Joshua Dover" <[email protected]> > Cc: [email protected] > Sent: Wednesday, 9 April, 2014 4:05:46 AM > Subject: Re: [Input Requested] Handling Downloads on Froyo (2.2) > > 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 > > > > > > > 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 > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
