Instead of passing in `null` each time you don't have a username/password,
this change provides those as meaningful default values in an overloaded
version of the method. This takes care of Java's lack of default argument
support.
This is for an abundance of caution. If the guard condition checks
for the presence of both username _and_ password fields, then a crash
or some sort of force close during the update (after adding username
but before password) will mean that next time the app runs, this
condition will evaluate to false and the password field will never
get added.
As with the previous commit, there is probably not any harm doing this
in the way it was done. However it helps reason about the code if
changes are applied in the order that they were introduced. Especially
because each of them does something depending on the version of the
database at that point. With this change, you always know that at the
point that the function is run, the database version will be 51 (and
hence the structure of the database will be predictable).
This may not have caused any trouble, but the principle behind the old
behaviour is that at the point that that was required, the fdroid_repo
table had that particular structure. There is a small chance that it
_may_ have some unintended consequences when upgrading clients with very
old database versions. Probably not, but may as well leave it as is.
Extended DownloaderFactory to support optional username & password parameters.
Extended HttpDownloader to check for HTTP 401 Authorization Required status code
and send a simple HTTP Basic Authentication header with all requests.
Extended ManageReposActivity to support repositories that use HTTP Basic
Authentication, added a dialog to prompt for username and password.
Extended RepoDetailsActivity to be able to display and modify the authentication
credentials.
Replace search dialog with a search widget
SearchView is the recommended way to implement search UI. See https://developer.android.com/guide/topics/search/search-dialog.html#UsingSearchWidget
The UX is still far from ideal but looks much better now.
Before and after (Gingerbred):
Before and after (Lollipop):
See merge request !168
Enable HttpDownloader to use URL-based HTTP Basic Authentication.
This is a very small merge request that adds the possibility to use URL-based HTTP Basic Authentication in a repository URL. With this change you can for example use `https://user:password@my.repo.com` to authenticate against a private repository.
It would be great if you could merge my little feature request into the master, or let me know what I can do or have to change in order for the merge request to get accepted.
I'm of course open for discussion. My use-case is the identification of individual users. We dynamically create a signed index.jar file for each user which contains an individual set of apps depending on the permissions of the user etc.
HTTP Basic Authentication is on of the possible solutions, another solution would be to use the Android Account Manager, but this would be a much larger change.
Thank you for your consideration.
Best regards,
Christian Morgner
See merge request !167
Clean up tabs fragments
No functional changes, just refactoring. The only visual change is that empty text is now positioned at the center which was the initial design (as far as I understand):
See merge request !165
Not sure why it was added initially but now it appears to be unneeded:
the support library does everything right and the lists are themed
properly without any hacks.
Never fallback to UIL for handling image downloads, only use for displaying.
@relan picked up a bug I introduced while refactoring the icon downloading code in !139. This fixes that bug.
Our `IconDownloader` extended `BaseImageDownloader` from UIL. There was an
explicit check in the F-Droid `IconDownloader` which looks for
HTTP/HTTPS/Bluetooth schemes. If it wasn't one of these, it fell back
to the base class. This was what was happening for local cached image
files. As such, when the `getInputStream(...)` method was refactored
to only use F-Droids `DownloadFactory` and not delegate to the base class,
it failed on local "file://" URLs.
This change introduces a `LocalFileDownloader` and makes the `DownloaderFactory`
aware of it.
The `BaseImageDownloader` class only provides support for the following schemes:
* HTTP
* HTTPS
* File
* Android content providers
* Android assets
* Android drawables
F-Droid now supports HTTP, HTTPS, and File URLs. There is not currently any
need for content proiders, assets or drawables to get icons for apps in F-Droid.
If there is a need in the future (e.g. an issue currently discusses loading
icons from installed apps if possible) then that specific `Downloader` can get
introduced to solve the problem.
See merge request !164
Our `IconDownloader` extended `BaseImageDownloader` from UIL. There was an
explicit check in the F-Droid `IconDownloader` which looks for
HTTP/HTTPS/Bluetooth schemes. If it wasn't one of these, it fell back
to the base class. This was what was happening for local cached image
files. As such, when the `getInputStream(...)` method was refactored
to only use F-Droids `DownloadFactory` and not delegate to the base class,
it failed on local "file://" URLs.
This change introduces a `LocalFileDownloader` and makes the `DownloaderFactory`
aware of it.
The `BaseImageDownloader` class only provides support for the following schemes:
* HTTP
* HTTPS
* File
* Android content providers
* Android assets
* Android drawables
F-Droid now supports HTTP, HTTPS, and File URLs. There is not currently any
need for content proiders, assets or drawables to get icons for apps in F-Droid.
If there is a need in the future (e.g. an issue currently discusses loading
icons from installed apps if possible) then that specific `Downloader` can get
introduced to solve the problem.
Cache installed signature
This will later be useful for #122 and others. Also a few more fixes related to signatures and package information.
CC @pserwylo
See merge request !158
These are written manually and mostly don't contain HTML. Some html is
fine if you want to use links or markup, but <p> elements are just
pointless and very seldom used. Be consistent in not using them.
