18 comments

Add a comment…

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

Post comment Submitting...

• Bob Kerns commented  ·  June 21, 2010 10:32  ·  Flag as inappropriate  ·  Delete

  Carter writes:
  "This really isn't a volume specific request, as third party apps may want notification of arbitrary setting changes made by Locale. For example, imagine an app that only wants to download data over Wi-Fi. It might want to avoid downloading data during Locale's periodic Wi-Fi location scans. Given the complexity of implementing such a notification API, this isn't something we'd implement without significant design over the course of several months. In addition, Locale isn't the only app that can change setting on an Android phone. We'd need a standard that everyone could agree on.

  In the meantime, this specific feature request has been implemented by a third party developer. The free Locale Audio Update Notifier is now available on the Android Market!"

  Actually, I do consider this to be a volume-specific issue.

  You can already get notification of changes to settings, once they've occurred. The issue here is because volume, unlike any other example I can think of, is something people want to *LOCK* -- that is, restore and disallow changes to.

  And the reason for that is the presence of a physical key that messes with your volume settings.

  I think you've over-generalized the problem. While a general notification protocol might possibly be useful, I don't know of any failing behavior that it addresses. The volume issue, however, addresses what I consider a failing in the audio manager, and prevents an out-and-out conflict between applications seeking to address this failure that results in making the device rather unusable.

• yvolk commented  ·  June 20, 2010 10:00  ·  Flag as inappropriate  ·  Delete

  Hi pals,
  Locale-Audio-Update-Notifier and RingGuard version that supports it's notification
  are both being published on Google Market!
  Please see screenshots at http://code.google.com/p/locale-audio-update-notifier/

• yvolk commented  ·  May 30, 2010 10:17  ·  Flag as inappropriate  ·  Delete

  Hello guys!
  I've implemented first version of my "Locale Audio Update Notifier" setting plug-in,
  put source code to the Repository and prepared .apk file for testing.
  
  I've tested it with special version of RingGuard that x475aws sent to me... Currently it works "sometimes", I mean I couldn't figure out why RingGuard sometimes honors ("likes") my notification, sometimes - not :-(
  
  Project Home Page: http://code.google.com/p/locale-audio-update-notifier/

• Bob Kerns commented  ·  April 04, 2010 22:06  ·  Flag as inappropriate  ·  Delete

  I'd just like to chime in here.

  First, I'd like you guys to take this back OUT of email. This is NOT a private issue, contrary to Carter's assertion. The very fact that I am here commenting is evidence of this.

  (And I, in turn, am here due to a specific request from a user of my app and the others).

  This is a generic issue, and a generic, open approach is needed.

  In fact, the we have an approach on the table which is already implemented by three independent applications -- RingGuard, Advanced Volume Manager, and my application SmartVolume. (I haven't uploaded the change yet).

  Carter's proposed solutions are non-solutions. For this to work, Locale's volume setting needs to follow the protocol. Not "if users use your setting exclusively". Not if the change happens to be >1 unit. (Even if that were a reasonable limitation -- it is not -- we don't get informed by the ContentObserver of each step. They get batched up).

  Think of this as being a good neighbor. People use volume manager applications for a variety of reasons -- often to offset design flaws in volume control placement on physical devices.

  So this is for the user's benefit. For our applications to work together smoothly, we need to be able to distinguish between the different sources of changes.

  Using a non-standard Locale plugin to do this is not a solution. Users won't know to do it, or won't like the extra hassle, etc. This really needs to be something Locale participates in, or not. And if not, it's most likely to be viewed as a limitation of Locale -- though it's anyone's guess which app gets uninstalled.

  However, I think the protocol does need a bit more work.

  1) It's not registered at openintents.org -- it should be.
  2) It seems to me that Advanced Audio Manager only sends it for the ringer volume. I'm investigating and will take it up with Perry Nguyen.
  3) The protocol lacks any indication of the source of the change. I think two indications are needed -- a programmatic identifier (package ID) and a user-friendly name (which could be localized). These would, of course, be two additional extras.

  I suggest org.openintents.audio.extra_source_id and org.openintentns.audio.extra_source_name

  This allows the receiving app to decide whether a particular change should be allowed -- hopefully in a way that captures the user's intent. (I don't think we should at this stage attempt to incorporate user intent into the protocol).

  I think the problem and solution are reasonably straightforward. I expect we can come to agreement pretty quickly, and all come out the better for it.

  You can email me at rwk -at- acm-dot-org.

  Thanks.

