| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |
|
|
|
| |
On SDK >= 8, Math.floor and Math.ceil are faster than FloatMath
equivalents.
|
| |
|
|
|
| |
save() and restore() are more adequate to restore the initial state and
prevent rounding errors.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
PeriodicHandler now uses weak references to keep a link to the looper
that requested it. This way, it will not prevent the source from being
garbage collected even though a delayed message may be queued in the
handler.
Also, at the next iteration, the periodic handler will notice that its
starter looper has been garbage collected and will stop itself if it has
not been already.
|
| | |
|
| |
|
| |
* If you get compile errors, upgrade to ADT 20 and SDK 20
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
main/src/cgeo/geocaching/DirectionProvider.java
main/src/cgeo/geocaching/ui/CacheListAdapter.java
|
| | |
| |
| |
| |
| |
| |
| | |
Also, use float instead of double for every angle computation.
Conflicts:
main/src/cgeo/geocaching/ui/CacheListAdapter.java
|
| | |
| |
| |
| |
| |
| |
| | |
We have to ensure that the direction stays within the right range when
computing a smooth update.
Related to issues #1680 and #1685.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix for #1680 introduced in ad93745d42f9aaf5bc4925075987ef64c13b2f71
had to account for the possibility of angles being outside the [0, 360[
range.
Commit 0034e358668d5911639628468be7409b2696d6c5 fixed #1685 and now
ensures that the returned orientation is within the right domain range
even after the phone rotation has been added to the sensor angle.
It is now possible to simplify the computation because we now that the
difference of two angle values will always be in the ]-360; 720[ range,
and can this fixed by adding 360 and taking the module with 360 to enter
back the [0, 360[ range.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Also, use float instead of double for every angle computation.
|
| | |
| |
| |
| |
| |
| |
| | |
We have to ensure that the direction stays within the right range when
computing a smooth update.
Related to issues #1680 and #1685.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The fix for #1680 introduced in ad93745d42f9aaf5bc4925075987ef64c13b2f71
had to account for the possibility of angles being outside the [0, 360[
range.
Commit 0034e358668d5911639628468be7409b2696d6c5 fixed #1685 and now
ensures that the returned orientation is within the right domain range
even after the phone rotation has been added to the sensor angle.
It is now possible to simplify the computation because we now that the
difference of two angle values will always be in the ]-360; 720[ range,
and can this fixed by adding 360 and taking the module with 360 to enter
back the [0, 360[ range.
|
| | | |
|
| |/ |
|
| |
|
|
| |
This will help with issue #1604.
|
| |
|
|
|
| |
The initial values were never used as the variables are set in any case
before being used.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The behaviour is unchanged, but altering Settings.isDebug() to return
false will prevent verbose, debug and info levels messages from being
logged.
Part of work on #1301.
|
| |
|
|
|
|
| |
* avoid creating message objects, there is a pool
* only get GCVotes for filtered caches, not for all
* don't use GepointParser in LocParser, we know those are pure floats
* String concatenation
|
| |
|