Include support for libaccesspoint to control the WiFiAP of a device.
Selecting wifi networks i snow possible by touching the name of the
wifi network in the "Start Swap" screen (sometimes it will say
"No network yet"). This exhibits the same behaviour as the "Join Wifi"
screen used to (and still does) do.
On emulators (is there other devices too?), Bluetooth is unavailable,
but the "Send F-Droid" is still there. I could remove it, but then
people may get confused as to why it is not there. Instead, there is
now a dialog which explains why it can't be sent (no Bluetooth).
The AppDetails subclass used to be used when you couldn't install apps
directly from the swap workflow. Now we don't send people to app
details, so the activity is unneeded.
The swap progress also now listens for progress broadcasts, rather than
showing an indeterminant progress bar.
Fixed lots of (minor) conflicts. Some due to earlier rebasing of
material stuff that was subsequently merged into master with a
different commit hash (I guess, that's what it looked like anyway).
Still need to hook up the buttons in the app list, but this change
shows the correct status and/or buttons for installable/upgradable/
incompatible/installed apps in the swap list. This change also hooks
up UIL to download icons for apps and thus display them in the list.
Involved creating another view/state for which the swap workflow can
be in. It is not explicitly stated by setting the state of the SwapService,
as is the case with other views. Rather, it is inferred based on the
presence of a `NewRepoConfig` crafted from the incoming intent in
`onResume()`.
Also gave me an idea of how to move more logic out of individual views,
and into the SwapWorkflowActivity. That is, inflateInnerView should
return the inflated view, to be cast into the specific subclass. From
there, the activity can call methods directly on the view to set it
up, rather than having the view do that stuff itself. In the future,
may consider doing this with other views too.
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.
NFC swap now goes to confirm swap, not manage repos activity.
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.
See merge request !91
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.