• yvolk commented  ·  March 27, 2010 04:17  ·  Flag as inappropriate  ·  Delete

  Ok, please email me yvolk at yurivolkov dot com.
  --
  Yuri

• x475aws commented  ·  March 26, 2010 17:43  ·  Flag as inappropriate  ·  Delete

  You may well succeed in convincing me. Let's take this to email. I'm going away on vacation so nothing will happen right away.

• yvolk commented  ·  March 26, 2010 13:14  ·  Flag as inappropriate  ·  Delete

  So let's compare different scenarios to help you decide,
  in which case RingGuard will have higher rating:
  1. RingGuard is being used without Locale.
  - No difference, if it was adapted as I propose or not.
  2. RingGuard is being used with Locale AND no volume setting Locale plugin is used.
  - Same as above: no difference.
  3. RingGuard is being used with Locale AND some volume setting Locale plugin is used.
  3a. RingGuard is the same as now - without modifications:
  - If User sees "confirm dialog" when Locale decides to change volume, User has to figure out what happened: properly and quickly, - and then either confirm or cancel the dialog. Believe me, this is bad user experience :-)
  - If User missed the moment, the volume wouldn't be changed, so desired volume change wouldn't occur at all. Bad too (e.g. if phone rings at night when User hopes it wouldn't...)
  3b. RingGuard was adapted as I propose:
  - User may see "confirm dialog" when Locale decides to change volume, but after a second or two... the dialog disappears.
  - If User missed the moment (this means if he or she didn't look at the screen for some seconds...), the volume will be changed, as intended. Good, because User doesn't know about this.

  ...I am personally at the point 3a now and I don't like the situation. Do you know which app I will uninstall? ;-)

• x475aws commented  ·  March 26, 2010 07:41  ·  Flag as inappropriate  ·  Delete

  I was going to say that if it means so much to you, I would let you do the plugin and I'd modify RingGuard. But then I remembered what I mentioned earlier, that the confirm dialog coming up and disappearing will be a poor user experience. You might not mind, but other users will surely downgrade me for it. Good ratings are a priority for me.

• yvolk commented  ·  March 25, 2010 02:20  ·  Flag as inappropriate  ·  Delete

  Hi x475aws,
  _I_ may do these modifications:
  1. I will write and publish the "Locale RingGuard setting plug-in". I just need your API specification to achieve this (I don't see it at http://www.openintents.org/en/intentstable , please post me).
  2. To modify RingGuard itself
  to make it accept Intent with Volume change info not only before actial Volume change, but also during "Wait time", that's already configurable in RingGuard,
  I need your help. There may be two options:
  a) You make these modifications yourself. In fact these are NOT Locale-specific modifications: they effectively extend breadth of your RingGuard usage...
  b) You trust me to make these modifications in your code (we may discuss NDA privately).
  I will do modifications and testing, and then
  I will send modified version to you to be included in the next release on the RingGuard and published by you.

  So what's your move?

  (I've added comment some minutes ago, but it disappeared... so this reposting)

• x475aws commented  ·  March 23, 2010 20:08  ·  Flag as inappropriate  ·  Delete

  yvolk, thanks for clarifying this ("exclusively" means "without any others being included or involved", so if you're right, then "exclusively" wasn't the right word to use). But to tell the truth, at this point I'm not interested in writing and debugging Locale-only modifications to RingGuard. Two months ago I might have decided differently. But now RingGuard has the code to handle the open intent, which I think is a perfectly good solution.

• yvolk commented  ·  March 22, 2010 15:44  ·  Flag as inappropriate  ·  Delete

  >yvolk, maybe I misinterpreted the word "exclusively" in Carter's statement
  >"As long as users use your setting exclusively within Locale, then you'll always receive
  > an Intent before Locale changes the volume."
  No, I think you understood Carter right: he wrote about single "Settings plugin" that will change volume AND then send Intent to RingGuard.

  > So you're saying users could combine a no-op RingGuard setting
  > with the settings they already use?
  2. Yes, my proposal will allow to use any existing Volume settings plug-in in combination with non-op RingGuard setting plug-in (the letter plugin is thus "RingGuard enabler" :-) ) .

  3. What's about race condition, I think that it is enough for RingGuard to accept Intent with Volume change info during "Wait time", that's already configurable in RingGuard.
  I personally have set the "Wait time"= 15 sec, so I'm sure this is enough time to wait for that Intent.
  And of course, you'll have to create good Documentation for your "Locale RingGuard setting plug-in", describing what it does (and what it doesn't do) and how RingGuard app itself should be configured to work with Locale...

