SwapService is the thing that needs to be always running, and the last
thing killed. So it should start first, and stop last. So now, the user
clicking the button starts SwapService, which starts SwapWorkflowActivity.
This also eliminatings the "Loading" screen in favor of just showing the
StartSwapView with various inline progress indicators.
The Android back button provides a working back function, and the Swap
"close" button on the upper left already provides a reset function. So this
turns the "back" button to be a "try again" button which re-runs the
connection process.
The Receiver superclass is not reusing difficult code, but it is hiding the
simple list of UI configuration that it does.
This also eliminates the "error" TextView and just reuses the existing
TextView for error messages.
Almost all of the nearby/swap view classes could be condensed into a single
base class that is instantiated in the view XML. This is the first step
towards making that happen.
It also lays the groundwork where "steps" are all SwapViews. The
original concept of "steps" put all steps together, whether
F-Droid could control them or not. For example, the Views were
mixed with the system Bluetooth prompts. This is the first step
towards converting the steps to always be SwapViews, which are
always under control of this app.
When coming back to a SwapView/step, it does not seem feasible to handle
automatically restarting things like permissions and Bluetooth prompts. If
there is a way, it should be possible to first load the proper SwapView
instance, then trigger the system prompt. The makes the SwapView a pure
View, without any Controller in it.
* Rename ids to something meaningful
* Remove inner layouts from constraint layout
* Use same text and button styles
* Make sure the background image doesn't overlap with the text
This uses the new Storage Access Framework, which was required for
accessing files on the SD Card starting in android-19. But the API
was really limited until android-21, and not really complete until
android-23 or even android-26. So the levels of usability will vary a
lot based on how new the version of Android is.
This is a quick hack to reuse the Latest view with a slightly simpler
layout. It makes the "basic" flavor fully functional as an fdroid client.
The goal here is just to have something simpler with as little new code as
possible. It is essential that the whitelabeling and "Light" aka "basic"
flavor does not increase the maintenance load.
closesfdroid/fdroidclient#48fdroid/fdroidclient!692fdroid/fdroidclient!695
"full" is the original F-Droid app with all the features. It should still
build the exact same app after this change. "basic" is the smallest
version of F-Droid possible. It does not yet build, nor work.