Database is locked for much less time - only briefly before starting an
update sequence, and again after all downloads and parsing are complete.
Also, when the same app is defined in multiple repos, the apks are
merged rather than just having one take priority.
If an error occurred or the user cancelled the download, the message
(toast) would be redisplayed on every rotation from there on.
This change fixes the bug (by removing the reference to the download
thread when it's finished) and encapsulates all interaction with the
download thread in DownloadHandler.
Rationale:
1) The string is competing for space with the license field.
2) It would need separate singular/plural versions to be correct.
3) It's unnecessary when the list of APKs is shown directly below.
Traceview revealed that the call to DB.getApps() was by far the
slowest part of recreating the activity, followed by getPackageInfo().
By transferring the list contents and some other fields from the old
activity object, the time needed to create the new one can be
substantially reduced.
This moves the download thread from an anonymous inner class to the
class Downloader, which isn't tied to the activity.
The state of the progress dialog is updated by polling the download
thread at regular intervals - message passing seemed to need a bunch
of synchronized methods and shared variables anyway (to ensure that
all messages reached the right activity) so it was much simpler to
just take it out. But maybe my approach is completely backward.
Change the default value of the "cacheDownloaded" preference used in
the actual code to match the default value that is specified in XML
and shown to the user.
There is no point in splitting the strings ahead of time since 1) not
all strings need to be split and 2) we currently deserialize them just
as often as we iterate over them.
