API Adds/Delete and Amendments (Scopes)...

  • 1
  • Question
  • Updated 3 years ago
  • Answered
Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members.

When I first implemented the API, there were events (using default scopes defined for auth) that pushed a type param of 'region:changed'. I notice that I no longer receive these. I also noticed when I attempted to add additional scopes, I'm getting 'Invalid Scope'. Specifically 'current_location' as I was hoping that somehow re-invoked the region:changed.

Has something changed ? Is there somewhere that I can reference release notes (developers newsletter perhaps) ? How does one keep up with the API releases ?

Thanks in advance...
Photo of Cuda

Cuda

  • 350 Points 250 badge 2x thumb

Posted 3 years ago

  • 1
Photo of Adam Altman

Adam Altman, Alum

  • 3,712 Points 3k badge 2x thumb
Hi Cuda, 

Events
Region:changed is an event that was never fully baked or in the documentation. It was firing for a while, but we had it on the chopping block for some time to deprecate and looks like that's finally happened.  We would not depreciate any documented events or endpoints without notifying our developer list first. Since we're talking about it here, three undocumented events are being deprecated:  region:changed, parking:location:changed, vehicle:stopped.  These all fired inconsistently and never quite made it up to production-quality.  Apologies for the inconvenience.

Adding Scopes
Currently, an app's scopes are defined on our end.  If you'd like scopes changed, email developer@automatic.com.

Release Notes
Nothing yet. We'll start doing that soon. As mentioned, for any changes to the documented APIs we will email developers with registered apps.

--Adam
(Edited)
Photo of Cuda

Cuda

  • 350 Points 250 badge 2x thumb
Thanks for the quick reply Adam. You're correct, the 'region:changed' event was isolated upon analyzing log data on my web service. I was actually utilizing it to determine probability (distance between current location and nearest fence) that I was advancing towards a specific location (e.g. home). Hmm, will have to re-think that one.

I can't say I remember seeing parking:location:changed, rather I do see parking:location - hope I'm not confusing the two. Also can't say I've seen vehicle stopped.

Again thanks for the information and once again I have to say, this is one of the reasons I love this product is the top-notch support... 
Photo of Adam Altman

Adam Altman, Alum

  • 3,712 Points 3k badge 2x thumb
I believe you're right, it's called parking:location not ...:changed.


We ♥ our users, glad you feel it. :)
Photo of Cuda

Cuda

  • 350 Points 250 badge 2x thumb
Adam,

So would you recommend utilizing the 'ignition:off' in lieu of the parking:location (although I still see this event occurring) ? In a previous conversation we had, you indicated that ignition:off fired quickly with less accuracy (65m) as opposed to parking:location which was somewhere in the area 2m.

I'm really just looking for the ideal event which provides the best location accuracy without the expense of time (<30 seconds). I can always adjust the accuracy of the fence but driving up to a dark house may get me deprecated (courtesy of my wife).

Thanks
Photo of Adam Altman

Adam Altman, Alum

  • 3,712 Points 3k badge 2x thumb
So the tradeoff will always exist of location accuracy vs time...  
- the most timely event is going to be 'ignition off'
- the most accurate event going forward is going to be 'trip:finished' which is a superset of 'parking:location'

For this application, I'd go with ignition:off.  while parking:location is still firing to you, you could listen for either.
Photo of Cuda

Cuda

  • 350 Points 250 badge 2x thumb
Perfect, thanks Adam. I updated the code last night to evaluate ignition:off ..

This conversation is no longer open for comments or replies.