ellenhp / aprs.tools Goto Github PK

This is a big nice to have, almost mandatory for 1.0

Context sensitive parsing is available in autumn so this should be possible at the very least.

aprs.fi is the biggest offender for this, it's almost impossible to view several stations with the same set of coordinates. APRSDirect does seperate the group out better though.

Hopefully this can be part of 1.0, but parsing and better visuals of weather station data, in the log history would be just great.

Content descriptions for symbols
Verbalize information about track
Reverse geocode locations?

Having the backend means clients who scroll around have the world's APRS data at their disposal, which has caused at least one OOM crash on my pixel 2. Replace the packetplotter/packettrackhistory combo with an LRU cache of grid squares. New requests in warm grid squares should only retrieve aprs data since the last request was made, to save bandwidth. This cache should be able to interact with the system and respond appropriately to memory pressure.

Additionally, current behavior of allowing requests for huge geographical areas but returning only the N most recent packets should either be preserved or improved. Graceful degradation (no heatmaps!) is ideal.

There should also be a separate mechanism for storing stations heard on RF. I'd hate for the LRU cache to purge stations heard on RF, especially if the device is offline and there's no way for the user to get that data back.

Right now I don't think changes to SharedPreferences are getting plumbed through to the service, so the AprsIsClient isn't getting recreated as it should

I want to be able to reboot my proxmox containers without breaking prod. I think I want to do this with google cloud build and docker? Idk, open question.

Continuation of #8

map empty not show anything

This is highly concerning because it wasn't caught by the linter or a robolectric test. Possibly report it to robolectric?

It was removed during the UI rewrite

Things have changed a lot lately and code quality has suffered. Add some tests, get robolectric stuff working and add a linter config. This should also include refactoring to make heavier use of dagger and autofactory.

Mandatory for 1.0

This is an OOM. Investigate what's causing it and how to cut down on memory usage. Removing markers of cached cells outside the viewport would help maybe? Also look at lazily loading the entire packet, and sending only the latlng and symbol from the server.

It should be possible to view stations in a list sorted by distance instead of on a map.

I want warning free code.

It would be nice to have the option to download map tiles with open street maps.

This leads to timeouts.

Howdy,

This is an interesting project. I wonder if you have plans to continue development.
I've updated "com.google.android.geo.API_KEY" with my own API key to get the map working.
Then I built and launched on an emulated pixel 3xl.

Looks like api.aprs.tools is down? Perhaps we could use the aprs.fi api https://aprs.fi/page/api ?

2020-06-11 23:46:17.840 9423-9643/me.ellenhp.aprstools E/Volley: [672] BasicNetwork.performRequest: Unexpected response code 404 for https://api.aprs.tools/within/86940000+?type=posit

This is probably what's causing markers to stick around on the map after they should have been removed.

I'm setting all the timeouts correctly but it still just stops working occasionally. Log output looks like this:

[snipped, because it goes back forever]
Sending packets to server.
Response: 200             
Sending packets to server.
Response: 200             
Sending packets to server.
Response: 200             
Sending packets to server.
Response: 200             

Then nothing. Adding a software "watchdog timer" would fix this. I plan on having at least two of these jobs going in parallel so the dropped packets while the watchdog restarts the service don't concern me.

Don't forget the unit tests