* Replace hardcoded color values with references to style.xml,
which in turn has different values for light and dark theme.
* Force reload the activity to get the theme applied.
TODO:
* Swap uses it's own theme, need to figure out a way to
handle that. Currently the main Nearby screen which you get
to from the bottom navigation is ok, but anything after
that is light / custom themed.
Given the only feedback available to the user that they initiated a
download once clicking the version from the list is up top, this scrolls
the recycler view to the top to show that feedback.
Also shows the selectable background when they touch the version list
items.
When navigating to Updates -> Show Apps and then downloading an item, it
shows the download progress inline for that item. After this is
complete, it then shows a tick icon next to the item. The long term goal
should be to remove the list item from under "Show Apps" so that it is
only shown at the top of the "Updates" view. However this will require
more work. In the meantime, we can alleviate some confusion by replacing
the "Tick" icon with a button that says "Update" (like the other buttons
in the Update view).
Now that we've moved the first screen to "Latest", we always want to do
our best to show something there. This preference is pretty redundant in
light of this.
The text is more comprehensive on the main screen than on categories,
because this is the view that all users will see when they first open
F-Droid.
Fixes#879.
Previously this was only shown in the notifications.
This does not show the full progress of the update, but at least it
provides a rudimentary level of feedback. In the future it can be
modified to show more substantial feedback if required.
This results in a slightly larger apk (e.g. 500KiB), but it reduces the
scope for bugs greatly. We still get all the benefits of only having to
maintain a single density-independent vector (rather than several
density dependent PNGs and all the work that involves).
The class of bugs that it solves is that there are several places where
vectors cannot be used, and you wont notice when developing on a device
newer than 5.0. For example, notification icons, `TextView`
and its `android:drawableStart` attribute.
Fixes#913.
The CardView extends FrameLayout. This layout has some problems with
margins: http://stackoverflow.com/questions/5401952/framelayout-margin-not-working.
These can be overcome in most situations by swithcing from a margin to
some padding on the child view. The reason it is okay to do this in
most cases is because the child view is usually a layout such as a
ConstraintLayout anyway. For such cases, the difference between margin
and padding is not much different, because there are usually not any
background colours or borders applied (where padding vs margin would
usually make a difference).
Left some more unused strings which are a bit more general purpose and
perhaps should wait until after a stable release to remove. The
rationale for this is that we may want to revert to part of the old
terminology in certain places, and don't want to have to ask everyone to
translate everything again.
These are loaded dynamically at runtime based on a sanitized version
of the category names. Thus, the static lint tool cannot pick up that
they are indeed used.
On newer devices, it takes the icon, removes colour, and uses that. This
looks weird because:
* The head and body look too close together once you remove the shading
from the launcher icon.
* The eyes dissapear because they are white (not transparent) in the
launcher icon.
This notification is kind of weird, because the only ways it can be
dismissed is by:
* Swiping a notification away from the notification drawer.
* Closing and reopening F-Droid.
However I think the UX is still pretty nice:
* Tells the user that it worked.
* Allows them to navigate to it if desired.
Default padding specified is 12dp which is not very generous.
This reduces it to 2dp for seemingly good effect. Yet to see what it
looks like with longer translations of other languages, but time will
tell.
The previous language hinted at the fact we auto download and install
updates like Google Play. This is not the case (unless you have
priv-ext). To clarify, now we "Automatically _fetch_ updates", ready to
install when the user initiates the install.
Fixes#839.
