On Tue, Dec 30, 2014 at 1:34 PM, Tim Guan-tin Chien <[email protected]> wrote: > On Tue, Dec 30, 2014 at 12:44 PM, Hsin-Yi Tsai <[email protected]> wrote: >> Hi all, >> >> One more question: with this new proposal, how are applications going to >> display "user preference" instead of a current state, like what we've done >> in utility tray? Need one more attribute? >> > > Most of the time, interfaces are designed to be a both read and write > interface for user (e.g. checkbox). > I am not entirely sure what you mean by utility tray. The quick > settings buttons exhibits the same behavior. > > If the user are allowed to change things and only apply when they say > so, I would imaging such UI be placed in a dialog with Back/OK buttons > (and with OK means apply now)
Hi all, I just talk to Hsin-Yi offline and I would like to make some clarification here, by means of describing steps to run when the said method is called: A. Steps to do when setFooEnabled(false) is called: 1. If the state is not "enabled", reject the promise and stop. 2. If not, switch the property to "disabling". 2. Dispatch a property change event. 3. Submit the disable request to the relevant hardware. 4. If the request is fulfilled by the hardware, 4.1 Switch the property to "disabled". 4.2 Set the persistent state to "disabled". 4.3 Dispatch a property change event. 4.4 Resolve the promise. 5. If the request is rejected by the hardware, 5.1 Switch the property back to "enabled". 5.2 Dispatch a property change event. 5.3 Reject the promise. B. Steps to do when the phone boots: 1. The state should start with "disabled". 2. If the persistent state is "enabled", run steps as if |setFooEnabled(true)| is called. The important thing to clarify is section A point 4.2: Persistent state (e.g. Gecko pref) should not change if the request to hardware is rejected -- therefore, a failed setFooEnabled() call should not result any side effect. Also, the switch state has no requirement to bind the hardware state -- such as network state of the WIFI or RIL. It's up to the API or the hardware to define the requirement to fulfill the hardware request (e.g. the already connected network must be disconnect before we fulfilled the hardware-disable request). The only requirement here is section A point 1: to prevent race (to the hardware or the UI), we should reject the API call when the state machine is "working" (i.e. "enabling" or "disabling") or when the operation is simply invalid (i.e. the state is already "disabled"). Thanks, Tim _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
