The problem was that since the changes to implement tab swiping and
fragments, the process for refreshing the lists was changed. The
previous infrastructure for invalidating the result of
FDroidApp.getApps() is still useful, so we presume that the list of apps
is only going to take a few cycles to return, instead of several
seconds. If it has been invalidated, so be it, we will put up with
waiting the few seconds.
"All" kinda made sense in the context of internal workings
(fetch package list from several repos, then process compatibility of
all apps), but superfluous from user's perspective.
Requires a bit of a dodgey hack because of a bug in Android,
but it gets the job done. The good thing is that the hack is
quarantined to a class specifically dealing with the ActionBar
for devices that support it, and not required for earlier
devices. In the future if the bug is fixed, it will be relatively
easy to make sure that it is only applied to the versions which
require it.
Wwhen "populatingDetails" of an app, it's now a bit more careful.
It doesn't reject future apk files just because the app has been
updated by one repository.
Changed strings.xml to reflect the multi-repo nature of updating.
Also refactored progress events to make them more generic and
easier to nest deeply down the call stack. The ProgressListener
now just expects a ProgressListener.Event, which in addition to
statically typed type and progress info, also has an associated
Bundle which can store arbitrary data.
Polls the download server before download to see how big the file is so
that we can figur eout our progress during download. Its a bit of a hit
(about 1.5 seconds on my connection), but I think most people would be
willing to take a small hit to get accurate percentage measurements.
I also spend a small amount of time (~1.5 seconds) asking how big the
file is before we download it, so that we can give an accurate
progress measurement. The same can be said for peeking into the
XML file before we pass it to the SAX parser, by just iterating
over every line looking for "<application" and counting that. It
is not perfect, and it takes about 3 seconds for 600 apps on my
crappy emulator, but the progress makes much more sense.
Refactored helper loops as per Andrew's suggestions.
Close file reader correctly.
See http://stackoverflow.com/a/6495399.
I thought that I could just wrap
API dependent code in an if statement, ant it would only have a problem
if it tried to execute a particular function at runtime. However when
testing on a 1.6 emulator, I was getting "VerifyErrors" which as the
link above suggest, are because it is verifying every statement in a
class. Refactoring out to another class solves this because it only
verifies classes which are loaded at runtime.
Also added utility method to make checking a bit easier,
and removed reference to SDK from DB (it mentioned in the
comments that SDK_INT was only available in v5, but the
Android docs say it was introduced in v4. Because FDroid
now depends on the Android support library, which in turn
depends on v4, it sould be okay to depen on this.
