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.
The previous dependency extended the support library bottom nav. It did
this at the expense of lots of reflection. This is pretty brittle and
likely to break in future releases as the support lib gets updated. In
the mean time we need to have a fully working bottom nav, so this commit
includes a different dependency.
Most 3rd party bottom navigation panes look great. All that I found
require at least API 11, mostly API 14 (due to animations I suspect).
I've forked one of the most popular ones on GitHub and made it support
back down to API 10. My fork is added as a dependency until upstream
accepts the PR.
If they don't ever, then we can reconsider what our options are.
The two times I've swapped the bottom nav implementation have both been
trivial. The code generally only touches the MainActivity and its
layout.
Shows a red badge over the "Updates" menu item.
The updates badge is a bit hacky. There are indeed libraries which
implement a bottom nav which have support for badges built into
them. However they target API 14. There are also other badge
libraries which just deal with rendering, but for the cost of
another dependency, it is not particularly difficult to create a
`TextView` with a background and position it ourselves.
* Show selectable background behind "Show/Hide apps" button.
* Scroll to the relevant place in the list when showing/hiding apps.
* Only show one line (ellipsized) of the apps to update in header.
Even though it doesn't matter here because it is going from one side of
the parent all the way to the other. I hope it makes it easier if we
completely avoid right/left and only ever use start/end. Then searching
for RTL problems will be easier.
Alows for more flexibility in what we are able to display, including:
* Prompting users to donate to frequently updated apps
* Showing messages from package maintainers to users
* Marking apps for later installation when offline
Most of these are not yet implemented, but will be able to when
required, whereas they were not able to in the previous UI.
Fixes#882.
Couldn't figure out the exact cause of going from Inkscape .svg to
Android VectorDrawable, so redrew it in inkscape and this time it works.
*shrug*.
This is as per the mockup in issue #840, and does the following:
* Adds a new `PreferencesCategory` of "My Apps" at the top of the
preferences screen.
* Adds a "Manage Installed Apps" preference, and moves the
"Repositories" preference into this category.
* Repeals an existing change which prevented "updateable" apps from
appearing in the list of "installed" apps. This is because the two
lists of apps are no longer displayed alongside eachother.
* Enhances the `AppListItemController` to also be able to display
whether or not the currently installed version is the recommended
version or not.
* Also adds option to display whether the user has asked to ignore any
updates for any specific apps.
Things that are still not right:
* BottomNavigationView doesn't read out the title of items when selected.
Created this issue: https://code.google.com/p/android/issues/detail?id=230595&thanks=230595&ts=1482125499
* TTS reader combines the app name and summary without a pause which is jarring.
* Touching the background of the recycler view in the categories view reads all category names.
* Likely other problems too.
Shows progress and download complete now, but left a few TODOs
lying around. These are mainly around the ability to then deal with
installing an app once download is complete.
The styles used by the app details showed good padding on either
side of the buttons text. This was because they had a certain amount
of screen space to fill up which resulted in nice empty space on either
side of the text. Other buttons do not have this type of layout, so
need to have a minimum amount of padding thrust upon them.
Required breaking out into values-v17 too, so refactored common styles
into base style to make this easier.
As per the main screens feature image behind the "Recently added"
items, also use the same abstract artwork as a placeholder for the
feature image in app details.
Draws two rows of triangles, each coloured randomly according to
the dominant colour in the apps icon.
Given that the colour is probably assigned to the FeatureImage in response to
a network request finally downloading an image, there is a period of no feature
image. After the colour is provided, then if it is set instantly it tends to
look jerky. This eases in the colouring of the feature image.
Happy to discuss whether this is a good idea or not, but right now
there is no way to update repositories so often you are left with
an empty first screen.
This doesn't worry about state management (e.g. remembering
whether we are refreshing or not and showing this when we resume the
activity). Instead, it listens for the refresh listener, and when
triggered it will set the refreshing state to not refreshing. For now
the notification can act as the feedback that something is happening.
