'src' works because we're only doing java files under that directory.
But it would be slower than needed, and in the case of PMD it would also
use the test files which wasn't intended at all.
It seems like having it as a compile dependency already works for the
tests. Having it duplicated seems to sometimes trigger errors (e.g. a
user reported a duplicate zip entry due to the duplication) and might
also be problematic if we don't keep the two versions in sync.
Random fixes from DownloaderService hacking
Here are some random fixes that I did in the process of the DownloaderService refactoring. I don't think anything should be controversial. Thanks for your rapid code reviews recently @mvdan :)
See merge request !245
"Consider using apply() instead; commit writes its data to persistent
storage immediately, whereas apply will handle it in the background"
commit() is only useful if the code actually checks the return value.
* Use a % sign that String.format() recognizes, apparently there are more
than one % signs, in Chinese, its big: ％
* a string in lithuanian forgot the %s
More DownloaderService progress
As part of the incremental approach of moving downloading to an IntentService, here are a few more commits refactoring things into events instead of listerners/callbacks/etc.
ping @pserwylo
See merge request !240
An AsyncTask ties into the UI thread for things like onPostExecute(). If it
is run within an AsyncTask, then it freaks out because it can't tie into
the UI thread. We don't need it to do that here anyway, so just use a
plain Thread, and set the priority to background.
As part of the process of moving the APK downloading to an
IntentService, I'm removing and incrementally reorganizing the
existing events so that the code continues to be functional as it is
reorganized. We might want to include more detail in a download error
to expose to the user, but I think instead what will be more fruitful
is to hide details on errors where there is nothing the user can do
except retry. Then if there are errors where the user can do
something about it, then F-Droid should instead offer them the option
of doing that, and not just show an error message and walk away.
This is part of the move to standardizing all internal broadcasts to use
the Intent's Uri field as the standard place for a download URL, and then
using that in IntentFilters to do matching.
Fix version upgrade string for RTL languages
In right-to-left languages _forward_ is the direction to the left, so leftwards arrow should be used to indicate upgrade:
For left-to-right languages it remains the same:
Closes#609.
See merge request !235
Simplify Downloaders
This is some groundwork to simplify the Downloader stuff in preparation to moving it to something like an `IntentService`, as part of #601. This mostly removes unused bits that I've found in the process of writing the `DownloaderService`. Some of these events will be added back in a more consistent way, so that there is one event type for the same idea throughout the code base.
See merge request !236
This also removes all the related stuff that resulted in
EVENT_APK_DOWNLOAD_CANCELLED being sent. Since EVENT_APK_DOWNLOAD_CANCELLED
ultimately does nothing, that whole bit of plumbing is unused.
Allowing all downloads, including updates, to be canceled simplifies the
code and if the user wants to cancel an update, they should be able to. But
canceling updates is not implemented in this commit.
This makes it so gradle provides all dependencies, rather than a mix of
classes that are copied in versus imported via gradle. This library is
already used by the tests, so its not really a new dependency, and proguard
should remove all the unused stuff.
Since this is internal code and not a library for use with other projects,
it should only include the methods that are actually in use. The other
copies are just dead code, which means more stuff to read in order to
figure out.
Unfortunately, this approach did not really work out. It would have been
really nice to rely on the provided DownloadManager stuff, but it has too
many issues, like not working with Tor or other proxies, and being
difficult to tightly integrate.
start porting tests to latest Android Studio/gradle setup
To encourage more people to use and add to the test suite, I've been working on making it work nicely with Android Studio and gradle. I've also setup the possibility for JUnit tests that run on the host machine, not the emulator. Those are run with `gradle test`. I added a JUnit test of `HttpDownloader` too.
See merge request !233
"Variable explicitly initialized to 'false' (default value for its type)"
I never remember what the default init value of booleans are, so this error
is quite annoying to me, and I can't see the harm of this behavior.
checkstyle says: "So in this case, x gets initialized to 0 twice, and bar
gets initialized to null twice. So there is a minor inefficiency."
This makes it a lot easier to setup all the testing stuff. Mostly,
I'm tired of fighting Android Studio's fragility, so I want to remove
as much non-standardness as possible in the hopes of improving that
situation.
closes#534https://gitlab.com/fdroid/fdroidclient/issues/534
This is the last Android code in the whole suite of Downloader subclasses,
so now we can write JUnit tests for them all, and avoid the fragility of
tests running on the emulator.
When running tests on the host machine, android.jar contains no code at all
which is totally stupid. We can keep android.util.Log in there because it
does not affect the logic at all. Then just set that android.jar to return
generic values using:
unitTests.returnDefaultValues = true
If there is no LocalBroadcastManager, then the Downloader tests can be done
with pretty plain JUnit and then do not require the Android emulator to run
Fix crash when returning to swap after cancelling
Fixes#409. The problem was that there was some listeners being added for broadcast events when the swap view was shown. These were never removed, and so cancelling swap, then returning to it would spin up a _new_ activity with new views, while the old listeners were still around. When the old listeners received events, they would try to talk to their associated `Activity`. This no longer existed, so a crash ensued.
While I was fixing the specific bug associated with #409, I took the opportunity to make more of the event listeners well behaved in the swap process. I don't think any of them were liable to cause crashes, but were likely to cause some weirdness at some point in time if they were not fixed.
*Note:* This swap view was an exercise in moving away from `Fragment`s towards an `Activity` with individual `View`s. I'm going to call this a bit of a failure at this point, because there is so much work that needs to be invested in implementing lifecycle stuff in our custom views. `Fragment`s naturally come with lifecycle methods that are familiar to other Android dev's looking to contribute to this project (even if they are a little difficult to understand at times). Implementing our own custom Views instead still results in similar classes of bugs (i.e. talking to an `Activity` when the view no longer is part of that activity).
A classic example of this is in my usage of the `onDetachedFromWindow` function in the `View`. I have no idea if this is the best place to unregister listeners or not. In a Fragment, it would be a matter of `onPause` or one of the more well defined lifecycle methods. Empirically, `onDetachedFromWindow` seems to be well behaved. The other alternative would be for the Activity to explicitly invoke a `onRemoved` type method each view when it knows it is transitioning from one state to the next. However at this point, we are then really into reimplementing `Fragment` land.
See merge request !232
Translators:
ageru French
Ajeje Brazorf Sardinian
Mohamad Hasan Al Banna Indonesian
Paresh Chouhan Hindi
YFdyh000 Simplified Chinese
YF Simplified Chinese
Pass through a known good `Context` to `translateCategories`
All the good work to make sure that `getActivity()` actually returned
a proper context, obtaining a final reference to that known good activity
object, and then using that in the background thread is thrown away.
The reason was because the `translateCategories` method would go and
call `getActivity()` all over again. This changes the `translateCategories`
helper function so that it asks for a `Context`. This way, a known
good `Context` can be passed in, rather than having to perform a check
to see if `getActivity()` is good again.
Fixes#603 (Hopefully)
See merge request !231
