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.
Doesn't do anything except create an app with no versions,
no donate links, anything like that, and ensure that the adapter
is able to create the view holders for each resulting item.
In the future we can beef this up to check more exotic conditions,
such as calling `updateItems(App)` with different apps, each
with different combinations of versions, donation links, permissions,
etc.
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.
Translators:
Ajeje Brazorf Sardinian
Alberto Moshpirit Spanish
Andreas Nordal Norwegian Bokmål
Clara Chido Shona
Enol P Asturian
E T Turkish
ezjerry liao Chinese (Traditional)
Licaon Kter Romanian
naofum Japanese
Nebojsa Tausanov Macedonian
Nutchanon Wetchasit Thai
Osoitz Basque
Sylvia van Os Dutch
Tawanda Mugari Shona
Verdulo Esperanto
Verdulo Polish
Yaron Shahrabani Hebrew
YFdyh000 Chinese (Simplified)
zmni Indonesian
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.
Fixed long version overriding app name (issue #322)
Also, fixed deprecated "singleLine" property to "maxLines="1"".
Also removed reduntant (legacy) padding declarations, for the files used exclusively by newer APIs which override those declarations with new ones.
See merge request !417
Rework net for 0.102
This is a collection of targeted fixes for the %"0.102" release. Most of them are quite narrowly targeted bug fixes. I couldn't avoid reworking the update scheduling in order to fix some of the listed bugs. This is the only part that seems possible to have regressions. In any case, if there are regressions, they will be in a very limited chunk of the code, in `UpdateService`, which we have no plans to touch in %"0.103 - UX Overhaul" so it'll be easy to do a 0.102.1 release.
See merge request !415
Also, fixed deprecated "singleLine" property to "maxLines="1"".
Also removed reduntant (legacy) padding declarations, for the files
used exclusively by newer APIs which override those declarations with new ones.
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)"
