Ramp up / ramp down

[lmeier]

No description provided.

[tjulien]

Is continuous not good enough? If not, wondering if we reuse it but change 1-2 of the options via code instead of creating a new preset. If we did want to create a new preset we would probably want to name it presetXxx and also think of a more descriptive name then "ramped up".

[lmeier]

think essentially we want continuous but with more frequent updates / faster sync interval.

IMO the intended tracking options are what works for microdetection / DD use case

[tjulien]

Makes sense. RampingOption and StateChange seem to add alot of complexity that will be hard to get right I think. Two things I'm thinking about:

1. Would it help if Radar.startTripWithOptions() accepted a second trackingOptions param that if set kicks in when within the radius? And we would expand the "previous tracking options" concept from 1 to a list, maybe.
2. Would it help if a single bundle of tracking options had a few more fields representing the ramped up needs? It might only be the update intervals and sync intervals. It would be less generic bc you couldn't change anything else when ramping, but the code to handle those values would be alot simpler I suspect.

[lmeier]

I've taken a stab at number 2, cutting a waypoint build now: e68d2f5

[tjulien]

tactical thing, I think the force pushes are making it hard to see what changed since I looked at this last. Everything looks like it was pushed 3 days ago. I'll fiddle around in github, see if I can find a way. I guess lacking that, what changed to implement #2?

But more generally, the idea behind my comment was to get rid of RampingOption and StateChange because I think they add too much complexity. I'll spend the day tomorrow trying to understand how those work and try to form a more detailed opinion.

[lmeier]

Oh yikes, that makes sense. Didn't mean to be force pushing. Will watch out for that.

What I did was remove the notion of there being any difference between "ramped up" tracking options and "normal / ramped down" tracking options. Instead, the tracking options are fixed — eliminating some of the state complexity you pointed out, not having to worry about keeping track of the tracking options over time.

Still, we need to keep track of past ramped state so that we can timeout of being ramped up. This is how we address the problem of being persistently (or for a long time) close to a ramp up geofence.

We might also choose to ramp down when stopped: true (GK suggested this today).

[lmeier]

Look forward to hearing the more detailed opinion that you form

[tjulien]

Got it. AreRampingOption and StateChange primarily needed to be able to timeout? Or are they important for other reasons? Ramping down or shutting down when stopped is an interesting idea.

How long is the timeout?

[lmeier]

Timeout is 20min in 1 hour OR 120 minutes in 12 hours

[lmeier]

Yes, correct that StateChange is for the timeout.

The RampingOption, perhaps deserving of a more fitting name, is just the enum passed to updateTracking to indicate whether updateTracking should ramp up, ramp down, or no-op.

[lmeier]

lowPowerLocationManager changes a la #303

[lmeier]

Closing as we're opting to do this server side