I’ll first address the specific request of a Portrait/Landscape condition: we will not add this feature to Locale because it won’t work as expected. The first problem is that “portrait” and “landscape” are not well defined on Android and do not match user expectations. For example, the Motorola Charm is actually in landscape when the device is held vertically. This weird behavior is documented here http://android-developers.blogspot.com/2010/09/one-screen-turn-deserves-another.html The second problem is that Locale is a background app and therefore it should detect changes while the screen is off. But Android’s notion of portrait/landscape is only updated while the screen is turned on.

Let’s take a step back though and take a broader look at this request. If a car dock isn’t opening Android’s Car Mode, most likely it isn’t a real dock. A real Android dock tells Android what type of dock it is, and these are usually made by the manufacturer of the Android device (e.g. Samsung makes docks for Samsung phones, HTC makes docks for HTC phones, and so on). Third party docks, on the other hand, are usually nothing more than some plastic and a power connector, and present themselves to Android as merely a charger. In general, the real solution to this “problem” is to buy a real dock from the phone’s manufacturer rather than a third party knockoff.

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!

The original request here was for a logical NOT operator, although it doesn’t make sense to create a logical NOT operator in Locale. Most of the time, NOT isn’t the right way of thinking about a Condition. For example, NOT 9 am to 5 pm could be redefined as 5pm to 9am. NOT at work would simply be the Default situation. For the other conditions built-in to Locale, thinking about the problem in a different way usually means that NOT isn’t needed. If a Condition truly needs NOT logic, then that should probably be put into the individual Condition’s UI itself rather than as part of the Edit Situation screen in Locale.

Although this request is for a NOT operator, I believe the underlying request here is a way of detecting the transition between situations. The strongest use case would be detecting when you’ve left a particular Location. While Locale can easily detect the transition between situations, providing a UI to allow the user to do something with that transition is extremely complex.

Today, Locale treats situations as a continuous event. When Locale determines that a situation is active, it applies that situation’s settings. When leaving a situation, a lower priority situation’s settings take precedence (usually the Defaults). This provides a single, consistent behavior that makes Locale easy to understand.

One suggested implementation is to have “On Enter” and “On Exit” settings within a situation. On Enter settings would work like the current settings within Locale, while On Exit would be applied when leaving a situation. But what if the On Exit settings of a situation are in conflict with the On Enter settings of a higher-priority situation? The number of arrangements that the user must think about has just doubled.

We’re still evaluating ways to solve the underlying requeste of “leaving a location”, without making the UI too complicated…

UPDATE:

Locale 1.4 includes significant improvements to the location detection system, reducing time to detect location changes by 20% while also improving battery usage by up to 50%.

The original goal of this request—reducing the delay of detecting location changes—has been met as Locale 1.4 detects location changes within an average of 4 minutes. We are therefore marking this request as completed.

Although this request is being marked as completed, we have ongoing research and development to keep improving the speed and efficiency of the location detection system further :).

(Original response)

By design, Locale has no user-configurable options. The goal is that Locale should “just work” without requiring users to fiddle with various options that could negatively impact the operation of the app. For example, asking Locale to check location every minute could cause the battery to drain within 2 hours at which point you might miss the train stop anyway.

Although a user-configurable option won’t be implemented, I see the underlying goal as improving how quickly Locale detects that location has changed. For Locale 1.3 and earlier, it can take up to 10 minutes for location changes to be detected.

I’m therefore repurposing this request for implementing improvements to the speed of the location detection system. Once these improvements are completed, a user-configurable update frequency will no longer be necessary.