Working with GPS location also

[Siltaar]

Checklist added by @smichel17 for easy reference. @Siltaar's comment is below the line.

• When location services get turned on and off, display a toast/snackbar letting the user know that we're updating, or that they need to enable location services.
  • Also display this toast when we start searching for location updates
• Remove LocationPreference, put the location into the useLocationPreference summary
  • Trim the length/precision to something reasonable (currently 3 digits after decimal)
  • Change the summary text based on whether location is enabled
• Start the LocationUpdateService any time the TimeToggleFragment is opened
• Do a better job choosing between network and gps location
  • Specifically, right now we use gps only if a device has no provider for network location. That is, if a device is network location capable, but is in GPS only mode, we will prompt the user to enable location services when we should just use the GPS, which is active already.
• Battery optimization: If the last known location is less than an hour old, use that instead of updating.
• Make background updates give up more easily.

Not going to do this right now:

• Give the user an indication of when the location was last updated
  • In a snackbar, with an action to update

---

Hi,

I'm using current f-droid version of RedMoon, and even in Saving Mode or Approximate Position mode I can't get a location from RedMoon interface.

I'm using a Fairphone with the "Open Source" Android edition (meaning : graphical widget to root the phone, and no Google services).

So I don't have any working approximate location mechanism, but my GPS is working very well (with OSMand~ for instance).

Would it be possible to be able to get the current position for automatic Sunrise / Sunset time from precise position got from the GPS ?

[raatmarien]

This would indeed be possible, but would require Red Moon to ask for permission to the orecise location of the user.

In the mean time, I would recommend you install UnifiedNlp and an location backend (Just search F-Droid for "location backend" for all the options. This will not only make the current Red Moon able to find your position, but it will also greatly improve the time it takes your phone to find your location when you need it 😄.

[smichel17]

See also #102

[Siltaar]

Thanks raatmarien for your answer. I know UnifiedNlp and did not find reliable backends (my cell-towers are not in databases, and app to add them seem dead ; I'm living far from other WiFi than mine and don't want to register mine in such databases, and it's not only because I'm leaving in a boat that moves…). I consider WiFi beacon mass recording as an issue and don't want to encourage it by using such databases. I will continue to use my bare GPS location, with 30-60s location fix, acceptable in my usecases (it even do not eat up my small Data plan, french provider : Free 2€/month 50MO)

Thanks smichel17 for what look like a technical solution for the next version.

"Who can the most, also can the least", I hope that Android allows apps to get an approximate location from the precise one, or can't figure out why it's not the case :-)

[smichel17]

I put a debug build up at http://smichel.me/files/red-moon/app-debug.apk. @Siltaar Could you try it out and see if it works for you? You should be able to install it alongside the f-droid/play store version.

[smichel17]

-checklist moved to top comment-

[Siltaar]

Oh, I was updating my f-droid list of application since 9 days, not seeing the update coming… So sorry for the delay.

I tested it, it worked perfectly. (and by the way, the UI updates are great).

(I even did update my redshift config file with my exact location as I had it under the eye)

[smichel17]

@Siltaar I put my checklist in your top comment for easier reference. Although I didn't modify your words, I probably should have gotten your permission first. If you're not okay with it, I will put it back how it was.

[Siltaar]

@smichel17 You're welcome.

[smichel17]

@raatmarien @\anyone else: I'm trying to come up with a non-hideous solution to the following problem. I wrote it in mostly non-technical language so anybody can try to help me take a crack at it:

The location service sends the UI certain messages. The ones we care about are:

• When location services are disabled, so the UI can prompt the user to enable them
• When location services are enabled, so the UI can confirm that it's now searching for an updated location
• When the tries to start the service during the time it's running, we'll resend one of the above messages (in case the user missed it first time around)

After we register for location updates for the system, the system will notify us when location services get enabled or disabled. If location services are disabled at the time we register, we will get a notification (almost) immediately.

When the user tries to update the location, one or two things happen:

1. There is code (onCreate) that is executed once, the first time the user tries to update the location, but not again for subsequent requests
2. There is code (onStartCommand) that is executed once per update attempt.
3. If we registered for location updates in either of the past two steps, but location services are disabled, this is where we get the immediate notification mentioned above (after onStartCommand, even if we registered for updates in onCreate)

So, the problem is, if we send a message once per update attempt (in onStartCommand) and also when location services get enabled/disabled, we tell the UI that location services are disabled twice.

I have this solution:

• Register for updates in onCreate. Before we do so, check if location services are enabled. If they are disabled (ie, if we're doing to send duplicates), suppress the next message about them being disabled (ie, don't send one of the duplicates).
• Always send messages in onStartCommand

It works, but it's ugly. If possible, I'd really like to avoid relying on the current order of things in order to choose which commands to suppress (ie, a solution that won't cause bugs if someone changes the order of things later). But I can't think of anything that'll actually work.

[smichel17]

Found a good way: UI can send two messages: one to start the service and another to ask the service to start/stop sending updates. This doesn't work either, because our messages arrive before the one from the system about location being disabled.

My solution was to send a message on registration when location services are enabled, as well as the one the system sends when they're disabled on registration, and suppress the first status update instead.

[smichel17]

Fixed in 4790e80

[smichel17]

There are a couple tweaks/improvements that could be made, but they are not worth spending any more time on right now. They're minor enough that I'd be impressed if any user could identify them.