Previously, everybody had to remember the preference name and the
default value. If it was ever changed, this would have to be updated
everywhere. Now, the Preferences class is responsible for talking to the
SharedPreferences functionality of ANdroid.
I've started with just the compactlayout preference, because
that is what I required for this fix.
Currently, removing the cache does the job much better. The only thing
clearing the cache doesn't do which "reset" did is removing the databases. But
we don't want to do that anyway.
If someone wants to do that, they can just deactivate or remove a repo, and it
will get wiped from the database.
Removed the license and the version info from the compact view, and
showed the description instead. The installed status, and whether the
app can be updated or not (but not which version can be updated to) is
now shown via little icons on the right hand side of the list view.
Also refactored adapters to allow different views for
Available/Installed/Updates tabs. This is because I didn't want the
"installed" status icon in the installed tab, and neither the
"installed" nor the "updates" icon in the "updates" tab.
The adapters were moved to the "views" package, because I needed to add
three new classes and they started to clutter the list of *.java files.
* Add paddings.
* Don't use hard-coded pixel sizes.
* Don't use white color directly (this would soon break the white holo theme)
* Don't use an "empty" textview to force a vertical space.
Looks much cleaner now, and the code is easier on the eyes.
"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.
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.
