Implementing the bare bones of a generic "peer finder" framework. This
may or may not eventuate to something which can live in its own library
and be used by other projects. Might go hand in hand with Carries idea
of having a common UI to be shared among projects.
Got Bluetooth and Bonjour kinda working, but the UI is crud,
and it doesn't remove items and ends up with duplicates. Otherwise,
on our way to a proper "nearby peers" screen.
Removed LocalRepoService, replaced with SwapService.
Still TODO:
Manage threads. Currently everything is called from the
UI thread, which is a regression from the previous behaviour.
I'd like to manage this so that the code interacting with the
SwapManager doesn't need to bother itself with whether it is calling
from the UI thread or not.
The local repo service had many different methods and properties for
dealing with starting and stopping various things (webserver, bonjour,
in the future it will also need to know about bluetooth and Wifi AP).
The SwapService handles this stuff by delegating to specific classes
that are only responsible for one of these. Hopefully this will make
the process of enabling and disabling swap repos easier to reason
about.
The local repo service was also stopped and started quite regularly.
This meant it was up to the code making use of the service to know if
it was running or not, and to enable it if required.
The new SwapService is only started once (when the singleton
SwapManager is created for the first time). It should not use any more
resources, because it is a background service most the time, and it
is responsible for moving itself to the foreground when required (the
burden is not on the code consuming this service to know when to do
this).
By having the service running more often, it doesn't need to'
continually figure out if it needs to register or unregister listeners
for various properties (e.g. https enabled) or wifi broadcasts. The
listeners can stay active, and do nothing once notified if swapping is
not enabled.
Moved the timeout timer (which cancels the swap service after 15 mins)
into the SwapService, rather than being managed by the
SwapWorkflowActivity. Seems more appropriate for the service to know to
time itself out rather than the Activity, seeing as the Activity can
die and get GC'ed while the service is still running.
Finally, although there is nothing stopping code in F-Droid from
talking to the service directly, it is now handled by the SwapManager
singleton. This means that details such as using a Messenger or Handler
object in order to communicate via arg1 and arg2 is no longer required,
and instead methods with proper type signatures can be used. This is
similar (but not exactly the same) to how Android system services work.
That is, ask for a "Manager" object using getSystemService(), and then
use that to perform functionality and query state via that object,
which delegates to the service. Then we get the best of both worlds:
* Reasonable and type safe method signatures
* Services that are not tied to activity lifecycles, which persist
beyond the closing of the swap activity.
All the code from the activity and the fragments has been successfully
ported to the SwapWorkflowActivity + Views. Thus, the code is no longer
useful, as it was only kept over the previous WIP commits so that it
can be referred to to help re-implement fragments with views.
Not worrying about styling yet, just functionality. Added an InnerView
interface that these views can implement. Currently it asks them to
populate the menu. It may be slightly inefficient if we end up with a
popup menu, because it is called onPrepareOptionsMenu, but expects the
inner view to inflate the menu. However, for swap this shouldn't be an
issue, as all the menus pretty much fit in the action bar of most screen
sizes.
The NFC message now is handled by the FDroid activity, so it is treated
the same way as every other incoming repo URL. Because FDroid handles
incoming intents correctly, the NFC one just magically works when
the <intent-filter> is moved from ManageReposAcivity to FDroid without
further code changes.
The other change is that the two way swap only happens when both are
actually swapping. Otherwise, we will send a request for someone to
swap with us, when we are incapable of swapping with them.
Fixes#267.
Although this is usually regarded as poor form, it is currently better
than the alternative which is the whole swap process poohing itself
when a device is rotated. In the future, it may be worthwhile investing
in designing a proper UX for landscape swap too. However the process
of swapping can be quite complex if not presented well, and so it might
end up being too much work to maintain two different UXes for landscape
and portrait.
On api 19 or later, writing to your own private directory on the SD doesn't
require any extra dependencies. We only ever store icons, apks and index stuff
on the private repo, so we never read/write anywhere else on the SD.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
