If the device supports API level 16 (Android 4.1) then add a menu item
on the repository management screen to "Find Local Repos". Activating
this menu item will initiate NSD service discovery with the NsdHelper
class looking for 'fdroidrepo' and 'fdroidrepos' service types on the
local network. When one is found, the service is resolved and the name
& IP are populated into a list of discovered repositories. Clicking an
NSD discovered repo will prompt the user to add the repo.
* If the info is taller than the icon, grow larger to fit it in
* Center icon vertically
* Move padding out of the header
* Revert some font sizes to how they were some time ago, a bit smaller
Yay!
As expected, a lot of the stuff in DB class is due to UpdateService
requiring it to process the downloaded indexes and insert data into
the database. Thus, this change is about removing that stuff from
the DB class and migrating to ContentProviders.
This required a bit of a change to the way that UpdateService decides
what to do with the data from indexes, but I hope it will make
understanding and changing UpdateService easier in the long term.
For example, it used to read the app details from database, then
if a repo wasn't updated (due to unchanged index) then it would take
the app details for that repo from the list of apps, and re-update
the database (or something like that).
Now, it has been refactored into the following methods:
* updateOrInsertApps(appsToUpdate);
* updateOrInsertApks(apksToUpdate);
* removeApksFromRepos(disabledRepos);
* removeApksNoLongerInRepo(appsToUpdate, updatedRepos);
* removeAppsWithoutApks();
* and probably some others...
Which hopefully are self-explanitory.
The recent change to implement single repo updates was re-implemented
with in light of the methods above. The interface to UpdateService for
scheduling a single repo update is the same as it was before, but
the implementation is completely different. Still works though.
Using batch content provider operations for repo updates,
but they suffer from the problem of not all being under the same
transaction, so if an insert/update stuffs up half way through, we
are left with only half of the update being complete. In the future,
if there is some way to implement notifications from the content provider's
applyBatch method, then we can do it all in the one transaction, and
still have notifications. Currently we break it into several calls
to applyBatch (and hence several transactions) to inform the user
of the progress.
Also adding the beginnings of some tests for AppProvider. In the future, I'll
work on adding better coverage, including instrumentation to test UI features.
==========================
Below is a list of many of the minor changes that also happened along the way
==========================
Make "Can update" tab stay up to date using content observer, rather
than manually deciding when to refresh the tab label as before.
The installed app list is now cached in Utils, because it is invoked
quite a few times, especially when rendering the app lists. The cache is
invalidated when PackageReceiver is notified of new apps.
The content providers don't notify changes if we are in batch mode.
I've left the notification at the end of the batch updates as the
responsibility of the UpdateService. However, it would be nice if this
was somehow handled by the content, as they are really the ones who
should worry about it.
Made curVersion, curVercode and curApk work with providers.
This was done by removing curApk (otherwise we'd need to query the db each
time we fetched one app to get a reference to that apk (resulting in hundreds
of queries). Instead, UpdateService now calculates curVercode and curVersion
and saves them to the database. We then use these where possible. If we really
need curApk (because we want info other than its version and code) we still have
the option of ApkProvider.Helper.find(app.id, app.curVercode). I considered
putting this inside the app value object, e.g. in getCurApk() but thought
better of it as it will likely result in people invoking it all the time,
without realising it causes a DB query.
incompatibleReasons required a minor UI tweak, removing the "min sdk"
ui element from the Apk list. It is replaced by the "Requires: %s" view
(which only appears when the app is incompatible). In the process, and in
response to some feedback from mvdan, I left the min sdk in there, but
only made it show when in "expert mode", just like the architecture.
In order to make the "installed apps" query work under test conditions,
needed to change the way the InstalledApkCache be replaceable with a
mock object.
Pause UIL loading on fast scroll of list, as the list was very choppy for
some reason.
Re-added "Last repo scan" info to the Manage Repo list view.
Fixed up some misc TODO's, removed some unused/empty functions.
Its quite annoying to have the URI EditText in focus and the soft keyboard
pop up when viewing the RepoDetails since the vast majority of the time,
the user will be viewing the info there, not editing the URL.
This commit just moves the focus to the frame, and prevents the soft
keyboard from showing up by default. The user can still click on the URI
EditText to edit it and the soft keyboard will pop up.
In the new Repo Details screen, there is some elements that are labels as
the "signature". This is not quite right, it is actually referring to the
fingerprint of the repo signing key. Since a repo will also usually have a
HTTPS certificate fingerprint, there will also be a fingerprint for that
certificate.
* 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
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).
