Describe the bug:
When turning the OSM map when not all tiles are loaded the the app freezes.

To Reproduce:
Steps to reproduce the behavior:

1. from main screen open map
2. turn the mobile to lanscape / portrait

Actual behavior/state after performing these steps:
The app freezes.
After some time it is restarted and shows the main screen.

Expected behavior/state after performing these steps:
No freeze.

Version of WhereYouGo used:
master with PR #93

Is the problem reproducible:
Yes

Additional context:

 I/System.out: (HTTPLog)-Static: isSBSettingEnabled false
 W/System.err: java.io.InterruptedIOException: thread interrupted
 W/System.err:     at com.android.okhttp.okio.Timeout.throwIfReached(Timeout.java:145)
 W/System.err:     at com.android.okhttp.okio.Okio$2.read(Okio.java:138)
 W/System.err:     at com.android.okhttp.okio.AsyncTimeout$2.read(AsyncTimeout.java:211)
 W/System.err:     at com.android.okhttp.okio.RealBufferedSource.read(RealBufferedSource.java:60)
 W/System.err:     at com.android.okhttp.internal.http.HttpConnection$FixedLengthSource.read(HttpConnection.java:466)
 W/System.err:     at com.android.okhttp.okio.RealBufferedSource$1.read(RealBufferedSource.java:396)
 W/System.err:     at android.graphics.BitmapFactory.nativeDecodeStream(Native Method)
 W/System.err:     at android.graphics.BitmapFactory.decodeStreamInternal(BitmapFactory.java:726)
 W/System.err:     at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:702)
 W/System.err:     at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:740)
 W/System.err:     at org.mapsforge.android.maps.mapgenerator.tiledownloader.TileDownloader.executeJob(TileDownloader.java:67)
 W/System.err:     at org.mapsforge.android.maps.mapgenerator.MapWorker.doWork(MapWorker.java:97)
 W/System.err:     at org.mapsforge.android.maps.PausableThread.run(PausableThread.java:141)
 D/skia: ---- read threw an exception
 D/skia: ------ png error Read Error!
 W/MainApplication: onAppMinimized()
 W/PreferenceValues: disableWakeLock(), wl:null

While testing the fresh NB, the app asked me for permissions. While the permissions popup wre displayed, the changelog popup in the background was shaking up and down until I finished validating the permissions

To Reproduce:
Steps to reproduce the behavior:

1. On a device without the app
2. Download and install NB apk
3. Launch it

Actual behavior/state after performing these steps:
The changelog popup is shaking in the background

Expected behavior/state after performing these steps:
No shake in the background

Version of WhereYouGo used:
NB from 2020-03-03

Is the problem reproducible:
Not checked, sorry

Screenshots:
None

Currently WhereYouGo does only support maps of version 0.3.

Mapsforge stopped updating the v3 maps on their server in 2018. Most other provider of compatible maps also do not longer offer v3 maps.

In order to keep the offline map feature usable (and BTW also use the same map as for c:geo) a support of newer mapsforge versions is needed.

Describe the bug:

The map menu text color is black instead of white on Android 9.
This is nearly unreadable.
The text is white on Android 7.0.

To Reproduce:

Open the map view.
Open the menu.

Actual behavior/state after performing these steps:

Expected behavior/state after performing these steps:

Version of WhereYouGo used:

2020.03.05

Is the problem reproducible:
Yes

Lookin on CI and having installed the versions from different build jobs, I have seen, that nightly job builds with the addition "developer build" in the versionName.
It should be date-NB-commitID

As clarified in #52 we currently have to use a two step approach to sign the app for publishing on Google Play due to historic reasons:

1. Sign with an upload certificate (stored on our CI server)
2. Final signature with official app keys happens when uploading the APK to Google Play using this upload certificate

The downside of this approach is, that APK files produced by our CI server (such as nightlies and PR builds) can not be installed as upgrades of the official version.

