To make things less confusing, this disables the main button on AppDetails
when something is running. During install, it also changes the text of the
button to "Installing..."
This removes lots of boiler plate, makes it much easier to get the info
where it is needed, and puts the code in line with rest of FDroid. The
ProgressListener pattern was forcing a lot of passing the listener
instances around through classes that never used the listener even.
That makes that repo automatically ready for use based on user actions like
adding a new repo, switching an existing repo on, etc.
This also lowers the priority of the "update" menu item since it shouldn't
be needed any more. But leave it for now, just in case.
Having a Context in Downloader means that the communications can be changed
to a LocalBroadcastManager, following the pattern that is in a lot of this
app already.
Since the repo updates are happening in an IntentService, they are already
running in a separate thread. Ironically, the dialog was showing in spite
of that. This removes the dialog entirely and instead puts up a
Notification with the same messages. Ultimately, the "refresh" button
should go away, the repos should be updated whenever someone goes to
install an app, and all APK downloads should also show up in the same
Notification.
This removes UpdateReceiver entirely and replaces it with local broadcasts,
since that is a common pattern in FDroid and Android. It also reduces the
amount of code here.
refs #103https://gitlab.com/fdroid/fdroidclient/issues/103
No need for a reusable Fragment here, its only used in one place. This
changes the structure to be a regular Activity, with all View and Menu
setup in XML files loaded in onCreate().
This also converts the URL to a TextView. Having it editable in this
Activity makes for a confusing user experience. Instead, the "Add Repo"
input should validate the URL and not allow creating repos that don't work.
This also purges the use of UpdateService.UpdateReceiver, it will be going
away in the upcoming commits.
We are not forcing an update, in the sense that we make the update
service run. Rather, we are ensuring that the next update wont return
after doing nothing, with the message "repos already up to date".
In this case, the repo metadata (and hence its etag) is the same,
but we made changes in the client to handle the metadata correctly.
Thus, we don't care that it hasn't changed, we want to update anyhow.
Did this by using the same query which is used to update the icon URLs
after updating the index. To make this same method accessible, without
causing sad database locking, had to expose the method from AppProvider
in a way which would let DBHelper access it. See comments in code for
further explainations.
While there, removed the final lint warning in my Android Studio for
the AppProvider. This was a warning because we could have ended up
iterating over a null object. Although it turns out there was a correct
guard in place which would ensure this didn't happen, it wasn't in such
a way that lint would understand. Thus, I changed the guard condition
around `for( String blah : CommaSeparatedList.make() ) {}` to let lint
relax and not be so pedantic.
Replaced `Switch` with `SwitchCompat`. In the future, should completely remove
F-Droid's `SwitchCompat` class. Fixed paddingLeft/paddingStart, except for some
places where lint complained. Apparantly that is for some Samsung tablets on
Android-16. Will have to create a layout-v17 version in the end for these.
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).
Kept getting a message in the Bluetooth _client_, which said the
socket timed out or received an invalid response or something. Most
people seem to believe that it is due to a bug in the Bluetooth stack
on Android 4.2.1 and suggest using reflection to access a method that
actually works as intented. I couldn't get it to work correctly though.
Kept the code here because this whole branch is a WIP, and we need
to figure out how to make Bluetooth work one way or another.
`SwapService`: Remove unneccesary TODO's and unused constant. Also
added other TODO's there which will need to be done before swap is
stable. Can make them into issues in gitlab, but will leave there for
now.
`SwapWorkflowActivity`: Clarified TODO's, fixed issue with cancelling
swap when in the "connecting" state (before it would not show the
right view again, now it goes back to the first view).
`WifiQrView`: Make scanning of QR code initiated by `SwapActivity`.
This is because the activity is actually the one who is able to listen
for a response anyway.
`BluetoothFinder`: Cleaned up TODO's in but didn't actually address
them.
`BluetoothPeer`: Removed TODO about fingerprints, because TOFO is
probably the way to go with Bluetooth anyhow.
`BonjourFinder`: Remove dead code, prevent NPE by using final local
variable rather than member variable (the member variable gets set
to null in a different thread).
`BonjourPeer`: Fix bug with prompting other device to swap back.
`BluetoothDownloader`: Fix typo in comment.
`Downloader`: Removed TODO that was left over from a refactor, and
was never actually correct. The code after refactoring was broken
because it created an `InputStream` which was never closed. Now it
doesn't do that, because it was fixed in an earlier commit in this
branch.
`HttpDownloader`: Remove TODO, but clarify that the downloader does
not follow 30x redirects.
It is very hacky, and I did it through the non-swap interface, and it
only works once then the state stuffs up and it no longer accepts incomming
connections, but it worked! Now to smooth out all the things.
Before, you could "Enable swapping" without specifying which type
of protocol to enable. Now, the two switches are clearly delimited
between bluetooth and wifi.
We don't want to depend on HTTP being active in case there is
no wifi that exists at all. In some cases, local 127.0.0.1 does not
exist if the Wifi is not connected. This commit takes the code
from LocalHTTPD and repurposes it for the BluetoothServer needs.
This drastically simplifies the very important index.jar signature
verification process by splitting out the Trust On First Use (TOFU) part of
the process into its own method, and makes the TOFU write happen separately
from the `RepoUpdateRememberer`. It requires all connections go through
the normal verification process.
Thanks to @mvdan for catching that. Turns out Java's String formatting is
not as tolerant as C's printf(). Java crashes when the format is wrong,
while C just ignores extras.
Might as well tap into the stream to get the byte counts, that's best
progress info I can think of when parsing a file.
This is a step towards a single progress bar for the whole process, instead
of showing one progress for downloading, another for parsing XML, then a
third for processing the new app info.
Now that there is only ever the index.jar, the whole flow of RepoUpdater
has changed quite a bit. This updates the logic for deciding when to store
the current repo's pubkey in the database for future reference.
This changes the flow to stop writing the unpacked index.xml and instead
stream it directly to the XML parser from the index.jar. This should speed
things up some.
refs #259https://gitlab.com/fdroid/fdroidclient/issues/259
This is also work towards running the whole thing in the background:
refs #103https://gitlab.com/fdroid/fdroidclient/issues/103
This also removes the progress stuff since it will need to change a lot to
work with the streaming mode
Before, there was an abstract RepoUpdater class with two subclasses, one
for signed and unsigned. Now there is just a single class, and it only
ever starts with the index.jar. So this removes lots of code that was
there to handle that more complicated structure. For example, there is no
longer the need to separately work on the index.xml vs index.jar.
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.
The reference to mini-services above are not full blown Android
services. Rather, they are utility classes which can be started,
stopped, and send broadcasts about their status.
Made the list of apps to install better, with buttons for install
or upgrade, and statuses for incompatible and installed.
