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?
Best regards,
Hsinyi
Alive 於 12/30/2014 12:28 PM 寫道:
於 2014年12月30日 於 下午12:18:26, Kevin Grandon ([email protected]
<mailto:[email protected]>) 寫:
Just curious, would this be a non-issue if we stored more information
than just a boolean? What if we stored additional information say, in
JSON? Have we thought about using datastore?
I think the problem is the race. You won’t know how long the
datastore/settings db will callback, and the callback from enabling to
enabled really does not mean navigator.HARDWARE.status is ‘enabled’
because the database operation is async and anything could happen
during the database observer operation.
But if the hardware API has status change event we could make sure we
always have the correct status in the callback.
As we've seen in the past moving stuff into gecko can be a slippery
slope, so we should definitely think this out thoroughly. In any
case, it seems that this might create a more friendly API for third
party developers, so a +1 from me on that front.
It does seem like a *lot* of work though. I think it'd be worth while
to do an initial investigation on both a platform fix and a different
store in gaia to make sure we invest our time wisely.
Best,
Kevin
On Mon, Dec 29, 2014 at 9:39 PM, Tim Guan-tin
Chien<[email protected] <mailto:[email protected]>>wrote:
TL;DR: I proposed all hardware API switches to not only move out of
mozSettings database, but also have the API taking it's own
responsibility to make the settings persistent, and expose the
current
value and changes through the API.
Hi,
I would like to make sure we reach a consensus on we should deal with
hardware switches and it's relations with mozSettings.
Back in FxOS v1.0 we made a mistake moving some hardware switches to
mozSettings, and it's problem to cause a lot of headaches. The
boolean
in the settings is proven to be not enough to reflect the status of
API (e.g. is being enabled, or failed to be enabled) and a lot of
bugs
was caused by this. People then was mostly agreed we should move the
switches back to the APIs, e.g. mozMobileConnection.setRadioEnabled()
and returns a Promise.
Yet, once the switch has been move out of the API, we have not yet
decided what we should do with mozSettings. The settings is still
needed because we would like to keep the user preference persistent
across reboot (e.g. when the radio is turned on|off, it stay on|off
when the phone reboots). But then we have the problem who is
responsible of setting and getting these settings.
1. If we let the API caller (e.g. Settings app) to set the
mozSettings, we would have to do
(A) in Settings app
mozMobileConnection.setRadioEnabled(val)
.then(function() {
return navigator.mozSettings.createLock().set( ... );
});
and (B) in Systems app when the phone boots.
navigator.mozMobileConnection.createLock().get( ... )
.then(function(value) {
return mozTelephony.setRadioEnabled(value);
});
This is undesirable because
1. Not every API switch caller do (A) has access to mozSettings
should
the API become privileged, and even if they do we can never sure they
have indeed updated the settings correctly.
2. (B) currently contributes to phone boot-up time a lot, which is
documented in bug 1095034 ("Too much IndexedDB on startup").
So I talked to Hsinyi, Alive, and Arthur, and I come up with the
proposal
and they agree: I propose the responsibility of keep the status
should be
moved from Gaia to Gecko, specifically, each of the APIs should keep
their own status in a clean way, and simply remove the
mozSettings key
altogether. The API can keep the value in Gecko pref, which we can
make sure the hardware status and the pref is always in sync, and
Gaia
will take the value returned from API (a |getRadioEnabled| method for
example, or an |radioEnabled| property?) as a single source of truth.
We would also need the API to send a change event to all document
when
the status changes.
Thoughts and comments? Thanks.
Tim
_______________________________________________
dev-webapi mailing list
[email protected] <mailto:[email protected]>
https://lists.mozilla.org/listinfo/dev-webapi
--
Hsin-Yi Tsai 蔡欣宜
Mozilla Taiwan
[email protected]
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
