The default behaviour of gradle when encountering a transitive
dependency which is the same as an explicit dependency, but where the
transitive dependency has a higher version, is to bump the depdendency
which was explicitly added. This meant that the addition of the
bottom navigation library implicitly bumped our support lib to 25.3.0
due to its dependence on it.
The options are:
* Change the 3rd party lib to support 25.2.0 instead of 25.3.0.
* Explicitly exclude the transitive support lib dependency in our build
script (what we have done in the past, e.g. with acra).
* Bump our explicit dependency.
Given the nature of the changes from 25.2.0 and 25.3.0, it seemed like
it was simplest to bump our dep. However, there is a bug
https://code.google.com/p/android/issues/detail?id=251302 which causes
a function we depend on in SwitchCompat to require API 14. Therefore,
this change excludes the 25.3.0 transitive dependencies, allowing our
25.2.0 dep to get used.
In the process, I've noted that there were a few places we opted for
excluding the transitive dependency in the past. These have now been
removed because we have a higher version than they do, and thus they
will no longer drag our old version forward.
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.
Right now, it will allow us to set the selected item more nicely.
In the near future, we will use this dependency to control the visual
display of the bottom nav better (e.g. icons/text appearance/animation).
Note that there is a bit of development going on at the Android team,
and the official bottom navigation view may oneday support all of these
features. In that case, we should probably switch back.
* 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.
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.
There were a few different options around, but some of the best ones
which provided the most flexibility when adding diverse/complex
viewTypes to a recycler view target a minsdk above 10.
The "adapterdelegates" library still offers a big improvement on vanila
adapters, especially for the Updates view.
This is in response to identifying a bug with the way priorities work
with categories. Two repos may both specify different categories for
the same package. In this case, F-Droid should only select the
categories from the highest priority repo. Well, it is not to say that
this is the most preferable option, but it is consistent with other ways
that repo priorities are used.
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.
