The update count was broken because I added the join onto the
apk table, and in the process, forced a GROUP BY on the AppProvider
queries. This group by made the COUNT(*) actually count the number
of apks for each app, not the total rows.
When viewing app details from a swap list, we need to return to the
swap list when pressing "up". Previously it would go to the main list
of apps, and only return to the swap list when pressing "back".
Now, a subclass of AppDetails is used when in swap mode, which knows
how to navigate up to the correct task.
I had trouble wrapping my head around which point in time the fdroid/repo
directories are created, when they are populated with .html files, and
when the index.xml is put there. I did some minor cleaning up to make
it a bit easier to manage this in the future.
Althought the construction of the XML document was fine witn Android 7,
the actual serialization of it was limited to 8 or higher. Try as I might,
I couldn't find a way to figure out how to serialize a DOM tree on API 7.
Turns out that the "PullParser" API is able to build and serialize XML
trees on API 7. It's a little clunkier than the DOM alternative, so I
refactored out the generation into a subclass to make it clearer what
it is doing and when.
* Selecting apps to swap fixed
Before the checking of a list item would not actually register it to
be included in the swap. This has been rectified.
* Added a new property to repos for "isSwap"
Repositories with this property are not shown in the Manage Repos
activity, as there is not much benefit to having this happen.
* More robust error handling when symlinking files
Before it would check for stdout or stderr and then throw an exception.
This happened even on successful symlinks on my 2.3.3 device. As such,
I've put the error checking after the shell command has completely finished
(just in case there were any race conditions), and more importantly, checked
for the presence of the file being linked - rather than just stdout or
stderr.
* More code cleanup
Generics <> operator, Nullable annotations, removal of dead code.
* Removed dead code
* Added some Nullable/NonNull annotations to prevent future misuses of variables.
* More verbose errors when an error occurs creating directories/files.
* Provide CheckBox for selected items
Newer API's highlight the background using the "activated" state. Older
APIs need this to be implemented differently, so there are now checkboxes
on the left of the list view items to provide this functionality.
* Clean up IDE warnings
Diamond operator for generics, remove unused imports and unused method.
* Adapter class created for installed apps
Cleaned up the code to do with binding views to the adapter in this view.
Previously it made quite a few assumptions about the structure of the layout,
e.g. "layout.getParent().getParent() is a LinearLayout", which would cause
crashes if the layout changed slightly.
* Cleaned up text alignment styles for API < 17.
API v17 has a textAlignment style, wherease previous verisons rely on
the "gravity" property. This change includes gravity="center" where there
was previously only textAlignment="center".
* Fragments get added properly on 2.3 device.
For some reason, when adding the fragment to android.R.id.content, it
wouldn't work on my 2.3 device. This change includes a (almost) empty
activity layout with a single FrameLayout. The fragments are added to
this rather than "content", and it works better. It is not perfect - it
still adds the fargments behind the action bar, and so the action bar
appears blue. But at least they are there :)
* Added translatable strings where constants were used before.
Not related to v2.3 support, but stil important for a stable release,
that is fully translated.
Bug in the code which decides which apps to select for swapping.
Due to the way in which Adapters and ListViews work together to provide
"header" and "footer" functionalities for lists, there is a mismatch between
the index in our original adapter, and the actual index on the list. It is
up to us to maintain this correctly, which was not done, hence the off by
one error.
This was present in the old local repo implementation, and the skeleton
code for implementing it was copied to the swap fragment. The only change
neccesary was to add a search button to the menu and make it have a
SearchView as its action view.
Shows an expandable notification on devices that support it (4.1+
I believe). The support library does most of the job of handling
incompatibilities between platforms.
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.
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
