Android Question FusedLocationProvider question

Relying on making permissions optional is problematic as only Android 6+ supports runtime permissions.

If you want to save power then set the priority to low power: https://www.b4x.com/android/help/fusedlocationprovider.html#priority

Thanks very much for your reply. I didn't realize this would do the job, thinking it was not a rigorous setting, and could be overridden by the OS if it was deemed appropriate.

Also thanks for the tip about permissions - I will leave it as it is.

Thanks,

Chris C-B

Now I have got my system back over the catastrophe, I'm back to B4A, and following up on the solution provided by Erel, and I find another stumbling block.

Using Vader Consulting's excellent 'B4A Object Browser', I see there a FusedLocationProvider.Priority item, which does not appear when used in an application. In fact, the two sets of available options are remarkably different.

So, how do I implement FusedLocationProvider.Priority.PRIORITY_HIGH_ACCURACY ?

Can anyone help, please?

Chris C-B

SeaBee said:

So, how do I implement FusedLocationProvider.Priority.PRIORITY_HIGH_ACCURACY ?

Click to expand...

Check the documentation!
https://www.b4x.com/android/help/fusedlocationprovider.html#locationrequest_setpriority

Priority

Events:
None
Members:

PRIORITY_BALANCED_POWER_ACCURACY As Int

PRIORITY_HIGH_ACCURACY As Int

PRIORITY_LOW_POWER As Int

PRIORITY_NO_POWER As Int

Members description:

PRIORITY_BALANCED_POWER_ACCURACY As Int
Used with SetPriority(Int) to request "block" level accuracy.

PRIORITY_HIGH_ACCURACY As Int
Used with SetPriority(Int) to request the most accurate locations available.

PRIORITY_LOW_POWER As Int
Used with SetPriority(Int) to request "city" level accuracy.

PRIORITY_NO_POWER As Int
Used with SetPriority(Int) to request the best accuracy possible with zero additional power consumption.

Thanks very much for the explanation. What I didn't realize is that I need to declare a LocationRequest first, and set the priority to this. Now I have reread all available stuff on the FusedLocationProvider and understand it a lot better, I shall continue to get the LastLocation (working fine) and check it's time and accuracy. If these meet the requirements, then just proceed, otherwise offer LocationServices or GPS, and let the user decide. Once a satisfactory result is obtained, turn it all off!

Again, thanks for the rapid support.

Chris C-B

Murphy's law strikes again! Having got FusedLocationProvider working precisely as I want, and in a fairly complex manner, I now think I am going to have to dump it, and go with direct GPS and esLocation2.

I got around to reading the Google Play API licence agreement carefully, and find that, for the purposes of my app, I cannot save the data, not even for the 30 day waiver, as the FusedLocationProvider is part of Google Play API. This is a big problem, as the app facilitates planning future events, and I need to save this location's position. Geocoding is a much harder nut to crack. If the user puts in the relevant place name, Google Play returns a list of possible locations, and on selection, the user gets the latitude and longitude of the location, which I then need to save, but cannot save under the licence agreement.

My current possible workaround is desperately complex, and is based on the fact that although the raw data cannot be saved, the product thereof can be saved. I am an amateur sailor, and years ago, before even Transit satnav was available, I wrote a permanent almanac in HP basic for the HP95C, giving a sextant user the ability to navigate without the complexity of using Admiralty tables and written calculation sheets. My permanent almanac provided full data on the Sun, Moon, the six navigational planets, and the 63 navigational stars (but not allowing for the proper motion of the stars, as this level of accuracy was not required).

I have already started looking at a B4A transfer of this for just the Sun - the easiest to compute. My planned methodology here is to calculate the precise altitude and azimuth (just N or S) of the sun at transit, at the location and at 0 N and 0 W, on the date the location was researched on Google. I will store this data only (place name, date of search, alt. and az. Sun, alt. and az. 0,0). Then, subsequently, when the user wants to review data for that location, the latitude and longitude may be easily reconstituted and saved, being 'the product thereof' of the Google API.

What a palaver, just to save two numbers!