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?
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:
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
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.
Related
I'm working on an app using Firebase and Geofire. On running the Geo query at the current location, let's say I receive 10 keys in the OnKeyEntered override method. Each of these keys is essentially a user node in Firebase. I need to listen to each of the user in the query area for any data change so that I can show updates on the map in realtime.
Currently, I'm adding a ValueEventListener for every key entered but I'm not sure if starting so many listeners at the same time is good idea. The users in the query area can potentially be more than 50. That means I could have 50 open listeners!
Is there a better way to go about it? I was trying to figure out a firebase query to filter on only the geo query keys but was unsuccessful.
Any help would be great!
Listeners are not computationally expensive, unless you have one that's going to be triggered very frequently because the data it's listening to is changing often.
Don't fall into the trap of optimizing your code before you actually observe a need to optimize it. When you see that performance is poor, that's the time to make optimizations. If you need a bunch of listeners to get your work done, go ahead and do that. Just know what your practical upper bound it, and be sure to test that upper bound for problems.
I wrote an app to show the next stops of busses and trams at a given station in my city.
The data i am displaying is fetched from an online XML API and contains the absolute time of departures. Currently i am displaying this data as is (e.g. "11:53").
However some users wish to see the time in a relative format (e.g. "in 5 min").
Now the problem: Quite a few users i know have a constant offset in their system time. Sometimes even deliberately to avoid being late all the time. Most of the time they know this offset and consider it unconsciously when seeing an absolute time.
When i display the departure time relative to the system time however i doubt that users will consider their offset.
Is there a standard way to get the cell-network time for example? Should i just ignore the issue maybe?
When your app started, you can fetch the current time from some online service and compute this offset.
I am in the process of planning an app that includes a feature that requires it to record and store the exact route a user takes while driving. Is there any location api that supports this out of the box? Or supports detecting a turn? I was initially hoping for an event triggered by the user turning onto a different road, but so far, no such luck.
I think you may try this way:
1 Request for GPS location update every 30s ,you can do this with Timer and TimerTask ,and LocationManager;
2 You can get the road name through Google Map API with the GPS location you get;
3 So you will get to know whether the user is turning onto a different road every 30 seconds.
I believe I have found a solution that makes use of the other answer here. I will post it as a separate answer though as it adds more to the other answer and is a full solution. As Ai Hao said, I could have my app request an updated location every 30 seconds to determine whether the user is on a new road, and then place a waypoint signalling the turn. However, this method is flawed if the mapping algorithm used (and I do not have the expertise to write my own) detects multiple possible routes. My solution to this issue is to store all location responses until a turn is made. This means that when a turn is detected, the oldest location data will be the last turn, while the newest will correspond to the turn being made. The app will request alternate routes, and if any are found, will calculate a route between the second oldest and second most recent coordinates, until no alternate routes are found. This should result in the exact route that the user took.
I'm making an application where users can save GPS data from phone to server when they travel their everyday routes. For example they are heading from home to work. GPS data is stored in a database.
Now, user wants to know maybe there's more people who travels this route too. I want to compare different users routes and give to user for example 3-5 best matches from other users routes.
Important is compare the whole trip, because users can join their routes and go work together from starting at some point not just from beginning and end. Also I think important is the destination point from the users view, who is searching other users routes. Other user route must be near by the searchers route end.
There are two factors - time and location. One user drives with a car and another walks and takes a bus for example. The one who walks starts his trip earlier, another later, because he travels this route faster. In one point at certain time their routes are matching.
How can be routes compared? Is there algorithm(s) for that? Do I need to compare every point in a route?
Essentially you are talking about a combination of routing algorithms and traveling-sales-man
The most common routing algorithm was invented by Dijkstra some 50 years ago, and calculate the best way of getting from point a to point b in a directed network -- in routing applications that means that each road is represented as a edge in the network, and where each edge is associated with a "cost" i.e. the time it take to travel down the road, or the average speed, or in your case it would be the number of people traveling on that route.
The Traveling Sales Man is a slightly different but also related, trying to optimize for the number of nodes visited -- in your case it is probably solving the opposite as it is trying to maximize the number of cities (edge-intersection nodes) while minimizing the cost of traveling to all the nodes -- worth understanding if you want to solve this problem
See GIS - it's a (HUGE) field of study - very interesting but very intense
I think what you would have to do is to convert the GPS co-ordinates that you get from the phone, into routes. Have a look at this Open Route Service which is part of the Open Street Map project.
Once you have each person's latitude and longitude converted to a common set of routes, then it will be easier comparing their paths to see if they have something in common. You could also do things like search for alternate routes. Perhaps one person by traveling a couple of extra mile/km can travel together with another group of 4-5 people going in basically the same direction. Things like that.
I have a list of coordinates in the database identified as POI. For a city could be >100 records.
I would like to get notified when the phone gets in 150 meters range of one of the location. The location coordinates too has an error/radius, usually 10 to 100meters. Since I don't find it good to add each location(could be hundreds) for a trigger, how can I optimize the wake-up code?
Also do I have options to remove a previously setup notification from the queue?
You could store your POIs in some sort of intelligent Hash-Table using the coordinates to compute a unique hash. Each time a location update arrives you make a lookup in your hash-table to see if there are POIs near the current location. This lookup should only take O(1), since it is a hash-lookup.
The desired range should be taken into account when computing the hashes and storing the POIs.
Just an idea!
Kind regards,
mefiX
There's an app named Locale, that can toggle various events based on your GPS location OR available Wifi network OR cell-station id, etc
It also has a plugins interface. It could be useful for you to examine that app and, maybe, write a plugin for it.
This problem reminds me of graphics in video games. There's no need to load the points that are well outside your range of movement. I'd break down the map into a grid, set triggers for the 8 adjecent grid blocks and then for each of the POI within the current grid block. When a new grid block is reached the triggers are updated. It'd probably be smart to overlap the grid blocks considering the range of error.