While this is only a minor problem, it would however desirable to use the same keys everywhere.
As @menion mentioned in a comment we should revisit this topic once the existing keys need to be renewed anyway.

Describe the bug:
Using the beta version 2020.03.05 no map tiles are loading for me independently which only provider I choose.

To Reproduce:
Steps to reproduce the behavior:

1. Start WhereYouGo
2. Select map
3. Choose between the various sources in Menu - Map type

Actual behavior/state after performing these steps:
None of those I tried show any tiles on my device. Empty (white) map.

Expected behavior/state after performing these steps:
Map tiles should be shown.
Additionally I guess, that some tile providers are no longer available/valid (e.g. OpenCycleMap is no longer available for free). But however I guess Mapnik should work like it does in c:geo.

I wasn't able to check the logs yet.

Version of WhereYouGo used:
2020.03.05

Is the problem reproducible:
Yes

Additional context:
Samsung S10, Android 10

When trying to download a cartridge (e.g. initiated by c:geo) then there is no check if username/password configured. If nothing configured then the app gives an I/O error:

(see DownloadCartridgeActivity DownloadTask(DownloadCartridgeActivity.this, username, password); )

While downloading is confirmed working by all beta testers, there are some reports about not being able to play cartridges. We did not actively change any code in this part, however due to the raised targetSDK I guess there might be new problems.

I am currently waiting to get some GC-codes where cartridges are problematic. I tried to start several and had no problem so far.

Same as for c:geo also WhereYouGo could take advantage of crowd based translation contribution using crowdin.org

Currently no checkstyle rules are defined.
This should be done and could be done by using/adopt the rules from cgeo.

Copied from biylda/WhereYouGo#11
Please look there for the detailed thread history.

Hi,

Variable arguments eg. function i18n(key, ...) are not supported in WhereYouGo.
The emulator works well with them, but not WhereYouGo.

I suppose I also have this problem.

The cartridge from
http//www.wherigo.com/cartridge/details.aspx?CGUID=002b0a3a-1e2d-4a7a-bc93-9ce523eac2d2
contains the game in English and Norwegian, and this is to be selected upon start of the game.
However, the game is only available in English in WhereYouGo.

The problem is OpenWIG, the Wherigo engine WhereYouGo uses. It hasn't a complete Lua implementation.

I had a quick look at the repositories for OpenWIG. SourceForge and Google
Code looks abandoned. There were a few GitHub ones, all autoimported.

How to proceed on this one? Perhaps an initiative to join forces on GitHub?

;)Frode

As I know, Jan (other of OpenWIG) don't do anything new on OpenWIG. So there isn't any help from this side.

OpenWIG itself uses Kaluha, a Lua implementation for J2ME (see http://lua-users.org/lists/lua-l/2007-05/msg00174.html for the announcement). So, if you want to solve the problem, you have to look into the Kahlua implementation of OpenWIG.

Thank you for providing pointers as to where to start the debugging. This
sure will come in handy for whoever takes on the issue.

Now, I don't have the programming experience to do this. And I don't have
the time to aquire it at present either.
I am more tenured in filing bug reports than actually fixing them.

Seems this task is up for grabs, then.

;)Frode

Describe the bug:
Error report appeared as in screenshot. Was trying to open a saved Wherigo cartridge.

To Reproduce:
Steps to reproduce the behavior: have been unable to reproduce the behaviour however I was opening a saved game for https://coord.info/GC864D5

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'

Actual behavior/state after performing these steps:
Error message kept appearing despite pressing 'OK'. Had to exit WhereYouGo to get it to stop.

Expected behavior/state after performing these steps:
I expected the saved game to open and allow normal play.

Version of WhereYouGo used:
2020.03.08

Is the problem reproducible:
No

Screenshots:
Attached

Additional context:
Nil

It would be helpful to have a continuous integration environment for this repository enabling

• static code checks
• nightly builds
• app signing for preparing to publish

The c:geo CI could be reused for that purpose.

Copied from biylda/WhereYouGo#23

Hello,

