Lint finds these, but it's very slow and currently we're not taking lint
errors as fatal. So for now this script will be useful, as nearly every
time I pull from weblate there are at least a couple of these.
Translators:
agilob Polish
Hsiu-Ming Chang Chinese (Taiwan)
Nathan Follens Dutch
Perry Verheij Dutch
Robin van der Vliet Dutch
Robin van der Vliet Esperanto
Verdulo Esperanto
Wathiq Qajar Arabic
We still allow them in single-line statements, like:
if (foo) bar;
for (int i : ints) bar;
Everything else should use braces to help readability and avoid silly
human mistakes that might result in bugs.
These changes were completely automated via a python script.
Search: clear focus when enter/return is pressed
Fixes#572.
Assigning to @pserwylo since he wrote the current search widget stuff.
See merge request !206
Translators:
Coucouf French
Danial Behzadi Persian
Green Lunar Hebrew
Licaon Kter Romanian
M2ck French
Marian Hanzel Slovak
Verdulo Esperanto
Verdulo Polish
Work around dead activity issue in AppDetails
It seems like install() sometimes runs when the AppDetails activity is
finished or finishing. This results in the windows (dialogs) failing to
show, and a BadTokenException to fire:
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@d6e3570 is not valid; is your activity running?
This seems to be the culprit:
at org.fdroid.fdroid.AppDetails.install(AppDetails.java:840)
at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.install(AppDetails.java:1657)
at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.onListItemClick(AppDetails.java:1721)
Apparently, you can check whether an activity/context is being finished:
https://stackoverflow.com/questions/7811993/error-binderproxy45d459c0-is-not-valid-is-your-activity-running
I cannot reproduce this issue, thus can't say whether this fixes it or
not. Either way, it can't hurt to try. This can be reverted if we see
ACRA reports of this in the future, and the issue reopened.
Fixes#565.
See merge request !204
It seems like install() sometimes runs when the AppDetails activity is
finished or finishing. This results in the windows (dialogs) failing to
show, and a BadTokenException to fire:
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@d6e3570 is not valid; is your activity running?
This seems to be the culprit:
at org.fdroid.fdroid.AppDetails.install(AppDetails.java:840)
at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.install(AppDetails.java:1657)
at org.fdroid.fdroid.AppDetails$AppDetailsListFragment.onListItemClick(AppDetails.java:1721)
Apparently, you can check whether an activity/context is being finished:
https://stackoverflow.com/questions/7811993/error-binderproxy45d459c0-is-not-valid-is-your-activity-running
I cannot reproduce this issue, thus can't say whether this fixes it or
not. Either way, it can't hurt to try. This can be reverted if we see
ACRA reports of this in the future, and the issue reopened.
Fixes#565.
Fix 555 content provider invalid uri
Was not correctly encoding "/" characters when searching. This caused the Uri used by the Content Providers to include a slash, which makes it look like a separate segment of the path which was wrong. Now correctly encodes "/" characters. Also noticed one other place incorrectly encoding characters, where they would've been double encoded when added as query parameters to a Uri.
See merge request !203
Refactor swap "peer finders" to use ReactiveX
*NOTE: This includes the commit specified by !197.*
In the old code, there is a _lot_ of procedual style "Is this peer finder running, if so, do this". In addition, the choice to do things on background threads or not is a little ad-hoc. Finally, the `SwapService` needs to know about both bluetooth and wifi peer finders, whereas really they are both only there to emit "Peers", regardless of the type.
As such, some improvements in this change are:
* The choice to run peer finding on a background thread is made once, at a higher level when starting the peer finder.
* No longer does the UI code ask "Am I searching for peers". It instead waits to be told whether it is or isn't.
* The addition of new types of peers in the future is the job of the Peer finder itself. It quietly aggregates all of the Peer Finders it knows about into a single observable that emits different types of peers.
This code doesn't fix any particular issue, but rather it is about making the entire swap workflow easier to reason about. I plan on migrating more of this workflow to this functional style in the future, and hopefully that will have benefits in terms of stability and code understanding.
See merge request !198
Translators:
fabrizio maggi Italian
Gabriele Pau Italian
Irvan Kurniawan Indonesian
Karola Marky Latvian
Patrik Kretic Slovenian
riotism Chinese (Hong Kong)
I misread the documentation when first using the `appendEncodedPath` method,
because it expects the path to already be encoded. This causes a bug because
if you search for a '/'. The result is a malformed URI that has the path
'/search//' instead of '/search/%2F'.
Using `appendPath` will always encode the string given to it, which is desirable.
Also check for empty strings, and return a URI that gives all apps. This was
not strictly neccesary, because the code which invokes it checks for empty
strings, but if somewhere else in the future starts to use this code, they
would've had to know to check for empty strings first.
Fixes#555.
Put null check around access of `R.id.header` fragment.
Please note I haven't reproduced the specific problem. Also, the stack
traces being reported are only marginally informative, because they are
in response to a content providers firing events, and thus don't have
any context about when or where the event was fired from.
However, my looking at the code seems to indicate that this will prevent
NPE when the Activity is no longer visible but an app is finished
installing. Also, the view should still update correctly on resuming the
Activity because the `onResumeFragments()` methods will be invoked
which invokes the `refreshHeaders()` method.
Fixes#286.
See merge request !202
Please note I haven't reproduced the specific problem. Also, the stack
traces being reported are only marginally informative, because they are
in response to a content providers firing events, and thus don't have
any context about when or where the event was fired from.
However, my looking at the code seems to indicate that this will prevent
NPE when the Activity is no longer visible but an app is finished
installing. Also, the view should still update correctly on resuming the
Activity because the `onResumeFragments()` methods will be invoked
which invokes the `refreshHeaders()` method.
Fixes#286.
