ubuntu-phone team mailing list archive

["Alejandro J. Cura" <alejandro.cura@xxxxxxxxxxxxx>]

On Fri, Jun 13, 2014 at 3:48 AM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx> wrote:
> From the push notification service perspective, the incoming message
> is not descriptive enough to automatically map the incoming message to
> one of the visual cues. For that to happen, we need assistance from
> the app to translate between the message's payload and the declarative
> language of the visual cue endpoints. This is where the helper comes
> into play. Once the translation has happened (under tight resource
> constraints), the push notification service decides where to put the
> visual cue according to user preferences.
>
> The alternative approach would be to encode all endpoint-specific data
> (think: notification title, subtitle, icon, sound, haptic feedback)
> into the push messages. While technically doable, we would end up with
> quite a bad signal/noise-ratio per message, where signal refers to the
> app-specific payload and noise refers to any system-specific field.

Thanks for the detailed explanation, it's very clear how this would work now.

Still, this looks like giving much too flexibility on what to show and
how to annoy the user (sound, haptic feedback!) to apps we don't
trust.
Do we have clear use cases for this added flexibility?

(I keep thinking of the "Talking Cat" type of apps that plague the
android store, and that kids love, but then annoy you to death with
notifications to remind you to buy virtual food and to play again,
and...)

cheers,
-- 
alecu