0

In my app I have a Service which receives location updates and stores them to a database. I also have a Fragment which displays a MapView and a PolyLine of all recorded waypoints from the database.

During recording, the Service notifies the Fragment about new waypoints so the Fragment can update the PolyLine. The problem is that when the user navigates away from the app the app the Service keeps recording waypoints to the database, but now the Fragment doesn't get updated since the Fragment is paused. So in onResume I create a new PolyLine, read all the waypoints in the database and add them to the database.

This is all working fine, but it doesn't really feel like it's optimal from a performance perspective to create a new PolyLine and re-add all the waypoints (there could be thousands!). I guess I could just re-add any new waypoints that are not already in the PolyLine, but I wanted to see if anyone here has an alternate solution? Is there any way to keep the Fragment "alive" and updating its PolyLine even when the app is in the background (as long as the service is running)? Or is there a better way to do this?

Magnus
  • 17,157
  • 19
  • 104
  • 189

1 Answers1

2

Recreating the polyline is probably inevitable, but here are some things you should think about doing if performance becomes an issue:

Put a time limit. When recreating the polyline, only fetch the data in the last hour or day (test and you'll be able to determine the best value here), and offer an option to extend that period. This will make it more understood by the user that the data needs some time to load, and that the app will use more resources.

Aggregate the data while saving them. This should reduce the disk space used to save the points in the database (very important for low end devices) and improve on the performance when rebuilding the activity.. These are some tips for what you can do to reduce the number:

  1. Check 2 points behind and see if they are a straight line. If so, delete the middle one. That should remove a lot of data recorded when the user is in a car or walking a long distance
  2. Check if the last set of points (5 or more) are in the same area, that way you can get rid of a lot of data. So if a user is just waling in his home or workplace, you can just save one point for that without loosing too much data, which shouldn't really be a problem in most (99%) of the applications.
Ali Al Amine
  • 161
  • 2
  • 4
  • Thanks, that's some good advice! I'm already doing #2 when I register my location update listener (default is 10m minimum distance). The straight-line-detection is a nice one, not sure how to implement it though - it would need some sort of tolerance... – Magnus Aug 09 '16 at 14:37
  • @BadCash There are a few ways I can think of to achieve that. The best one I can think of is to calculate the distance of the middle point to the line created by the two surrounding points and check if it's smaller than a certain value determined by the error margin that you need. – Ali Al Amine Aug 09 '16 at 15:34
  • Thanks again :) Yeah that would be one way to go. I had another thought - what if I compare the length of the path from A-m-B (m=middle point) with the length of the straight path A-B, and if the first one is within a certain tolerance (longer) than the straight path, it can be considered straight? – Magnus Aug 09 '16 at 16:06
  • @BadCash Yeah that's a really nice idea. And btw something to be wary of is a slow change in the angle over a long distance, such as a slow turn on a highway or something(that also applies to my solution above). If that happens the algorithms will aggregate the data by thinking that the error is acceptable while it's not because of an avalanche effect caused by deleting a previous point. So I would also add the distance between points A and B as a factor to decide on the error tolerance (long distance between points should have a lower chance of being aggregated) – Ali Al Amine Aug 09 '16 at 16:18