Location fetch should be a non-blocking operation as location availability can be very unstable and can crash the app regularly

[katajanmarja]

Describe the bug
I live in a country where GPS interference is apparently a regular occurrence and it's hard for me to tell how bad smartphone location information getting is in general. But many GPS-needing softwares will randomly struggle to get location even while standing outdoors. This part is not Seek-specific.

However, Seek's way of fetching location information seems to make it very vulnerable to malfunctioning due to location information not being readily available.

• Sometimes, when observing a species (taking the photo), it works fine. The location syscall sometimes just goes through, no issues.
• Often, when observing a species, the app will get stuck with a spinner for a long time, and then either crashes or tells me that the observation has no location, which I can fix when posting to iNaturalist by clicking on the Location button and pressing the 'center to current location' crosshairs icon repeatedly until the location syscall gives something for the app to work with (until then it shows me the map in what seems to be California).
• After I restart the app if it crashed, the observation is often present (if I re-observe the plant it asks me if I want to use the old photo), so as far as I can tell observation-saving itself went ok, but if I close the camera from the 'X' while the spinner is ongoing, it seems it won't save the observation (or cancels the save), which is super frustrating.

To Reproduce

It's likely overly hard to reproduce 'bad location reception' but you may have luck if you turn off wifi (as it helps location services in areas where wifi is readily available) so that you rely solely on GPS on a cloudy day, or bring a potted plant to the bottom floor of a two-floor train and make out with it with Seek there since they are pretty neat Faraday cages. (Trains are, not potted plants.)

Steps to reproduce the behavior:

1. Start identifying a plant by pressing the camera icon in Seek
2. Let it get to an ID and press the 'now take picture' button to take a picture
3. Observe a long spinner (something like 30 sec, i haven't counted, but excessively long), possibly leading to an application crash or complaint that your observation has no location during which there is an option to press 'X' on the camera shoot to regain GUI responsiveness but that will lose the observation.

Expected behavior

• Save the base observation first to not lose the picture and ID on an app crash, and preferably keep it if the user presses 'X' to escape the crazy spinner if there is now some default of cleanup.
• If you don't get location information for it in 1-2 seconds, there's a few options:
  a) use a cached location from a moment earlier for now; statistically users may try to identify multiple plants in the same region without moving a lot, and waiting 15-30 seconds for every picture is excessive. (You can also do location calls in the background while not observing but that uses up phone battery faster. However, once the camera is taken out, I think it's fair to pick up location during that time and once you have it, not update it a second time after taking the picture, since the user is most likely just running around the same plant or wandering around very close to it - at least IF they ever save the observations - and if they don't, it doesn't matter if the location data is outdated.)
  b) save the observation without a location and indicate to the user that you're trying to pick up location information in the background (don't crash though, location isn't worth it before trying to do an iNat posting since we have no map features in Seek)
  c) provide an update to the UI for the user that you're having trouble getting location information and allow the user to save the observation without location information for now so they can move on with their life.

Generally, by the time we get the 'spinner of doom' it will NOT find location during the timeout, so having a long timeout just causes bonus usability problems.

This location seeking issue repeats for the main GUI trying to show nearby animals btw, and I would really love it to just stick to and remember my last location rather than go back to "I have no idea where you are so I won't show you zilch and nada". (It won't remember I've manually told it to find me stuff in my town either.)

So in that sense I do prefer option (a) of caching location data until an update can be achieved and using that for everything until you get a better update a lot.

Screenshots
(I can add a spinner screenshot if that helps you, let me know.)

Smartphone (please complete the following information):

• Device: iPhone Pro 15
• iOS 17.5.1
• Version 2.16.1

Additional context

• I have location settings turned on, but wifi is generally unhelpful for me when doing bioblitzing so I get bad 'location reception' also in other GPS games.
• I have good cell signal in the area, no 'network lag' observations.
• I do at times observe a second or two of delay when importing pictures with iPhone to iNaturalist, but the 'long wait' is specific to Seek, coincides with location complaints, AND I have similar issues with other GPS-dependent softwares regularly complaining that they have trouble getting my location (using different language) so I figure this is the root cause for Seek getting stuck too.
• If I turn off location services completely, Seek observations go through at lightning speed and cause a popup for location information needs instead, no spinners seen. So having location off would make observing faster, but unlike with Android there is no speedy iOS button for turning off location services by default at least. And I do want to post them to iNat too and finding the location within Seek manually when the GUI is always starting from California is not practical.

PS. Oh my god I love this app thank you so much. I keep advertising it to everyone even though it's been super buggy for me so far because real-time ID is just so gosh darn valuable.