Skip to main content

Architectural considerations for persistence relative to device settings

2 replies [Last post]
Joined: 2010-01-05

I'm probably missing something relatively obvious here, but, here goes....

I'm writing an application. In this application, I set the sound to be muted. Now, this mute persists through a power cycle. No issues there. However, I would like my application to know through a 'getMuted', if it existed, if we're muted, and update the appropriate visual controls.

There isn't really a 'getMuted'. This isn't too big of a deal, I know a workaround.

However, what concerns me, is the 'setMuted' function in function. It sets the 'muted' value on the class-load to be 'false'. Which is fine and dandy, but how does it really know what the underlying native implementation really has as a value?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-07-03

To your first point -- AudioOutputPort has both isMuted() and setMuted() methods. The isMuted() method would be the equivalent to your "getMuted" request. Is this not what you were looking for?

As far as persistence of AudioOutputPort settings, the method AudioOutputPortImpl.initFromPersistence() will query native to determine the persisted value of each setting at boot time.


Joined: 2010-01-05

AH HA! My supposition was correct and... it was something obvious.

The rest is probably implementation specific and I had better double-check.

Thanks, and thanks for your patience!