ubuntu-phone team mailing list archive

[Alan Bell <alanbell@xxxxxxxxxx>]

On 29/02/16 21:56, Thomas Voß wrote:
> On Mon, Feb 29, 2016 at 10:48 PM, Alan Bell <alanbell@xxxxxxxxxx> wrote:
> > On 29/02/16 21:29, Thomas Voß wrote:
> > > 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, if the app was coded perfectly, and the last known good position was 5
> > hours old and miles away, it would give the app the last known position, and
> > the app would then decide it is too old, subscribe for updates and wait for
> > a fix. That is the absolute best an app or web page can do if the platform
> > is working as designed, make the human wait, or use a bad location. The app
> > can't be written better because getting the first fix needs to be pushed
> > back in time to shortly before the app starts.
> Yes, by design we try not to guess what the user will do next ;) As
> mentioned in my other mail:
> I'm happy to work together with you on coming up with a heuristic that
> works for the majority of the users.
OK, so lets go with "start getting a fix when the phone is unlocked" 
would that be a change to the location service, or something in whatever 
the welcome screen is that calls some method in location services? I 
think that location services does dbus, so might have a "wake up and do 
your job" method, and I am pretty sure the welcome screen isn't lightdm, 
and is probably QML based but I can't see any promisingly named projects 
owned by the Phablet team.

Alan.