You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to be able to stop the location service based on a response from the service, something like { "stop_updates": true } or a status code.
After stopping updates, we can also discard saved coordinates, and remove the foreground service notification.
I would implement and send a PR, but I want your ideas on it.
Do you have an idea of how you would want this to look like?
I see 3 viable options:
Could search for a predefined json value
We can allow specifying a regex that tests whether we want to stop updates and match it against the whole response body
We can test for a response status code, like "406 Not Acceptable", or maybe define our own status code on 4xx if we want it to be considered an error, or on 2xx if we want it to be considered "okay, your coordinate has been accepted, but btw you don't need to send any more of these"
Personally I think status code is the easiest to implement on both client and server, and the most "RESTful".
I propose status code 202 Accepted, which by wikipedia means "The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.".
Or status code 285, just because it's an OK status combined with the 85 in mauron85. I could have chosen some random number over 226, but 85 was their in face as I was writing this issue.
The text was updated successfully, but these errors were encountered:
@mauron85
I want to be able to stop the location service based on a response from the service, something like
{ "stop_updates": true }
or a status code.After stopping updates, we can also discard saved coordinates, and remove the foreground service notification.
I would implement and send a PR, but I want your ideas on it.
Do you have an idea of how you would want this to look like?
I see 3 viable options:
Personally I think status code is the easiest to implement on both client and server, and the most "RESTful".
I propose status code 202 Accepted, which by wikipedia means "The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, and may be disallowed when processing occurs.".
Or status code 285, just because it's an OK status combined with the 85 in
mauron85
. I could have chosen some random number over 226, but 85 was their in face as I was writing this issue.The text was updated successfully, but these errors were encountered: