delayed conditions
Astrid supports Locale, so the obvious thing one might do is to trigger reminders when you, say, come home.
However, getting reminded the moment you walk in the door (or more likely, when you're near your home) isn't always useful. You might just be dropping off your bag.
So, a location condition that waits a configurable timespan, and then checks if it's still valid before firing off the actions would be handy. Some of the other conditions might also benefit (say, "if I'm *still* on the phone with mom after 30 minutes, then..."), while it would be rather useless for some (if it's still between 9 and 10 in ten minutes).
xen
shared this idea
This is a great idea and we’ve been looking at it for quite a while. I agree it could be quite useful when combined with Astrid integration. For example, a location-aware reminder would be really useful a few minutes after arrival, rather than right when walking in the door.
A key requirement would be that the delay should be very consistent and predictable. For example, if I ask for a reminder 30 minutes after I get home, it should always be exactly 30 minutes after I get home. Thanks to Locale 2.0’s instant location, we are now be able to meet this requirement.
I have a few open questions about this as we go forward with investigating how this might work:
- Should there be delayed conditions? Or should this be implemented as delayed settings? (The end result would be the same, but each requires a different mental model) - How short or how long of a delay would people want?9 comments
-
AdminCarter
(Admin, two forty four a.m.) commented
@carlos: I think this request might work better for your specific use case http://feedback.twofortyfouram.com/forums/5655-locale-feedback/suggestions/389767-don-t-turn-off-bluetooth-while-in-use
-
Carlos Lopez
commented
I have a condition that turns on bluetooth if I'm not at home. As soon as I arrive near home by car, the bluetooth turns off, I would like a 5-10 minutes delay, to prevent losing calls.
-
Beau
commented
I was using plugins that tied the Airplane Mode control to a timer, and triggered when I would lose cell service. I frequently go into areas that don't have service at work and having my DInc out of service would rapidly deplete the battery. Unfortunately I'm having issues with it right now, and the developer of the timer is unresponsive. I can't think of any other way to control my Airplane mode using the cell coverage as a trigger without causing a lock that I would manually have to undo. This would be a fantastic addition to the core app, nobody else has anything that comes close.
I vote that you could set a timer to delay the trigger if you set it as a setting, and you could time the effect of the situation if you used it in the conditions. Or vice versa.
I think that you wouldn't need any shorter time than 1 minute and nothing longer than 24 hours so you could get away with two sliders to control your timer (minutes slider and hours slider)
-
Marcin
commented
I think that it's rather some kind of condition, however it may be understood as a step, eg condition1-delay-condition2; or setting1-delay-setting2
Regarding, how long of a delay people would like, I guess it would be usually a few minutes, like 3-15 with a default value of 5. -
AndCycle
commented
agree with this one, tasker have similar function called cool down time,
this will be useful to prevent profile repeat it self in short time,although there is a plugin called "Locale Timer Plug-in" by DroidMunkey LCC,
it's not working at all and the company seems abandoned all their developed plugin,
this is really frustrated. -
Johan E. Johansson commented
I agree. I use conditions as screen orientation (phone turns silent when upside down, for meetings) and such a lot that are quite sensitive. Now, if there would be a slight delay, say only 10 seconds or so, it would be awesome.
Since most situations require Locale to react instantly, I understand this could be a bit hard to implement in an easy and logical way. But how about just adding an "if X" in "Y" seconds parameter to the conditions, that's optional?
Or even better, seeing as there's a lot of requests here that would make Locale to complicate, make it a basic, "simple" version and a more complex "advanced" version, much like JuiceDefender applies.
-
Brian White
commented
Like Ryan said...
I've found that many conditions would benefit from "after being active for X time" (with X perhaps being seconds, minutes, or even hours).
- lost cell signal (after 10 minutes)
- wifi enabled (after 30s for it to connect)
- got up in the morning (after 1 hour)Rather than have all the plug-ins try to support this, it would make sense to have it supported by the main app.
BTW, this would apply to both the condition appearing and the condition going away, probably with different delays for each.
-
byron.kuhn
commented
I would like this too, but more for things like any time my Bluetooth is on and unconnected for 10 minutes, shut it off.
-
Ryan B
commented
i can actually imagine this as an entirely new "duration" condition. it would require that all of the other conditions have been true for a certain period of time before firing the situation's actions. if any of the conditions becomes false before the duration has passed, the duration timer would restart once the conditions are all true again.
hmm, i wonder how hard this would be to write as a plugin...
