Required changing some local variable names to prevent the same
`view` variable being declared multiple times. Otherwise it should
be a verbatim change from if statements to switch statements.
Required a couple of undesirable changes, such as:
* sCollated -> collated
* mFDroidApp -> fdroidApp (note the lower case 'd')
Otherwise it was relatively minor given how many member variables there are
in the code base.
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.
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.