first of all, thank you very much for your work.

I have problems to play videos a new feature from you. I tried different MP4 videos. Than I took a look into the code, and it seems, that the viedeo isn't started. With this stack overflow (https://stackoverflow.com/questions/17399351/how-to-play-mp4-video-in-videoview-in-android), I assume, that you have to start the video when the VideoView is prepared. Is this correct? Or do you have any cartridge to test this behavior?

Best regards,
Charlenni

The Release Notes are currently maintained on 3 places

• README.md (version 0.10.0 changes in the "new" part)
• main/assets/news.txt (only version 2020.03.05 text)
• _data/changelog_en.txt /changelog_de.txt (only version 0.10.0 changes)

This need to be harmonised.

On WhereYouGo I can only use the GPS from my mobilefone.

All other apps can use external GPS connected with Bluetooth.

There are some outputs in the CI builds which says that we need a NDK installation.
(see e.g. https://stackoverflow.com/questions/53437653/android-studio-missing-strip-tool)

> Task :mergeDebugNativeLibs
 Unable to strip library '/home/jenkins/slave/workspace/whereyougo (PR)/build/intermediates/merged_native_libs/debug/out/lib/armeabi/libpl_droidsonroids_gif.so' due to missing strip tool for ABI 'ARMEABI'. Packaging it as is.
> Task :stripDebugDebugSymbols
 Compatible side by side NDK version was not found.
 Unable to strip library '/home/jenkins/slave/workspace/whereyougo (PR)/build/intermediates/merged_native_libs/debug/out/lib/x86_64/libpl_droidsonroids_gif.so' due to missing strip tool for ABI 'X86_64'. Packaging it as is.
 Unable to strip library '/home/jenkins/slave/workspace/whereyougo (PR)/build/intermediates/merged_native_libs/debug/out/lib/x86/libpl_droidsonroids_gif.so' due to missing strip tool for ABI 'X86'. Packaging it as is.
 Unable to strip library '/home/jenkins/slave/workspace/whereyougo (PR)/build/intermediates/merged_native_libs/debug/out/lib/arm64-v8a/libpl_droidsonroids_gif.so' due to missing strip tool for ABI 'ARM64_V8A'. Packaging it as is.
 Unable to strip library '/home/jenkins/slave/workspace/whereyougo (PR)/build/intermediates/merged_native_libs/debug/out/lib/armeabi-v7a/libpl_droidsonroids_gif.so' due to missing strip tool for ABI 'ARMEABI_V7A'. Packaging it as is.

Currently the app uses version codes like e.g. 0.9.3.
I suggest to migrate to a similar date based version code and version name as used in c:geo.

Using a date based version code has certain advantages when it comes to different versions like nightlies, RC and production. Additionally we could reuse the related scripts to set the version code/name on our CI.

When I open a Wherigo.com cartridge link, I can open and download it with Wheryougo. If I open a cartridge link from the Wherigofoundation, I have to open and download the cartridge with the web browser and then move it to the WherYouGo folder. This is complicated to find when you do it for the first time. Or if you rarely play wherigos.
I am an owner of some wherigos and I am often asked how it works with wherigofoundation.

Copied from biylda/WhereYouGo#19

In the lastest version I've found an issue regarding internal compass jumping from true values to completely faulty values and (eventually) back to correct values if there is a timer running in the background of the cartrdige.
Details and a testcartdridge for showing the issue can be found on:
https://groups.google.com/forum/#!topic/whereyougo/Vt6HD2c0Wws

It would be great if someone could have a look at this issue... thanks in advance.
Patrik

The following could be done (feedback welcome):

• Create a facebook page for WhereYouGo (currently not existing)
  This has just been done and I invited @mucek4 as second administrator
• Create a new mailbox (e.g. [email protected]) to channelize support mails rather than using the current Google Group, which we cannot adminsitrate/moderate
• Create a homepage

Currently defined in the project:

    // openwig with extentions
    implementation 'com.github.biylda:openwig:3a1e405'

What do we want to do in future?

I know a number of people using a Google-free (as much as possible) smartphone for geocaching, and like c:geo, WYG should be available for them. Are there plans to upload to F-Droid, or provide a separate repo, in addition to releases on GitHub?

While cloning the original repository I did also include the obvious stale branches which have commits ahead of master.
It needs to be evaluated if there is anything helpful in there, otherwise they could be deleted.

While testing the nightlies based on master I was unable to install the nightly version as of today on top of the already installed 0.9.3 (latest Playstore version).

Not sure why it fails.
As far as I can see the version code is untouched

Could either be a problem with the signing key(?) or do we alter the version code during build on the CI for the whereyougo nightlies?

To remove no longer working links and links to the old repository.

See here:
biylda/WhereYouGo#33

c:geo currently uses newer libraries. Maybe synergies apply.

We target (latest with PR #36) the current requirements for google play.
I think that we should create a new version of WhereYouGo as soon as possible only with PR #32 and #36.

When developing Wherigos, using GWZ files can be easier to handle than GWC, e.g. you can open them with ZIP Editor and quickly change resources. Applications like webwigo.net allow opening GWZ, so it would be nice to have in WhereYouGo as well.

Extracted from findings in #40, this isn't supported yet, please correct me if I'm wrong and just made a mistake when testing this.

The AndroidStudio 3.6 is out.
It needs the gradle plugin 3.6.0.
And for this gradle has to updated at least to 5.6.4.

I think we should stay at the current AS 3.5.3 until the next c:geo and WhereYouGo releases are released.

On high res displays, such as the Samsung S9+, offfline map is rendered at native pixel resolution which makes it almost unreadable because of high ppi density

AFAIK this has been dealt with in c:geo.
Also related to #73

In WhereYouGo are currently on most source files header with a license information and partly a author information.
In c:geo is this not realized.

We should dicuss and define a standard procedure for the future.

• Open a cartridge which requires a text input (e.g. from GC6RAXK)
• Start the cartridge until you reach the query to enter your desired language
• Use the button "Scan QR code"
• Device asks for camera permission
• (Permanently) deny permission

Result:

• An error message is shown (from an external or a integrated app)?
• Closing the error message brings you back to the cartridge
• No further explanation

Expected result:

• Show similar dialog as for location/file permission

Now that we have access to the Play console I have seen, that currently different APK packages are published covering a variety of different API levels.

This does IMHO not look so meaningful and needs to be flattened:

Issue labels need to be defined (e.g. aligned to cgeo/cgeo repository or a subset of them).

Took a first look into Google Play crash reporting.
This is the crash report with highest occurence.

Android 9 and 10

java.lang.RuntimeException: 
 
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:3430)
 
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:3614)
 
  at android.app.servertransaction.LaunchActivityItem.execute (LaunchActivityItem.java:86)
 
  at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:108)
 
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:68)
 
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2199)
 
  at android.os.Handler.dispatchMessage (Handler.java:112)
 
  at android.os.Looper.loop (Looper.java:216)
 
  at android.app.ActivityThread.main (ActivityThread.java:7625)
 
  at java.lang.reflect.Method.invoke (Native Method)
 
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:524)
 
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:987)
Caused by: java.lang.NullPointerException: 
 
  at menion.android.whereyougo.gui.extension.activity.MediaActivity.setMedia (MediaActivity.java:72)
 
  at menion.android.whereyougo.gui.activity.wherigo.PushDialogActivity.nextPage (PushDialogActivity.java:82)
 
  at menion.android.whereyougo.gui.activity.wherigo.PushDialogActivity.onCreate (PushDialogActivity.java:124)
 
  at android.app.Activity.performCreate (Activity.java:7458)
 
  at android.app.Activity.performCreate (Activity.java:7448)
 
  at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1286)
 
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:3409)

