jjayxxxx

← Locale Feedback

Speed Condition
82 votes
Vote 0 votes Vote Vote
Vote

Sign in
prestine

Your email address
Check!

invalid email

(thinking…)

Reset

or sign in with

UserVoice password

Forgot password?

Create a password

Your name
I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)
6 comments · Locale Feedback · Admin →

under review · AdminCarter (Admin, two forty four a.m.) responded

Calling this a true “driving” condition would be a misnomer, as a number of other factors would actually be used to guess that the user was driving. This request would simply detect the speed at which the phone is moving.

There are two ways currently to detect when the phone is in a car: a car dock condition or a Bluetooth condition, both of which are available now as plug-ins on the Android Market.

We’ve been investigating an implementation for a “speed” condition, and we’re confident we can create a reliable and low-power consumption implementation. There are just a number of considerations to take into account before doing so. After reading all of the comments, it appears that there are several different goals that users have in mind. Let’s look at a few of them:

1. Power savings: some users want to enable Bluetooth in the car and disable Bluetooth everywhere else. Unfortunately a speed condition would consume far more power than Bluetooth, so users are much better off simply leaving Bluetooth on all the time. Scratch this one off the list.

2. Safety/regulatory: some users want to turn the ringer off while driving, due to distracted driving safety and regulatory considerations. For this, there are some considerations:

First, how quickly would users expect Locale to detect a change in speed? The more quickly Locale detects a change in speed, the greater the impact on battery life. If the “speed” condition drains the battery in 4 hours, it doesn’t do anyone any good. Based on our research, there may be up to a 10 minute delay before speed changes can be detected. Would such a delay reduce the usefulness of a speed condition?

What about the reverse? How quickly would users expect the driving condition to deactivate once they stopped driving? Would it be annoying that you wouldn’t receive phone calls for 10+ minutes after you got out of the car? And how would users expect this condition to behave in bumper-to-bumper traffic? If the phone is moving at a slow speed for a long period of time, the speed condition might deactivate.

3. Finally, there are probably some other creative uses for a speed condition besides just to detect driving… Let’s hear them!

Calling this a true “driving” condition would be a misnomer, as a number of other factors would actually be used to guess that the user was driving. This request would simply detect the speed at which the phone is moving.

There are two ways currently to detect when the phone is in a car: a car dock condition or a Bluetooth condition, both of which are available now as plug-ins on the Android Market.

We’ve been investigating an implementation for a “speed” condition, and we’re confident we can create a reliable and low-power consumption implementation. There are just a number of considerations to take into account before doing so. After reading all of the comments, it appears that there are several different goals that users have in mind. Let’s look at a few of them:

1. Power savings: some users want to enable Bluetooth in the car and disable Bluetooth… more

jjayxxxx gave this 3 votes · October 12, 2011
Provide a condition that detects when you are moving or driving
3 votes
Vote 0 votes Vote Vote
Vote

Sign in
prestine

Your email address
Check!

invalid email

(thinking…)

Reset

or sign in with

UserVoice password

Forgot password?

Create a password

Your name
I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)
0 comments · Locale Feedback · Admin →

declined · AdminCarter (Admin, two forty four a.m.) responded

I agree this would be very cool. Unfortunately, modern phone hardware isn’t there yet.

Locale 2.0 detects motion in the context of predicting location arrival with historical data. Having historical location data and a target location introduce additional constraints to the problem, making it easier to solve efficiently.

To just detect motion (without the additional constraints of location) would still have a 10 minute delay. Based on our research, motion detection would need to be instant in order to really make users happy.

We’re always evaluating new ways to solve this problem, but its just not currently possible.

jjayxxxx shared this idea and gave it 3 votes · October 12, 2011
Different icons for location notification
262 votes
Vote 0 votes Vote Vote
Vote

Sign in
prestine

Your email address
Check!

invalid email

(thinking…)

Reset

or sign in with

UserVoice password

Forgot password?

Create a password

Your name
I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)
19 comments · Locale Feedback · Admin →

jjayxxxx gave this 3 votes · December 05, 2010
"check location now" button on locale main screen
8 votes
Vote 0 votes Vote Vote
Vote

Sign in
prestine

Your email address
Check!

invalid email

(thinking…)

Reset

or sign in with

UserVoice password

Forgot password?

Create a password

Your name
I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)
1 comment · Locale Feedback · Admin →

completed · AdminCarter (Admin, two forty four a.m.) responded

Locale support this already: simply open the app it and it will immediately check your location.

Locale doesn’t have a specific frequency in which Locations will be updated; the app uses an advanced scheduler to decide when location should be checked. On average, location changes will be detected within 4 minutes.

To improve Location accuracy, please read about training on our support page http://www.twofortyfouram.com/support.html

jjayxxxx commented · January 07, 2011

This idea was proposed as a solution to the problem of a potential 10-minute lag (apparently Locale only checks every 10 minutes) and/or the problem of poor GPS reception in a building.

I have sort of gotten around this problem by attaching other conditions with some of my locations, and widening the location radius. For example, I have a situation called "At the gym" which would never seem to kick in when I arrived. However, since I always use my bluetooth headphones I decided to add the Bluetooth plug-in by Andvari and set a condition for when that particular bluetooth connection is made. And the important thing I did was then make the location radius much larger (over 2000m) so that the GPS didn't need to be accurate (and perhaps cell towers would be used instead, saving some battery!).

Now whenever I arrive at the gym the moment I turn on my headphones my phone switches to "At the gym" mode.

Of course this work-around only exists when you have some other condition you can add to the situation.

jjayxxxx shared this idea and gave it 3 votes · November 18, 2010
Duplicate situation
23 votes
Vote 0 votes Vote Vote
Vote

Sign in
prestine

Your email address
Check!

invalid email

(thinking…)

Reset

or sign in with

UserVoice password

Forgot password?

Create a password

Your name
I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

You have left! (?) (thinking…)
2 comments · Locale Feedback · Admin →

completed · AdminCarter (Admin, two forty four a.m.) responded

Locale 1.3 now uses an XML format for backup files on Android 2.2 and later. The format of the files is really an internal implementation detail, and backup files are not considered a public interface to the app. In fact, the backup files contain the following warning: “WARNING: This file is not designed to be human-editable. Treat this file as if it were a swarm of angry bees: disturb it and you will get stung!”

With all of that said, it is possible to create a backup file, literally copy and paste a situation element, and then restore the backup file. I don’t recommend this solution, however it does implement this feature request for those feeling adventurous.

jjayxxxx commented · November 02, 2010

While i appreciate that this item might technically be feasible with the backup/restore scheme already in place, it is most certainly not usable. The idea is to make use of the existing UI by adding a long press option or a 'copy' button or some such. If you have to use the backup scheme to make a copy you may as well go through the hassle of creating the duplicate situation manually in the first place.

jjayxxxx gave this 3 votes · October 29, 2010

Sign in

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Sign in
Sign up

New users can just enter their email address :)

Searching

No results.
Clear search results

Give feedback
- Locale Feedback 43 ideas
two forty four a.m.