What will happen (with the RTT2 app logic) if Server update interval is reached but there are NO new (buffered) locations recorded since last server sync?
You just found one reason why synchronization time might make sense in some cases
. You will see that the timestamp won't change after one minute because no connection will be established. By the way, there might be some other reasons why the tracker synchonizes from time to time even if there is no location update. The tracker polls for new messages, remote commands, and so on from time to time. Apart from that it sends battery information from time to time.
Practically, users should not care about the last server connection timestamp at all.
I agree with you. The user does not need to care about this timestamp. On the other hand I think it does not hurt if the timestamp is displayed anyway (if there is any negative effect please tell me). Users can just drag and drop the field to the last position if they are not interested in that value. Actually there were two reasons why I have added this field:
1.) Provide some kind of backward compability because RT1 also displays the send time instead of the recording time
2.) Increase transparancy, i.e. show to the user what the tracker is doing. At least for me as developer it makes it easier to test if the tracker works as expected. And maybe it will also be helpful to some users (most probably techies
) who are playing around with update intervals to optimize data usage.
AND number of locations kept in the Buffer (not yet posted).
This is exactly what the field "buffer size" displays: The locations not yet posted
a) GPS update interval = xx sec; which means that locations are recorded at a configured interval only, and not on every single second
Generally this is true, but there is one exception. If the map window is in foreground the tracker assumes that users want to see their up-to-date location. So the location is updated every second on the local map (but not sent to the server). As soon as the map is in background the tracker switches back to the configured update interval.
And it is important to send all buffered locations (not only the latest one) as this directly impacts track accuracy.
I agree. It's important (especially for Track Loading users who want to see their tracks in detail).
Also, I don't see a logic with separating GPS and network sampling as two independent async threads/processes.
IMHO, if GPS set ON (i.e. for better accuracy and worse battery life), and retrieved successfully (i.e. within accurancy tolerance and reading timeout), there is no need to even ask for network location at all.
I agree and I even thought about changing that. The problem is that for historical reasons internal design is not optimal for that change. When I started this project I totally focused on GPS locations (the tracker even did not support network locations). As more and more users started to ask for network locations I added a separated (very simple) module to track network location. But as the GPS module is very complex (supports many options and handles GPS-specific problems) it is not that easy to merge these modules. So all in all I would say, merging is possible but so far I was too lazy
and this issue has not high priority because in my opinion querying does not really hurt battery. It will increase data usage a bit but not that much (especially if you raise the network update interval).