Although the adapter tries to keep in sync with the app status update
manager, there may be times when this is not successful. In such
circumstances, it seems safe to just guard against invalid situations,
rather than trying to assert an error or fall over.
Fixes#922.
There was some confusion in the user tests about how to launch an app
once it was installed. Hopefully this small change goes towards fixing
some of that confusion. Instead of just showing "X installed
successfully" in the app list, it now shows a "Run" button next to it.
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).
When dismissing an "X installed successfully" intent, it should also
dismiss the relevant item from the "Updates" screen. This was not
happening. Upon investigation, I noticed that when I dismissed a
notification, it was passing through the Apk which I installed over a
day ago. This is because it was reusing a previous pending intent rather
than creating a new one.
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.
Previously, the definition of "New" was whether or not the added and
last updated dates were the same. This made sense, because we only
showed apps from the past few weeks (depending on preferences) as new.
Now that we show up to 200 apps in the first screen, regardless of age,
this check is no longer helpful.
It seems pointless to only restrict "Latest" to items within the last X
days. When you only have the GP repo enabled, or other repos with less
apps that are updated less frequently than the main repo, this screen
always ends up empty. This change shows the last 200 updated items
instead of those updated in the last X days.
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.
It was assuming there is always a priv ext preference. However, we
remove the priv ext preference the first time the fragment is opened. In
these circumstances, the preference no longer exists, resulting in a
NPE.
Unused for now, but like with the `LoggingQuery`, it is helpful to
be used for debugging purposes. For example, used this to quickly
figure out that it took 7 seconds to fix the PRNG stuff in FDroidApp
onCreate().
Previously it would show a grid patter for the first five items, and
then resort to list items. This continues the grid pattern indefinetly.
Fixes#866.
We no longer prefix the list of categories with "Whats New", "Recently
Updated", and "All". The new UI doesn't require this. The only place
they were being used now were in the tests.
This was implemented before because the main screen of the three tab
layout needed to update in response to the list of installed apps being
installed. When we scan the list of installed apps upon starting
F-Droid, we didn't want to have to requery for the list of installed
apps every time we found a new installed app. For this reason, we
"debounced" these requests (accumulated them for 1 second, and then let
go of a notification only after 1 second of inactivity).
This is no longer a feature, and so we can afford to fire the
notification instantly.
We were jumping the gun before, and asking to refresh the app details
adapter before the installed app service was able to notify us of a
change to the apps installed version.
This should be refactored to use broadcast receivers instead of
content observers (which are tied to the implementation of a content
provider). However this is currently a straight port from app details 1
to app details 2.
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.
Prior to this, it would still show the "Ready to update" list item.
Now it updatpes the description to say "successfully installed" and
removes the "Update" button.
If you open AppDetails, initiate a download + install, and then navigate
away, it still pops open the install dialog for you. This is because it
never deregisters the broadcast receiver.
This change maintains the behaviour of always having the broadcast
receiver. This is because it is only added when the download
completes, and would require further refactoring to change that.
Instead, we listen for the receiver, but we ask if the AppDetails view
for the apk in question is actually visible to the user. If not, we
don't try to initiate the package manager.
Previously it showed the number of things which were eligible for
update. This will become less and less important the more people we can
switch over to automatic updates. However, given the privext vs unknown
sources thing, we will always have a lot of users who need to be
notified that they need to take further action to complete an install.
Prior to this, they were in whatever order they came from the metadata.
This resulted in weidrness because the repo which was updated last will
have its apps shown last. We are trying to move away from the repo
update order being important.
In the future, this sort order should take into account better
heuristics, but for now this is at least deterministic.
The database still treats repos with a _low_ number as _low_ priority.
This means it sounds weird when you say "Repo with priority 1 is the
least important", but other than that, everything works as expected now.
Technically we could recreate the query to update the repo metadata
within DBHelper, but that is difficult because it is sort of build into
the content providers. Unfortunately, we are unable to access content
providers from the DBHelper.
In the future if we are able to migrate away from content providers to a
more dumb data access layer, then we could reuse the query to update the
metadata priorities in the DBHelper. However that is a tomorrow problem.
To limit the possible oddness of having the installer package being
something different than F-Droid, only set it to priv ext on android-24
and newer, since its required there.
There is still quite a bit to figure out in the data format of the
per-package "What's New" entries, and its breaking the tests, so move
the placeholder code to the one spot where the placeholder whatsNew
entry is used.
App.getAllScreenshots() works nicely here, but its probably a temporary
measure until we figure out how to handle the various kinds of
screenshots (TV, Wear, etc).
This is based on @pserwlyo's work. The App and Apk classes currently
need just the public instance variables auto-filled by Jackson, so
everything else is considered opt-in, via @JsonProperty declarations.
This is currently only used for setLocalized(), setUsesPermission(),
and setUsesPermissionSdk23().
# Conflicts:
# app/src/test/java/org/fdroid/fdroid/updater/IndexV1UpdaterTest.java
repoId is used in Repo, App, and Apk instances to point to the Repo data
in the database. It does not come from the index files, but rather the
client database.
