Allows the two menu items "Ignore All Updates" and "Ignore This Update"
to be checked and save the relevant preferences to the database in response.
The old code waited until the activity was paused before saving the
preferences to the database. This code does not, and as such incurs
a database write on the main UI thread as soon as the user checks the
menu items. However that database code has recently been refactored so
it should be much more performant. If it turns out to still be problematic
then we can revert to the old behaviour of hodling onto any state changes until
onPause then persisting to the database.
Allows the type checking to be done by the compiler rather than the developer.
It was possible here because there is only two types of view, and the first type
will only have one or zero entries in the adapter. Thus, I've swapped the usage
of a `String` type for a `null` and checked for null instead of `instanceof String`.
Changed the helpful comments to a Javadoc comment, as tooling such as editors
will be more likely to make use of it like that.
Renamed to emphasise that only trailing new lines are stripped.
Added a basic test for this function to ensure it only strips trailing,
and also that it does actually strip trailing slashes.
Although the `textView` in `DonateViewHolder is currently not used, it was
pointing to an id which was not in the layout. This has been fixed in case
future devs choose to use this text view. Alternatively, we could remove it
completely if we don't think it is going to be used in this upcoming UI work.
Similar to the litecoin/bitcoin/flattr stuff, we need to check that a
proper URI can be handled via an intent. This previously just checked
whether the email address could be handled without the mailto: prefix.
This extracts the functionality from the old AppDetails which prefixes
donation links with the relevant scheme (bitcoin: or litecoin:) or URL
(https://flattr.com/thing/) into the App class.
The adapter has a hard coded assumption that mApp is never null.
This documents it as such by making the member variable @NonNull.
This is not perfect, because the consumer of this class doesn't quite
seem to check this constraing properly, however at least within the
class it adds some explicit documentation that is understood by editors
and lint that this is a non-nullable field.
Each call site of the `getHeaderView()` method needed to do a null
check and then it would call `setProgress()`. This has been replaced
with two methods `setProgress()` and `clearProgress()` to make it a
bit less repetative and harder to accidentally get a NPE in the future
by invoking `getHeaderView()` incorrectly.
There are certain things we can leave in the database even when they
are not being used. The criteria for this is:
* Could it be used again in the future?
* Can it be excluded from queries easily while it is unused?
Examples are entries in the package table, and entries in the category table.
This fixes a problem where entries in the category-app join table stayed in
the database, causing categories to be considered as "in use" when really there
were no apps in those categories. These rows need to be removed, because when
new apps are added again in the future, they will have different primary keys.
These different primary keys mean that the rows in the category-app table will
never be useful again, and thus should be removed.
Fixes#806.
This introduces three network states:
1. completely disconnected
2. connected only via metered networks
3. connected via unlimited networks
This allows the update process to use bandwidth better, especially when the
user has enabled the "Only on WiFi" setting. It also helps prevent silly,
cryptic error messages in the update process is triggered when there isn't
internet available.
I tested this with:
* 4G only, but not set up for internet
* 4G only, with internet
* 4G + WiFi
* WiFi only airplane mode
* no internet at all, full airplane mode
closes#793closes#774
Its really easy to use USB Ethernet devices with ChromeOS and some Android
devices like Android TV. ChromeOS now supports Android apps. Since really
the goal is to avoid metered networks, and ethernet is very rarely metered,
this fits in with the user expectations around the preference. And if it
doesn't, there are very few people using Ethernet with F-Droid right now,
so whatever harm does happen will affect an extremely limited number of
people.
First, this is more honest than just using the default since it is saying
what the actual software is. Second, it protects identity, since the
default User Agent on Android can have a lot of info in it, for example:
"Dalvik/2.1.0 (Linux; U; Android 5.1; XT1039 Build/LPBS23.13-17.3-1)"
