Rebased several months of work, and attempted to resolve any conflicts.
The conflicts were a tad more difficult than usual to resolve because they
were in files where large blocks of code were refactored into different
files, and git didn't realise.
Conflicts:
src/org/fdroid/fdroid/RepoXMLHandler.java
src/org/fdroid/fdroid/UpdateService.java
* Move it to the top right corner
* Don't let the app name overlap it
* Ellipsize version names to leave space for name
* Summary can now take two lines if it needs them
* Installed versions are now bold
When the repository is updated, it will check if the "name" or "description"
have been modified (or learnt for the first time) and if so, update the DB and UI.
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.
