1759893 - Simpler api for informing GV about web notification click / dismiss

Status: RESOLVED FIXED

(GeckoView :: General, enhancement, P1)

Description

[Petru-Mugurel Lingurar [:petru]]

Based on the discussions from https://github.com/mozilla-mobile/android-components/issues/7477

I see the web notifications needing to work even if the user closes the application in the meantime (and removes it from task manager).

Looking at what happens when a notification is clicked / dismissed it looks like only two strings are needed to identify the notification with which the user interacted [1].
But to be able to call the current methods we'd need to go through the WebNotification class.

I'm proposing a simpler approach for notifications, something along the lines of "post and forget":

• WebNotificationDelegate.onShowNotification will function the same - sends to integrators a WebNotification with all details based on which native notification to be created and shown
• [NEW] Integrators will add as intent extras to the native notification WebNotifications tag and cookie properties.
  For this GeckoView first needs to expose mCookie.
• Users can click / dismiss the native notification. A PendingIntent will inform the app about these events.
• [NEW] The receiving component will read the tag and cookie extras from the native notification's intent.
• [NEW] The receiving component needs a simpler API to pass these details to GeckoAppShell.onNotificationClick(tag, mCookie).
  Jonathan proposed

geckoRuntime.webNotificationController.dismissNotification(tag, cookie)

 
By using this approach neither do apps, neither do GeckoView need to keep a reference to WebNotifications. The apps can can even be killed and everything will still work as expected when users click or dismiss a certain web notification.

---

[1] https://searchfox.org/mozilla-central/rev/fa69d8b248e6c1df670aa6b019e30ec37e6672be/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/WebNotification.java#146-159

Comment 1

[[ex-Mozilla] Agi Sferro | :agi]

I responded on Slack but, I would rather offer a way to serialize the WebNotification object to a string so that it can be re-created at a later date, would that work for you? I would rather not expose internals of the notification.

Comment 2

[Petru-Mugurel Lingurar [:petru]]

(In reply to Agi Sferro | :agi | [slow ni? rn sorry] | ⏰ PST | he/him from comment #1)

I responded on Slack but, I would rather offer a way to serialize the WebNotification object to a string so that it can be re-created at a later date, would that work for you? I would rather not expose internals of the notification.

With the intended usage of still "persisting" this through a native notification extra?
This would work great! - still a simple, straightforward usage for us.
Going by the properties of the WebNotification the only thing that would worry me is the imageUrl - which could be a a big data url? So maybe this field can be left out when serializing the notification?

Comment 3

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: Bug 1759893 - Implement Parcelable for WebNotification.

Apps want to persist a WebNotification so that they can respond to taps on it
when the app is not alive anymore.

To achive this, we make WebNotification serializable through Parcel so that the
app can store it somewhere.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3d305df975f3
Implement Parcelable for WebNotification. r=jonalmeida

Comment 5

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/3d305df975f3