Phew, monster merge. Going to commit after *seemingly* resolving
conflicts, but it will no doubt take a few compile and runs to sort out
any funny stuff.
Conflicts:
AndroidManifest.xml
res/layout/addrepo.xml
res/layout/appdetails.xml
res/layout/repolisticons.xml
res/values/strings.xml
src/org/fdroid/fdroid/DB.java
src/org/fdroid/fdroid/FDroid.java
src/org/fdroid/fdroid/ManageRepo.java
src/org/fdroid/fdroid/UpdateService.java
SwitchCompat will return a Switch or a ToggleButton depending on the
platform (doesn't matter, both are CompoundButtons) and this will be
added to the repo_item view programatically.
I'm using some pretty specific listeners
to communicate between the details fragment and the repo list activity.
I've also split the functionality (e.g. for deleting) between the repo
list and the details view. In the future, when we have content providers
for repos, it will be easier to take care of everything from the details
screen, and automatically notify the repo list of changes.
Refactored update service.
Now has a static update method that can be called which
will setup the required intent to begin the update. It also deals with
progress listeners and dialogs for the user, so all of this is moved out
of FDroid. This was so that RepoDetailsFragment can now invoke the same
functionality.
When a new repo is being added, whether manually or via an incoming Intent,
check the address and fingerprint against repos in the DB. If the repo is
not in the DB, offer to add it. If the repo address is in the DB, then do
more checks:
* If that address has no fingerprint in the DB, then offer to add the new
repo including that fingerprint. This might happen when upgrading a repo
from unsigned to signed.
* if the incoming info matches a repo in the DB, offer to enable that repo
* if the address matches a repo in the DB but the incoming fingerprint does
not match the fingerprint in the DB, warn the user, and tell them to
delete the existing repo if they truly want to override the existing info
Previously, anything added via the Add New Repository dialog would just
overwrite any existing repo config that was there. This has become a
bigger issue with the QR Code scanning since it could become an attack
vector. This is the first step towards making this Add Repo dialog give
more info to the user about the state of things, and what the user might
replace by clicking OK.
They are more consistent now. Transitioning to RTL languages will also be
easier since more of them can be mirrored now. Also fixes some spacing issues
with icons and others.
Also, move visibility stuff from onResume to onCreate (they are only affected
by preferences, i.e. onCreate will always be run since the preferences button
is only in our main activity).
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.
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.