Describe the bug:
After installation of WhereYouGo and selecting "Map" from the main menu the user only sees an empty map.

To Reproduce:
Steps to reproduce the behavior:

1. Install WhereYouGo and start it
2. Select "Map" from the main menu

Actual behavior/state after performing these steps:
You will see an empty map screen and have to manually select the map source (once, then saved) to finally see the map.

Expected behavior/state after performing these steps:
For a good user experience we should set a default online map source.

Version of WhereYouGo used:
2020.03.08

Is the problem reproducible:
Yes

On first start a information window is shown.
While containing links have been updated to our repo, we could include a short information about what has happened to the app.

Copied from: biylda/WhereYouGo#20

I've tested a cartridge on both a Samsung J3 and S8 on both I don't seem to get stretched images.

PICTURE IN ORIGINAL ISSUE

In my cart I'm using 230px wide images as recommended by the whergio FAQs

I've also noticed that the size of images is also variable, I can load the same item multiple times getting different results each time, See below for example, I've previously also got blank images but can't replicate right now.

win_20170820_10_00_46_pro
win_20170820_10_01_00_pro

Example generated using a very simple test cartridge with one media item listed as the image for one zone.

-UPDATE-

Have just realised that the issue is only present with GIF images, If I use BMP, JPG or PNG they all stretch OK

