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.
