Jacek Szafarkiewicz
-
85 votescompleted ·
AdminCarter
(Admin, two forty four a.m.)
responded
Locale 3.0 introduces enhanced Bluetooth management. If you’re on a call using a Bluetooth device and Locale’s Bluetooth OFF setting is fired, Bluetooth won’t be turned off until either the call ends or the Bluetooth device is disconnected.
To learn more about Locale 3.0, please see the release notes here http://blog.twofortyfouram.com/post/19303488607/locale-3-0
Jacek Szafarkiewicz
gave this 3 votes
·
-
91 votesunder review ·AdminCarter
(Admin, two forty four a.m.)
responded
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) -… moreJacek Szafarkiewicz
gave this 3 votes
·
-
3 votesdeclined ·AdminCarter
(Admin, two forty four a.m.)
responded
This is an interesting idea that we’ve considered in the past but ultimately found that it won’t achieve the desired effect of improving battery life.
Instead of ranking conditions based on battery usage, Locale ranks them based on schedule. This is far simpler and more efficient.
Plug-ins shouldn’t be doing anything that consumes a lot of battery power anyway. Plug-ins are supposed to be detecting asynchronous state changes (or pre-scheduled state changes), rather than relying on polling. For example, connecting a Dock is an asynchronous event and a Calendar condition is a pre-scheduled change. Neither of these require polling, so neither of these should consume any battery power whatsoever. They happen once and they are done. So if plug-ins are implemented correctly, there’s no need to worry about battery usage.
Jacek Szafarkiewicz
commented
·
This can be also useful for determining position - when "cell id" (with accuracy e.g. 2000 m) tells I am out of any condition (e.g. in other city) it don't have to check WiFi.
Jacek Szafarkiewicz
shared this idea and gave it 3 votes
·
In this case you are right but I want to write a plug-in that detects bluetooth device in range.
And it will be checking if phone can query the device.
I thought it should be determined by some other condition e.g. location, so it won't query multiple devices.