[Feature Request] Map of spots

Hi, I’m Ian, the developer of Field Spotter (https://fieldspotter.radio). It displays spots from various programmes on a map. I made it to give myself a better visual idea of where spots are relative to the range and “skip” I think I have on my current band, e.g. I can probably reach the US east coast on 10m but not the west, so a map gives me a better idea than just the ability to toggle continents on & off on a list.

Thanks to all the great functionality in PoLo I no longer have to visit pota.app, Sotawatch etc. - Field Spotter is now the only thing I leave it for.

So the obvious question is, how do you feel about adding a spot map to PoLo?

If it’s of any interest, I’m happy to have a bash at implementing it myself. I’ve not used Node or React before but have some experience of vanilla JS in the browser.

I am thinking perhaps of a simple set of dots coloured by band similar to the existing QSO map. Clicking one would then bring up a variant of the existing popup with the callsign, reference and frequency, then clicking that would switch to the QSO view like clicking a spot in the list currently does. Maybe greying out spots you have already worked, as per the strikethrough in the list.

Of course if this feature isn’t of interest, I completely understand - just thought I’d throw it out there in case!

1 Like

It’s not a bad idea.

I ahve a few things already “in the oven” so I don’t think I can tackle it in the next couple of months, but why don’t you give it a shot. Ask here or in the discord server for any help you need setting up a dev environment or finding your way around the codebase.

Thanks, I’ll have a go at setting up the dev environment this weekend.

Sorry to bother you, but I’ve run into a problem when trying to run the application in the dev environment (Android emulator set up with ADK v34 as per React instructions, running on Debian Bookworm, npm 9.2.0, node 18.19.0).

I have set up my environment, run npm install, and am now running npm run android -- --mode alphaDebug to start the Android emulator. The emulator window appears, but the application isn’t there. In the terminal I have the following error:

error Failed to install the app. Command failed with exit code 1: ./gradlew app:installDebug -PreactNativeDevServerPort=8081 FAILURE: Build failed with an exception. * Where:
Build file '/home/ian/code/app-polo/android/app/build.gradle' line: 100 * What went wrong:
A problem occurred evaluating project ':app'.
> Could not get unknown property 'MYAPP_UPLOAD_STORE_FILE' for SigningConfig$AgpDecorated_Decorated{name=release, storeFile=null, storePassword=null, keyAlias=null, keyPassword=null, storeType=pkcs12, v1SigningEnabled=true, v2SigningEnabled=true, enableV1Signing=null, enableV2Signing=null, enableV3Signing=null, enableV4Signing=null} of type com.android.build.gradle.internal.dsl.SigningConfig$AgpDecorated.

I am new to Android apps so I’m not sure exactly what the deal is with signing. I assume you have a key to sign your releases to the Play Store which is obviously not committed to the public repo.

Based on some filesystem digging and StackOverflow answers, is there a step I need to take where I need to generate and set up my own key, or perhaps I just have to add some config to gradle.properties to use the included debug.keystore?

I can get the build to go further by adding the following to gradle.properties, although I’m not sure this is a reasonable thing to do, just grasping at straws really:

MYAPP_UPLOAD_STORE_FILE=debug.keystore
MYAPP_UPLOAD_KEY_ALIAS=debug
MYAPP_UPLOAD_STORE_PASSWORD=
MYAPP_UPLOAD_KEY_PASSWORD=

However, I then get some more Gradle errors which look like it is not successfully importing React dependencies:

> Task :app:compileAlphaDebugKotlin FAILED
e: file:///home/ian/code/app-polo/android/app/src/main/java/com/polo/MainApplication.kt:16:12 Unresolved reference: rollbar
e: file:///home/ian/code/app-polo/android/app/src/main/java/com/polo/MainApplication.kt:48:7 Unresolved reference: RollbarReactNative

I will continue hunting around online for potential fixes but if you or anyone out there is more experienced with React Native, Gradle & Android, and can point me in the right direction, it would be much appreciated!

Thanks

We removed rollbar a while ago. Looks like we had some stray references.

I’ve pushed to main a new commit that clears those up. Can you give it a new try?

Thanks, that’s definitely getting further now! Next issue looks like it might be another key-related thing, but this time in generated Java code:

/home/ian/code/app-polo/android/app/build/generated/rncli/src/main/java/com/facebook/react/PackageList.java:105: error: cannot find symbol new CodePush(getResources().getString(com.ham2k.polo.R.string.CodePushDeploymentKey), getApplicationContext(), com.ham2k.polo.BuildConfig.DEBUG), ^ symbol: variable CodePushDeploymentKey location: class string
1 error FAILURE: Build failed with an exception.

Discourse formatting has mangled the bit it’s pointing to there, but it looks like CodePushDeploymentKey doesn’t exist:

I’m reading the React Native Code Push docs and it suggests that it might need to be set in strings.xml, does it matter what it’s set to?

Quick update - I decided to have a go and just set it anyway, and it looks like it works!

Next question then - how can we make this easier for future devs? I have a branch with a couple of tweaks to README.md that I would like to raise a PR for soon. But I have now made a couple of undocumented changes to my working copy in order to get the software to compile:

In android/gradle.properties:

MYAPP_UPLOAD_STORE_FILE=debug.keystore
MYAPP_UPLOAD_KEY_ALIAS=debug
MYAPP_UPLOAD_STORE_PASSWORD=
MYAPP_UPLOAD_KEY_PASSWORD=

And in android/app/src/main/res/values/strings.xml:

<string name="CodePushDeploymentKey">test</string>

Should I update the README to recommend that other new developers start by making the changes as I have done, or is there a better way?

Make a PR with the changes to gradle and README, but leave the CodePush string out.

I just pushed a commit getting rid of any CodePush references. This should not be part of main, and it only gets added for the official app store releases.

I wonder if we should put the MYAPP_… definitions in .env instead of gradle.properties

That sounds like a good idea. I’ll give it a try and make sure it still works, then I’ll put the PR in. It’ll be tomorrow as I’m heading out for the evening now. Thank you for all your help getting me started!

Sorry I’ve stalled on this one for a while - real life got in the way as it does :slight_smile:

I have a couple of frustrations at the moment which I’m happy to keep plugging away at myself, but I thought I’d ask just in case I’d missed something obvious that someone else could answer in seconds:

  1. I can’t seem to get the maps to reliably work on the emulator (not just for my new map but the existing QSO map as well). Search results aren’t particularly enlightening. Does this work for you and I’m just doing something wrong?
  2. Is there a good way of setting breakpoints and debugging the app, or even just printing to the log and viewing the log for the specific app? I’m just trying to do some basic stuff like figure out what keys a spot or qso object actually has, but I can’t find an obvious way to do so!

(moving this thread to the Development category)

What kind of problems are you having with the maps? There are some API keys I have for the production builds, and maybe that makes a difference? But I think that maps keys are just handled by Android / Play Store.

Maybe the emulator you created does not have the right base image? I mostly test with these settings:

As to debugging, it’s a bit painful with React Native. There is a new set of dev tools but it requires upgrading to RN 0.75 or 0.76 and there are some other dependencies of PoLo that don’t support those versions yet. I’ll see if I can do the update after releasing the December version.

Thanks. I have the same here, apart from the architecture:

image

Sadly, totally blank map screen:

I will keep on trying things, might see if I can get it using my actual phone instead as it will probably be quicker!

I’ve not had maps working for a while and assumed it was just me, and as not something I’ve worked on so sort of ignored it until now. Prompted by your issue, and the fact I let this bug slip through as I didn’t have map to check :sweat_smile: , I thought I better get it fixed.

As @KI2D suggested, I had to get an API key from Google for their Android Maps SDK, and add it to manifest file and that seems to have sorted it. Not sure if there is way to put this in environment file (env local)?

Thanks, I now have working maps! I haven’t tried putting it in .env for now, I’ll see if they can be done later.

It looks like either the logging to terminal was improved, or I should have been using npm start instead of npm run android all along, because I can now do stuff like console.log(spots) to figure out the data structures, which is very handy!

Alright, I’ve got to a point where everything’s working, so I have submitted a PR. More than happy to receive feedback on the design, up to and including outright rejection :slight_smile:

May I request to make this feature optional please.
Via the settings menu for example.

For SOTA activators it just does not add any value. I don’t care where on the planet the spot is.
Either I hear the station or not. That works perfectly fine with the list.
Just avoid to make PoLo so overloaded that less powerfull phones just can not deal with all the bells an whistles.

Thanks, Joe

1 Like

Is there anyway to zoom out more to be able to see more of the world map?

I don’t think the map will use any resources unless you actively toggle from the list to the map, so you shouldn’t have to worry about it from a performance perspective.

But point taken on utility, I will add a settings option for whether the list/map toggle should appear.

1 Like

Unfortunately I don’t think so. I have tried manually setting the minimum zoom level to 0 but it doesn’t allow any lower than this:

Seems to be a limitation of Google Maps with no obvious workaround. Not sure how it behaves on iOS as I can’t test that.