Frustrated about:
All time-related ideas are pointless because any cacher can trick them by changing the system time of his mobile phone.

Solution:
The WhereYouGo player looks for an "environment variable", which is defined in the cartridge and then uses the specified time-source, e.g.
env_usetime=gps
env_usetime=system

not so good:
Since v0.9.2. input can be scanned from qr-code.
However, I have observed the following:
New cachers (and there will always be new cachers) are irrateted.
They see a button "scan qr", they press the button, a camera window opens ... and the cachers begin to search a qr-code ... (although there is no qr-code to find).

Therefore i suggest, to make the "scan qr"-button optional.

Solution:
The WhereYouGo-player looks for an "environment variable", which is defined in the cartridge and then displays the scan-button - or not.

env_inputQR= yes/no

and maybe even

env_inputNFC= yes/no

Copied from biylda/WhereYouGo#8

Hi!

Hopefully this is the correct place to report potential bug as the exception references openwig.googlecode.com which seem to have move.

Suprisingly a could't find this problem mentioned below, but probably I searched at the wrong places.

In the middle of the development of my cartridge - which work well in the urwigo-simulator also with no problems with save/and resume - I testet it on the smartphone: Lot's of java exceptions when I resumed a saved game: especially index of non-table and calling nil! I updated to the current version
same result.
So i started to analyse the problems. I am using tasks (also partly LUA-function in there). The problem at the resume-time seem to be, that the taskcompletion is called (which migth be ok and is ok to me), but there aren't any "objects" already "initiated"!
So a call of e.g.:

lua-function (call nil)
setting an attribute of item, character,.. (index of non-table)
move item to player
...

fail, as all "the reference" is nil and I think this is bug.

Of course I can implement a workaround, but I have to put it in many task ...
So probably there is a simpler workaround (some settings) or I did something wrong, ...

I implemented an easy cartrige, to eliminate potential problem caused by me.
I attach this simple/short cartrige with no lua and just in urwigo (urwigo und compiled code attached) for reproduction of this problem:

Start cartrige
Schweizermesser.CloseTask
Exit with save
Start with resume -> java exception (just for a short time)
Exit no save -> java exception (til press away)

I'am currently working with urwigo and on an Samsung GT-S5690 Android: 2.36 /Gingerbread ( Kernel2.6.35.7).

If additional Information is need just let me know.

Thanx in advance for help or fixing the bug
hansmen

testtask.zip

For a normal cgeo/Whereyougo user it is not always clear that Whereyougo is a separate application with own settings and the credentials for www.geocaching.com/www.wherigo.com have to be entered again.
The fact is the reason for problems with login and downlaod of cartridges.
Many times people have problems with the login and download and ask for a solution in forum and facebook groups. The most reason for the problem is missing credentials in Whereyougo.

