Hi Alexis,
An idea for implementation: keep the setters "fire and forget" (so can
be implemented as async messages in the extension), but keep a flag
marking there's a pending change. When you get an update from a system
callback, you clear the flag. If the getter is called with the flag on,
it will just make sure next update from system will send the sync reply.
In case of screen on/off, you always track the changed callback, so
things would look like, from a very high level perspective:
bool pending_state
bool pending_reply
value cached_value
turnScreenOn(): // Async.
call native API to turn on
if call was OK, mark pending_state
turnScreenOff(): // Async.
call native API to turn off
if call was OK, mark pending_state
isScreenOn(): // Sync.
if pending_state:
mark pending_reply
else:
set sync reply to a cached_value
onScreenStateChanged(): // Callback from system.
update cached_value
if pending_reply:
set sync reply to cached_value
clear pending_reply
clear pending_state
One benefit of this approach is that you can avoid busy looping /
waiting in the native code, don't blocking other code that might be
running in the extension process. If you don't trust the platform, you
may want to set a timeout to send the pending reply with whatever value
you got cached.
For the brightness case, taking a quick look at how WRT plugins
currently implement, it seems that if the application changes the
brightness itself, then the value returned comes from the cache (the
logic is a bit more contrived). You probably could do the same.
Cheers,
Caio
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
