IMO solving this at the ui-toolkit level is not correct, as that still leaves the problem for system services e.g. indicator-datetime.
seb128, looks to me like a lot of this traffic is coming from system-settings. src/accountsservice.cpp AccountsService::setUpInterface() is the source of the FindUserById() call, and the Get calls are coming from when the code pulls the properties for IncomingMessageVibrate, IncomingMessageVibrateSilentMode, OtherVibrate, DialpadSoundsEnabled, IncomingCallVibrate, IncomingCallVibrateSilentMode.
Two suggestions:
1. It's not clear to me why these are being stored in AccountsService instead of in gsettings-ubuntu-touch-schemas. The latter seems the more logical place for it and would be easy to implement; e.g. if the properties mentioned above were simple properties in com.ubuntu.touch.sound. Indeed, it looks like there's already some overlap, as there's a silent-mode property both there and on AccountsService. I'd be happy to write g-u-t-s and u-s-s patches for these if everyone's agreeable on this being moved to touch-schemas. (This would benefit indicator-datetime too :-)
2. For client applications, I agree with mdeslaur, that it would be good to have a service handle this instead of relying on client apps to monitor the setting and do the right thing; e.g. adding an intent argument to usensord's "VibratePattern" method specifying whether the vibration is due to an incoming call, a received message, or other. That still wouldn't solve the problem for system-settings, which still has to get/set the fields.
IMO solving this at the ui-toolkit level is not correct, as that still leaves the problem for system services e.g. indicator-datetime.
seb128, looks to me like a lot of this traffic is coming from system-settings. src/accountsser vice.cpp AccountsService ::setUpInterfac e() is the source of the FindUserById() call, and the Get calls are coming from when the code pulls the properties for IncomingMessage Vibrate, IncomingMessage VibrateSilentMo de, OtherVibrate, DialpadSoundsEn abled, IncomingCallVib rate, IncomingCallVib rateSilentMode.
Two suggestions:
1. It's not clear to me why these are being stored in AccountsService instead of in gsettings- ubuntu- touch-schemas. The latter seems the more logical place for it and would be easy to implement; e.g. if the properties mentioned above were simple properties in com.ubuntu. touch.sound. Indeed, it looks like there's already some overlap, as there's a silent-mode property both there and on AccountsService. I'd be happy to write g-u-t-s and u-s-s patches for these if everyone's agreeable on this being moved to touch-schemas. (This would benefit indicator-datetime too :-)
2. For client applications, I agree with mdeslaur, that it would be good to have a service handle this instead of relying on client apps to monitor the setting and do the right thing; e.g. adding an intent argument to usensord's "VibratePattern" method specifying whether the vibration is due to an incoming call, a received message, or other. That still wouldn't solve the problem for system-settings, which still has to get/set the fields.