Solution: Give the user an annoucement if credentials are missing and open (the settings) a dialog for enterring the credentials.

We should make this old version available to users via some download location to allow fallback in case they are affected by the regressions described in other issues.

Need to check tomorrow If I have the APK of 0.9.3. somwhere or if its stored on the old repo.

Describe the bug:
A friend submitted the following recordings to me via WA and commented:

This happens on any cartridge, some stored months ago, some recently [test builds for unpublished caches].

After some short time in the cartridge, it seems to happen on an interaction with zones or items, I'm booted out back to the main menu. (The error message "invalid cartridge" that pops up is appearing since I had messed up a cartridge some earlier time, but it didn't go away after fixing it. It should not be related with the current problem).

The folder is set to the Android Downloads so I can download cartridges via browser and have them available in the app immediately [workaround for the not working direct download in the time before the update].

The problem seems independent of the cartridge source, e.g. local test build or website download.

This happens only since the update (they hadn't used the beta).

On a secondary device, this problem is not present [and on my device it's also not present].

Is the problem reproducible:
No

To (possibly) Reproduce:
Steps to reproduce the behavior:

1. Set the cartridges directory to the Android Downloads folder.
2. Download and start some cartridge
3. Interact with zones or items
4. Crash without specific error message

Actual behavior/state after performing these steps:
Cartridges are stopped spontaneously.

Expected behavior/state after performing these steps:
Cartridges should run smoothly.

Version of WhereYouGo used:
08.03.2020 release, errors on Huawei P10 lite, no problems on Samsung J415FN and Galaxy S4.

Screenshots:

Additional context:
I think I have seen similar reports of varying verbosity on the Facebook page.

Since 1. November 2019 it is necessary to define targetSdkVersion to 28 (Android 9).
See
https://developer.android.com/distribute/best-practices/develop/target-sdk
https://support.google.com/googleplay/android-developer/answer/113469#targetsdk

Also from Google Play reports. Second highest in ranking of highest occurence.

Android 9+10

java.lang.RuntimeException: 
 
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:3430)
 
  at android.app.ActivityThread.handleLaunchActivity (ActivityThread.java:3614)
 
  at android.app.servertransaction.LaunchActivityItem.execute (LaunchActivityItem.java:86)
 
  at android.app.servertransaction.TransactionExecutor.executeCallbacks (TransactionExecutor.java:108)
 
  at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:68)
 
  at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2199)
 
  at android.os.Handler.dispatchMessage (Handler.java:112)
 
  at android.os.Looper.loop (Looper.java:216)
 
  at android.app.ActivityThread.main (ActivityThread.java:7625)
 
  at java.lang.reflect.Method.invoke (Native Method)
 
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:524)
 
  at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:987)
Caused by: java.lang.ClassCastException: 
 
  at menion.android.whereyougo.gui.extension.activity.CustomMainActivity.onCreate (CustomMainActivity.java:233)
 
  at menion.android.whereyougo.gui.activity.MainActivity.onCreate (MainActivity.java:356)
 
  at android.app.Activity.performCreate (Activity.java:7458)
 
  at android.app.Activity.performCreate (Activity.java:7448)
 
  at android.app.Instrumentation.callActivityOnCreate (Instrumentation.java:1286)
 
  at android.app.ActivityThread.performLaunchActivity (ActivityThread.java:3409)

Is your feature request related to a problem?
When I want to play a new cartridge, I have to download it (possible by e.g. opening the wherigo.com link with WhereYouGo), but a downloaded cartridge can not be opened directly from the android file browser with WhereYouGo.

Describe the solution you'd like
Allow opening a cartridge from the system storage, either from anywhere by opening it (declaring in AndroidManifest.xml an intent filter for .gwc and .gwz) This would by the way also provide a workaround for the problem that c:geo attempts to open cartridges, even if not solving that it pretends to be able to open any file with the line <data android:mimeType="application/octet-stream" />.

Additional context
See cgeo/7663