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().
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).
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.
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.
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.
