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.
In a future MR I will remove this class completely, but this just
ensures that touching a notification will not send the user to the old
AppDetails (instead sending them to AppDetails2).
Move logic which parses intent and forceably sets the text of our search
input to onCreate(), not onResume(). onCreate() is invoked each time a
new intent is sent to open up this activity. That is, each time a new
category is opened or a new search request is received. onResume() is
called much more often than this, including when the user is directed to
a new activity and then returns to the search screen after hitting back.
In this case we don't want to remove the search query the user had and
replace it with the data in the original intent.
Locale.getDefault() returns the default for the current JVM (or whatever
runtime Android calls it these days). By asking the configuration, we
will get the Locale that the user has selected from within the F-Droid
preferences.
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.
This will read downloaded .apk files from the disk cache in the background.
For each apk that corresponds to an app which can be updated, the status
manager is notified.
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.
Doing this required tweaking our `IconDownloader` which we give to the
UIL init method in FDroidApp. It only knew how to load from HTTP, but we
needed it to fetch `drawable://` images too (which the library
supports). In addition, it has been renamed `ImageDownloader` as it also
is now used for screenshots/feature images.
This is currently needed for screenshot placeholders, but might be
useful in the future as well. Note that the default BaseImageDownloaded
supports this, as well as content:// and drawable:// protocols.
This was not updating the versions expand icon correctly when the user
clicked on it. It was working when they scrolled away and returned to
the versions list. Now it works for both.
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.
Show an install button after the download is complete so the user can
click it to initiate an install. This is in preference to popping up
install manager activities on their behalf, because they may have queued
up several apps to update.
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.
No longer bind the views as they become visible. This resulted in
the same view being bound multiple times, but that was unneccesary.
Given that there is only five types of view, and each view type only
ever gets used once, the binding can happen when the view holder is
created, rather than each time it is shown. This fixed a few bugs to
do with views being inflated multiple times.
