The fix for the database locking bug was to have a singleton
`DBHelper` instance. This breaks tests because multiple tests
share the same database. The solution is to:
* Hack together a static method which clears the singleton,
then invoke it in the `setUp()` method for relevant test cases.
* Ensure the mock context provided to the providers during
the tests is able to provide a context via `getApplicationContext()`.
Without this, the mock context throws an `UnsupportedOperationException`
when invoking this method.
Using whatever `Activity` as the `Context` used to construct the first content
provider means that it will be help onto in memory until the application is GC'ed.
Previously, all of the various subclasses of FDroidProvider would create
their own database open helper in their respective `onCreate()` methods.
This seemed to be the cause of the multiple database locked exceptions.
Various online articles/SO posts/etc helped come to this conclusion:
* http://stackoverflow.com/a/3689883
* http://stackoverflow.com/a/8888606
* https://web.archive.org/web/20150709074733/http://www.dmytrodanylyk.com/pages/blog/concurrent-database.html
This should fix#265.
In the process, also did away with the two `read()` and `write()` methods
that returned a "readable" and "writeable" database respectively. It turns
out that it doesn't quite do what I originally thought. There is not much
benefit to specifying to the database helper that you want a readable/writeable
database. In fact, it is often the case that a call to `read()` would most
likely have returned the same instance that is returned by `write()`. The
semantics of them were therefore broken, and they've been replaced with
`db()`.
This is what used to happen before the recent refactor to the search UI.
Finishing the main activity means that it never comes back to handle the
"View this app" intent again. Instead, the main Activity just becomes an
entry point for redirecting the UI to the correct place.
Incidentally, I don't particularly like the current solution even though
it should work, and hope to come up with a better one in the future. The
reason is because the behaviour of some methods (`onCreate()` +
`handleIntent()`) is what defines the behaviour of other methods
(`checkForAddRepoIntent()`). This means it is hard to reason about the
state of the activity at any point in time. Developers need to be careful
when making changes to the `onCreate()` method because modifying it has
unintended consequences. That is what caused the problem in issue #541.
Fixes#541.
Before, both the swap activity and the fdroid activity would use
the "handled" key to check if an intent had been handled. This caused
problems, because by the time we got to handling the add repo intent,
it had already been "handled" by the swap activity so we bailed.
Before, it only happened in onResume(). Now, it happens in onNewIntent()
too (but ensures to only handle the same intent once).
Note the onResume() only ever handles the original intent, not the new
intent.
Fixes#524.
The approach to creating fragments in the constructor of the `AppListFragmentPagerAdapter`
was incorrect. Fragments are a special kind of magic, so this commit uses the approach
documented at http://stackoverflow.com/a/15261142 to make sure that the correct
fragment instances are always retrieved.
Fixes#521.
Use custom layout for ACRA report dialog, not default one.
Styling the default dialog was difficult and it doesn't obey some
of the guidelines provided by the Android design docs:
https://www.google.com/design/spec/components/dialogs.html#dialogs-specs
(see "Content Guidelines")
This change introduces a custom dialog extending the base ACRA reporting
activity. Specifically, it introduces a padding of 24dp around the dialog
contents.
I couldn't find design specs on the specific spacing between different elements _within_ the dialog, so I used the same spacing of 20dp suggested to use between the title and the main body of the dialog.
At the very least, this change should make it easier to update styles in the future if somebody suggests improvements to the layout of the dialog.
### Before
### After
See merge request !186
Partially revert f2212e33. Make some constructors public again.
There is some code in the Android SDK using reflection to find the constructor
of one of our custom views. As such, a previous change in f2212e33 broke this
code because it made constructors package local. This partially reverts the bit
of f2212e33 which pertains to the constructors accessed using reflection.
Fixes#519.
See merge request !187
There is some code in the Android SDK using reflection to find the constructor
of one of our custom views. As such, a previous change in f2212e33 broke this
code because it made constructors package local. This partially reverts the bit
of f2212e33 which pertains to the constructors accessed using reflection.
Styling the default dialog was difficult and it doesn't obey some
of the guidelines provided by the Android design docs:
https://www.google.com/design/spec/components/dialogs.html#dialogs-specs
(see "Content Guidelines")
This change introduces a custom dialog extending the base ACRA reporting
activity. Specifically, it introduces a padding of 24dp around the dialog
contents.
This is thinking of the future, when new AFs are added and the installed
client doens't know about them yet. Showing the name is better than not
showing anything at all.
Fixes#517.
The problem was that again, only the `vercode`s of apks were being
compared to see if they were the same, rather than `vercode` and `id`.
The result is that some new apks will incorrectly be asked to execute
an `UPDATE` query rather than an `INSERT`. As such, they don't end
up in our database at all because the `UPDATE` will not run against
any row at all.
Correctly purge removed apks.
There were two bugs in this code that have been fixed. Both were
introduced while moving to a lower memory consumption version of
the repo updater for #324.
They were found while investigating #517, although I'm not confident
that they are to do with the specific problem in that issue. It is
possible, because it is part of the code to do with purging apks
from the database, but I'd like to do further investigations into
the code before declaring that this is actually related to that issue.
In the mean time, this includes important fixes, and should probably
go out in an alpha once merged.
The first is that for each app which is updated by a particular repo,
it was not correctly asking the question: "Which apks belonging to
this apk, and provided by this repo, are no longer provided by this
repo?". It was accidentally only comparing the version number of
existing apks in the DB and new apks from the index. This ensures
that the apks being checked to see if they need to be removed or
not are those with the same package name AND the same version code
(provided by the same repo).
The second bug is that when it was persisting a set of apps + apks
to the database, it would ask for existing apks already in the
database for these apps. In this case, there was a bug where of
the 50 apps being persisted, it would only retrieve the first of
these 50 apps from the database to decide if it needed to be
cleaned up or not. Now, it correctly retrieves data from the DB
belonging to all 50 apps.
See merge request !181
There were two bugs in this code that have been fixed. Both were
introduced while moving to a lower memory consumption version of
the repo updater.
The first is that for each app which is updated by a particular repo,
it was not correctly asking the question: "Which apks belonging to
this apk, and provided by this repo, are no longer provided by this
repo?". It was accidentally only comparing the version number of
existing apks in the DB and new apks from the index. This ensures
that the apks being checked to see if they need to be removed or
not are those with the same package name AND the same version code
(provided by the same repo).
The second bug is that when it was persisting a set of apps + apks
to the database, it would ask for existing apks already in the
database for these apps. In this case, there was a bug where of
the 50 apps being persisted, it would only retrieve the first of
these 50 apps from the database to decide if it needed to be
cleaned up or not. Now, it correctly retrieves data from the DB
belonging to all 50 apps.
Add HTTP Basic Authentication to ApkDownloader
In order to download protected files, the APKDownloader must be able to supply HTTP Basic Authentication headers to the server.
See merge request !178