• x475aws commented  ·  March 22, 2010 09:53  ·  Flag as inappropriate  ·  Delete

  yvolk, maybe I misinterpreted the word "exclusively" in Carter's statement "As long as users use your setting exclusively within Locale, then you'll always receive an Intent before Locale changes the volume." So you're saying users could combine a no-op RingGuard setting with the settings they already use?

  The race condition is a problem. A delay of several seconds probably is indeed necessary, since AFAIK there's no timing guarantee for intent delivery. Clearly RingGuard can't wait several seconds before putting up a confirm, in the expectation that it might receive an intent from Locale. So it would have to put up the confirm, and then cancel it if it gets an intent. Not a good user experience, and sure to generate some poor ratings.

  Advanced Audio Manager and cVolume already send the "org.openintents.audio.action_volume_update" intent, and Setting Profiles is working on it.

• yvolk commented  ·  March 22, 2010 07:48  ·  Flag as inappropriate  ·  Delete

  @x475aws It came to me that in order to "integrate" Locale with your application (RingGuard), you have to write VERY simple "Locale RingGuard setting plug-in"
  that does nothing except sending your custom Intent to your application :-)
  According to this approach User continues to use any "Locale Volume setting plugin" he or she wants (including built-in plugin), but in order to live with your RingGuard application User has to add to the "situation", that has "Locale Volume setting plugin" another setting plugin, the "Locale RingGuard setting plug-in" plugin.

  The only problem may be in "Broadcast races". I mean information that volume was changed may be received by your application (sligthtly) before broadcast from "Locale RingGuard setting plug-in".
  You should change RingGuard logic so that it may accept broadcasts that come even slightly after volume changes (maybe even upto some seconds...)

  What do think?

• x475aws commented  ·  March 01, 2010 18:21  ·  Flag as inappropriate  ·  Delete

  I did consider this, but concluded it wouldn't meet the needs of Locale users who want to benefit from RingGuard while continuing to use Locale in their accustomed way.

  If you ever want to consider the broadcast intent solution, I have the code in RingGuard now. Please see

  http://x475aws.blogspot.com/

  Thanks.

• AdminCarter (Admin, two forty four a.m.) commented  ·  February 26, 2010 05:27  ·  Flag as inappropriate  ·  Delete

  One other option: create your own Volume setting plug-in for Locale. As long as users use your setting exclusively within Locale, then you'll always receive an Intent before Locale changes the volume.

• x475aws commented  ·  January 19, 2010 10:09  ·  Flag as inappropriate  ·  Delete

  I'm absolutely not asking for a special case for my app, sorry if that wasn't clear. Quoting from the Android docs: "Intent objects passed to any of the broadcast methods (such as Context.sendBroadcast(), Context.sendOrderedBroadcast(), or Context.sendStickyBroadcast()) are delivered to all interested broadcast receivers." So, any of the volume-control apps could listen for a volume-change intent from Locale.

  Your suggestion about Settings ContentProvider is interesting, thanks. To use it with the suggested heuristic, though, the system would have to guarantee that intermediate volume notifications could never be dropped in the interest of efficiency. If that happened, then the heuristic would be falsely triggered, and RingGuard's one and only function would break.

• AdminCarter (Admin, two forty four a.m.) commented  ·  January 18, 2010 19:56  ·  Flag as inappropriate  ·  Delete

  Any Intent that Locale broadcasts for consumption by 3rd party apps must be part of a detailed API specification. We can't create a special case for your app, since there's lots of others just like it (dgSuper Silent, Shush! Ringer Restorer, etc. for example)

  You might be able to register a ContentObserver for the Settings ContentProvider, although you'd have to do some digging through the Android source code.

• x475aws commented  ·  January 18, 2010 11:37  ·  Flag as inappropriate  ·  Delete

  I should have said broadcast intent, not implicit intent, sorry (like I said in my email, I'm new to Android). If I understand correctly, it would just be a matter of defining some new intent actions, and then using sendBroadcast to send them out at the appropriate time. If you need a response from each receiver then of course it's a lot more complicated. There is a timing consideration in the ring volume case, and if it has to work 100% reliably under every possible condition, then you would need a response. I'm assuming that some delay between sending the intent and changing the volume, perhaps a second or two, would mean that RingGuard would get the intent before it saw the volume change under nearly all situations. Maybe I'm wrong, or maybe you do want 100% reliability, not 99.999%.

  Thanks for the suggested heuristic. The problem is that there's no ring-volume notification, at least not one that really gets sent. So RingGuard polls every 0.5 second (no effect on battery consumption that I've seen), so it won't see intermediate volume values.