We were using different methods and violating the correctness error
"Log tags are only allowed to be at most 23 tag characters long." as reported
by lint.
Changes:
* Always start tags by "fdroid." (even though it's a bit redundant)
* Replace "org.fdroid.fdroid." by "fdroid."
* Don't include "compat.", "data." "views.fragments." et al (these didn't and
shouldn't be namespaces really, only for file/code organisation)
* Do include parent classes for subclasses, e.g. "fdroid.RepoProvider.Helper"
since these can conflict
If the download process is interrupted, a "dl-" file hangs around in
F-Droid's cache directory. If the download succeeds, extracts an xml
file from the downloaded .jar file, and then the rest of the process
is interrupted, then a "index-*.xml" file hangs around in F-Droids
files directory.
This fix removes these two types of left over files when F-Droid
is started. In addition, it also makes it so that the downloaded
repo indexes are now more clearly named "index-*-downloaded" (with no
extension, because the code which does it doesn't know whether it is
a .jar or .xml file, and it doesn't matter anyway). Also, it extracts
the .xml files to the cache directory too (instead of the files dir)
and names them "index-*-extracted.xml".
There is some code which removes the old "dl-" files that will become
redundant after the first time it is executed on a users device after
upgrading F-Droid. It is a very small amount of code run on startup,
so I am not concerned about the performance implications of leaving it
there, but I put a comment explaining that it can be removed in the
future.
Includes minor formatting changes, and a few annotations.
Previously, a few people have been confused by an empty list when they first
open F-Droid (e.g. if they are not connected to the internet, and repos didn't
update). This provides some feedback so that there is never a blank screen.
Fixes Issue #34.
To refresh the header, we retrieve the fragment from its id.
But the landscape layout used another id for the same fragment, so it
could not be retrieved, leading to a NullPointerException in landscape.
Therefore, use the same fragment id as in the portrait layout.
When adding repositories using the Manage Repos activity, firstly look
for an /index.jar appended on the URL provided by the user. If that
doesn't work (HTTP status code other than 200) then it will try
/fdroid/repo/index.jar, then /repo/index.jar. If it can't establish a
connection to the server, or if none of the above attempts results
in a 200, then the path provided by the user is kept (even though we
have a hunch it might be wrong).
This is to cover for the case where people arn't connected to the net.
Another way to deal with no internet connectivity is provided by a
"Skip" button on the dialog while searching for the index.jar.
The searching for index.jar is done by doing a HTTP HEAD request, so
the entire jar needn't be downloaded.
Finally, to make this happen in a clean sort of way, I refactored the
ManageReposActivity a little bit to encapsulate all of the add repo
dialog handling into a subclass. This way, the outer class doesn't
need to know things like: Is the dialog showing, what state is it in,
is the background task to search for index.jar files running, how and
when to cancel that task, etc.
When we receive notifications indicating that the app has changed, the
App object needs to be changed and the view updated.
These notifications can be received from two sources:
- the ContentObserver;
- onActivityResult().
Thus, the implementation should not be related to the ContentObserver
(in theory, we might want to keep only the onActivityResult()
notification). Therefore, move it to a separate method in AppDetails.
This also preventively avoids bugs when the ContentObserver is null.
This reverts commit 47e065442edc108d4bb38f9daaa7cdb3fff26b49.
Now that the ContentObserver is created when activity is started (even if not
resumed), then it will be non-null during onActivityResult(). Therefore,
the calls to onChange() will not lead to NullPointerException anymore.
The reason why we want to manually call onChange() is that the
ContentObserver notifications may happen several seconds later:
https://gitlab.com/fdroid/fdroidclient/merge_requests/58#note_948719
The ContentObserver was registered only when the activity was in resumed
state. However, in started but paused state (when the activity is
visible but not in focus), we still want to receive these notifications
to update the view.
Therefore, register it on start and unregister it on stop.
As a consequence, myAppObserver will be non-null during
onActivityResult().
If the AppDetails activity has been destroyed by the system during an
application installation/remove, it is recreated once it should be
displayed again (this behavior can be forced by enabling "Don't keep
activities" in Android developer options).
In onCreate(), it passes its instance of myInstallerCallback to an
Installer. In onActivityResult() (which is called before onResume()),
this installer calls a method (onSuccess() or onError()) on this
callback. The implementation of these methods (the anonymous inner class
assigned to myInstallerCallback) dereference myAppObserver, which is
still null, because it will be initialized in onResume(), so a
NullPointerException is thrown.
However, the problem is not only that myAppObserver.onChange() is called
when myAppObserver is null, but that it should not be called manually at
all: it is a ContentObserver, so it is automatically called when
registered to the content resolver. As a consequence, this callback was
called twice.
Removing these calls fix both problems.
Should fix issue #135https://gitlab.com/fdroid/fdroidclient/issues/135
Immediately after an app uninstall, the associated App will be updated
by a call to reset() in the AppObserver.onChange().
But before receiving this event, the activity and the fragments resume,
leading to a call to getInstalledStatus(…). At this stage, we don't know
that the app has been removed yet, but the package manager already
removed it. Therefore, PackageManager.getInstallerPackageName(…) throws
an IllegalArgumentException.
In that case, consider that the application has been uninstalled.
Should fix issue #167https://gitlab.com/fdroid/fdroidclient/issues/167
