Redundant SMS Notifications
Closed, ResolvedPublic

Description

When receiving SMS both TelephonyPlugin and NotificationsPlugin are triggered. Both display a notification and offer replying (Replying in NotificationsPlugin probably depends on the SMS app, it works with com.google.android.apps.messaging)

Here are some thoughts on this:

Both plugins have their pros and cons:

TelephonyPlugin:

  • Needs Permission for SMS
  • Replying works all the time
  • Notifications are separated from our other notifications
  • Notifications are sticky (shown in notifications plasmoid)
  • Notification icon is not shown in plasmoid

NotificationsPlugin:

  • Needs Permission for Notifications
  • Replying only works for some apps
  • Notifications are shown in our plasmoid (with icons)
  • Notifications are automatically removed when removed on the phone

To conclude, NotificationsPlugin does a far better Job except for replying.

My suggestion would be:

  • Remove SMS handling from Telephony plugin
  • Add missing reply functionality to Notificationsplugin: Check incoming notifications with a list of common SMS Apps, add replying functionality if not already present

What do you guys think about this?

Wouldn't it be better if the NotificationsPlugin checked whenever TelephonyPlugin is enabled, and if so, had an additional blacklist for telephony packages (so that it wouldn't handle notifications from those)? Replying via notifications does depend on the SMS app, and many default manufacturer apps still don't support that. The blacklist code is already there, this would include having an additional check in NotificationsPlugin.onCreate to add elements from that additional blacklist into the AppDatabase.disabledByDefault list.

My initial idea was to kill the notifications from the telephony plugin, but it's true that there are some cons on doing so. Is there a better way not to have duplicate notifications, though? There is already a blacklist of SMS apps on the notifications plugin, but it has only two apps as of now :P And this approach will never be perfect because it is impossible to blacklist every single SMS app.

Would it be possible to extend this blacklist at runtime?
For example the telephony plugin might be able to determine wich apps received SMS messages. Those apps could be added to the blacklist for the notifications plugin.

Replying to all SMS from NotiPlugin will be difficult because there is no easy way to get the phone number to reply to.
How about this:
We blacklist the most popular SMS apps in notifications (maybe eventually extend the list at runtime). If users use an exotic SMS app they can blacklist it themself in the settings. When receiving a SMS the telephony plugin triggers the notification plugin on the desktop side. This way the notification behaves like all others on the desktop but still is always replieable. This would introduce some coupleling between these two plugins, but I think it wouldn't be too bad.

When receiving a SMS the telephony plugin triggers the notification plugin on the desktop side.

We should probably make sure that this does not happen when telepathy can be used to reply to the SMS

I don't know much about telepathy. Can we figure out whether it is used at runtime and what should we do different if it is used?

It's already handled correctly in telephonyplugin.cpp, line 49.
Just wanted to mention this, so it won't get broken.

When receiving a SMS the telephony plugin triggers the notification plugin on the desktop side. This way the notification behaves like all others on the desktop but still is always replieable. This would introduce some coupleling between these two plugins, but I think it wouldn't be too bad.

How does that solve the two notifications problem?

Like this:

We blacklist the most popular SMS apps in notifications (maybe eventually extend the list at runtime). If users use an exotic SMS app they can blacklist it themself in the settings.

This won't be perfect of course, but it will catch most of the double notifications. When we kill SMS in telephony plugin entirely we lose the ability to reply to all SMS messages. IMHO this would be worse than having double notifications on some apps. Of course I would prefer implementing generic replying to all SMS in NotificationsPlugin, but I don't see an easy way to do so. I'm open for any suggestions on this.

I might be late to this discussion, but I thought I'd weigh in since I've found a workable solution on the client-side for my gnome-shell extension.

  • Since the Telephony event always precedes the Notification, I check in the Telephony plugin if the Notifications plugin is active.
  • If it is I add a match string such as contactName/phoneNumber: messageBody or Missed call: contactName/phoneNumber to a list in the Notifications plugin.
  • Then if a notification with a matching title: text is received, I associate the packet->body->id with the match string, but don't post a notification locally (silence basically).
  • If a Telephony event is acknowledged or answered the Telephony plugin asks the Notification plugin to send a "close" packet for any duplicate that matches the string.

There's a number of benefits to doing it this way:

  1. I get to keep the granularity of the Telephony events
  2. don't have to keep a blacklist of application names that might get localised remotely
  3. the Telephony events are "transient" but the Notifications aren't, so just like Android if the laptop/desktop is restarted without the event being acknowledged the notification will still be there
  4. duplicated missedCall events are handled as well

The only catches are the phrase "Missed call" must be translated to match Android's string and to make the Notification "actionable" requires either caching the incoming phoneNumber/contactName or integrating desktop contacts (ie GData/libfolks).

sredman reopened this task as Open.Jun 9 2018, 7:55 PM
sredman added a subscriber: sredman.

In the interest of backwards-compatibility, this has not actually been resolved yet. Hopefully we will find a better way to do it as part of our refactoring of SMS code

nicolasfella closed this task as Resolved.Sep 16 2018, 10:11 PM
nicolasfella claimed this task.