On Mon, Feb 29, 2016 at 9:46 PM, Alan Pope <alan.p...@canonical.com> wrote: > Hi Thomas, > > On 29 February 2016 at 15:35, Thomas Voß <thomas.v...@canonical.com> wrote: >> On Mon, Feb 29, 2016 at 12:38 PM, Alan Bell <alanb...@ubuntu.com> wrote: >>> it isn't really about that, it is about providing less broken location data >>> to applications that ask for it. The current situation is that if an >>> application requests location data it gets given random coordinates of >>> somewhere you may have been to in the last week or so. >> >> Hmmm, I'm surprised by that statement. The service hands out the last >> known good location, together with a timestamp >> and the accuracy aged out. If applications fail to handle the >> respective data correctly, it is not the service at fault here. >> > > I spent a week in Germany last week. At lunch time we wandered outside > from the exhibition centre and opened HERE maps to find a nearby kebab > shop (don't ask). Ogra pulled out his MX4 running rc-proposed and used > HERE to find a local shop and navigate to it. Our destination seemed a > ludicrous distance away from our current location, until we noticed > the current location on the map was actually the hotel we left some 5 > hours previously. Cue a few moments of stabbing to refresh the app to > make it realise we've moved (quite a bit as it happened). >
Sure, this is certainly a bug although it is not necessarily the service at fault here. > While this may be "Working As Designed", it's not "Working in a > meaningfully useful way". Having a location which is "aged" by over > half a working day is pretty useless on a mobile device. Other > platforms don't do this (in my experience), neither should we, battery > life be dammed, frankly. I want the map to show me where I am now, not > where I ate breakfast sometime in the past. > See before, but really: *if* there is a timestamp on an update, an app should use it. In addition, if there is an accuracy available on an estimate, the app should decide whether it is good enough or not. Deciding "not good enough" is perfectly valid, it depends on the app ultimately. We hand out the last known good position as it was a common request to provide an initial hint to applications. Even *if* the data is old and not accurate, an app should be able to handle that situation gracefully. Satellite- and network-based positioning is only able to give estimates, interpreting accuracy and age of the estimates has to be done by the app. We simply cannot handle it in a reasonable way centrally in the service. >>> Then it thinks about >>> refreshing the location and refining it over the next few minutes or so if >>> the application is one that asks where you are again and again. If it could >>> take a peek at the satellites every so often then it would enable several >>> additional classes of application and would be less broken for things that >>> only ask once. >>> >> >> That's incorrect. The service keeps on delivering updates to >> applications that have requested continuous location updates. > > Then there is a bug in the platform. The browser (in which HERE runs) > is a default app and the location service is also pre-installed. There > is an issue here which clearly need nailing as I'm certain we're not > the only 3 people in the world to experience this. > With all due respect, this is not a bug in the platform. Are you, 2 other people, and others experiencing an issue? Certainly. Is the only way to fixing it to periodically wake up the phone? I don't think so as other mobile platforms get the job done without doing that. Did we make sure that no other layer in the stack is keeping around stale cached updates for longer than it should? I would be surprised, to be honest. So rather than just saying: It has to be fixed in the platform we should instead carefully investigate where things can go wrong. I'm happy to remove the heuristic handing out last known good estimates if we find that most apps are unable to handle it correctly/gracefully. Cheers, Thomas > Cheers, > -- > Alan Pope > Community Manager > > Canonical - Ubuntu Engineering and Services > +44 (0) 7973 620 164 > alan.p...@canonical.com > http://ubuntu.com/ > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : ubuntu-phone@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
