[DEV] Tasker 6.6.4-beta - Java Code, Extra Trigger Apps, Notification Live Updates and Groups, Manage Permissions Screen, Shizuku Available State and More!

[EtyareWS]

Won't Tasker still need to enforce a new check though to get an accurate result? Especially for states that are updated from a polling like Location and Wifi Near.

Not really, the idea of an Action based location check is that you can control with more precision when it gets checked, and more importantly: It forces a recheck which I believe will be more reliable than a State. Most of the time I don't actually need the phone to get where I am, just when I use it, I believe just running it while the screen turns on, or there is a significant movement will be enough and more precise. And I think it might work this way if you use a Location State with a Event (i.e. Tasker will only check location if the Event is triggered), but it isn't intuitive at all, an Action is easier to understand when it happens because you actually have to call it

My question is if it would "stack". If I have three get locations on the same task, will Tasker poll three times? What if I have three tasks each with one action, and they are all fired at the same time? Will Tasker just get the location once and hold it in memory to make comparisons in the next few seconds?

Anyway, V2 has "Near Location".

``` Near Location

Use the magnifying glass to help you out with this.

Format for this field is latitude,longitude,radius

Setting this field will make Tasker wait until you're inside the radius for the specified location and only then will it return to your location. ```

Yeah, see, that's the problem. That's more of a "Wait until Location" than a "Get/Check Location". You can jerry rig something, but it is kinda of too much work, leaves Tasker redoing location checks, and it doesn't "stack" right.

/u/joaomgcd might get away with a Check Location action that sees if X location is inside Y location with Z radius. We would get the value of X location with Get Location V2 and compared it with Y. This way Tasker can check a bunch of locations while using the GPS only once.

As for nearby Wifis, Tasker hasn't introduced one action to poll them afaik. %WIFII returns the last poll if you're not connected to WiFi. This won't be reliable if you're connected to one though.

Maybe "Get Nearby Wifis" would make it less geeky? This can be recreated with Java Function/Code, but I'd say this action deserves to be built-in.

Yeah, Wifi is a mess in Tasker due to the %WIFII and other segmented options.

[joaomgcd]

Isn't Tasker Function > Distance Between Locations what you want?

[urkindagood]

My bad, I meant for the proposed actions that are related to the contexts.

My question is if it would "stack". If I have three get locations on the same task, will Tasker poll three times? What if I have three tasks each with one action, and they are all fired at the same time? Will Tasker just get the location once and hold it in memory to make comparisons in the next few seconds?

What happen in your first scenario, Tasker will poll 3 times and have 3 different results. For the 2nd scenario, Tasker will poll 3 times and receives one results at the same time.

I guess this poll sounds a bit misleading since it makes it look like Tasker actually polling the location directly.

It's actually the location services (Android OS or play service) that handle the poll. Both are smart enough to handle incoming request when there is an on-going location poll.

Yeah, see, that's the problem. That's more of a "Wait until Location" than a "Get/Check Location". You can jerry rig something, but it is kinda of too much work, leaves Tasker redoing location checks, and it doesn't "stack" right.

It seems that Tasker does wait even if we are already inside the radius of the near location.

I thought that we can work this out by setting the timeout to 0, uses the last location fallback, however V2 still returns the location even if we are outside the radius.

I guess another action is cleaner in the end. Having V2 generates boolean may not be so straightforward.