Open israel-lugo opened 7 years ago
stpr-dev
commented
7 years ago @israel-lugo I like the idea of setting poll time. I remember reading somewhere that there are limits as to the values you can specify.
Also, what do you think of this?
As I have said, I have no idea which is a better solution. Maybe a combination of your idea and this will be better?
redfish64
commented
7 years ago Isreal-lugo, please go ahead. I'll pretty much open to new features as long as they don't make the core functionality too complicated. I'll simply add it under the new advanced category in the settings.
Collectorgeneral, I'll have to look into this more. I'm pretty convinced just checking the phones accelerometer and orientation sensors will be most helpful, but maybe this will work, too.
On 24 Sep 2016 20:51, "collectorgeneral" notifications@github.com wrote:
@israel-lugo https://github.com/israel-lugo I like the idea of setting poll time. I remember reading somewhere that there are limits as to the values you can specify.
Also, what do you think of this https://github.com/redfish64/TinyTravelTracker/issues/49#issuecomment-249363133
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/redfish64/TinyTravelTracker/issues/52#issuecomment-249363303, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1W0nAFZ_IPsbgSRefsWZaxnQRskt4Tks5qtRzUgaJpZM4KFnzX .
stpr-dev
commented
7 years ago @redfish64
The reason, or two, I thought about this was:
The problem with point 2 is that you may have the phone moving, but not in a way that would require the tracking to go back to 'active' state. Take @israel-lugo 's example, say a person is in the basement of their office, and the GPS signal cannot be acquired. However, the person might have the phone in their pocket and might move around the office. I would assume that the sensors would get triggered by this constant moving, but there is no real need for the GPS to resume tracking.
Of course, if my understanding is wrong, then this whole thing goes out of the window. If your method is far easier to implement, then by all means you can do it and leave this for some other time (if viable that is).
This is something that came to me yesterday as I was testing the CPU wake for issue #50 (thanks for fixing that).
What do you think about adding a setting to let the person define a minimum and maximum poll time?
For example, user A might want to preserve his battery or CPU sleep time, and doesn't care about perfect granularity because he knows he won't move much today. He could set min poll time to 5 or 10 minutes, and max poll to something large like 30 minutes.
User B on the other hand is visiting the streets of a new city by car, and wants to map exactly where he passed. He doesn't care about battery because the phone is plugged in. He could set minimum poll to 0 and max poll to 2 or 5 minutes.
User C works near a datacenter below ground level, and doesn't have GPS reception for long periods of time. He would like to avoid waking the phone every 2 minutes to check for signal. He could set TTT on pause (issue #49), but he's afraid he'll forget to unease when he goes to lunch. He could set min poll to a higher value like 10 minutes during the work week, knowing he will sacrifice a bit of GPS accuracy.
I realize this can mostly be achieved by time percentage setting, especially user B (just set to a very high %). However, for users A or C, a low percentage doesn't necessarily mean high intervals. I haven't looked at the algorithm properly, but if it works like I imagine, if the phone takes 2s to acquire location, even a 5% setting could mean waking every 40s to take a new reading.
This would be a complement to the existing % setting, working like a hard limit. Basically, the sleep time would be a function of
max(minPoll, nextSignificantEvent).I haven't programmed much in Android specifically, but I could take a shot at implementing this. I can send you a pull request if you think it's a good idea.