-
Notifications
You must be signed in to change notification settings - Fork 1.3k
EXP 2991: Add surface to messaging fml #28423
Conversation
notification-config: | ||
polling-interval: 180 # 3 minutes | ||
|
||
objects: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
out of interest - the original file had objects:
in a types:
tag. What was that doing and is it no longer required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The types
tag turned out to be unnecessary cruft, and we quietly deprecated it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, thanks 👍
6149e95
to
50a37d6
Compare
MessagingMiddleware( | ||
surface = MessageSurfaceId.HOMESCREEN, | ||
messagingStorage = analytics.messagingStorage, | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused about how we are going to handle multiple surface, if we are just passing one to the middleware?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we just going to have one surface per app startup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused about how we are going to handle multiple surface
I'm not sure where the MessagingMiddleware
fits in: does it look after one surface, or should it be looking after all surfaces? If all surfaces, how does it fit in with a WorkManager job?
My thought here was that the Notification Worker would use a messaging storage directly.
Should the MessagingSurfaceId
travel in the Action/Facts rather than the middleware directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure where the MessagingMiddleware fits in: does it look after one surface, or should it be looking after all surfaces? If all surfaces, how does it fit in with a WorkManager job?
At the moment, it contains all the logic on handling when a message should be displayed or interacted with, ideally as all the logic practically should be the same for handling messages (Just the surface is different) we could have the middleware to take of all these actions for all surfaces and from other surfaces like the Notification Worker we could dispatch actions, indicating we would like to Evaluate
for a specific surface the same could be done in the home screen, just by adding the surface to the Evaluate
action.
It will be good to define if we will be able support sending multiple messages in multiple surfaces at the same time per app startup.
My thought here was that the Notification Worker would use a messaging storage directly.
We could use the storage directly but we may need to duplicate some of the logic that already live on the MessagingMiddleware
.
Should the MessagingSurfaceId travel in the Action/Facts rather than the middleware directly?
Yeah, having the surface as part of the actions could be ideal to keep the common logic in the middleware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From where are we going to get the MessageSurfaceId
? As if we get it directly from the message, we won't need to change much as the message could tell us where it should be shown, without a lot of changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From where are we going to get the MessageSurfaceId? As if we get it directly from the message,
Yes, this is correct.
We could use the storage directly but we may need to duplicate some of the logic that already live on the MessagingMiddleware.
Yes, that was my thought too. A judicious refactor of MessagingMiddleware
would be required, but definitely do-able.
It will be good to define if we will be able support sending multiple messages in multiple surfaces at the same time per app startup.
If I understand your question correctly: it's intended that multiple messages be sent to any surface; however, only one message per surface is displayed at any one time.
If there are two messages eligible for the same surface, the highest priority message is displayed. If it is clicked or dismissed by the user, or it becomes ineligible, the next highest priority message is displayed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, thanks for the clarification!
I think If we add the MessageSurfaceId
as part of the message
we will need to update fewer points, only the ones that are specific about where the message should be shown :) .
6074e23
to
a5c4f82
Compare
@@ -147,7 +148,7 @@ sealed class AppAction : Action { | |||
/** | |||
* Updates [MessagingState.messageToShow] with the given [message]. | |||
*/ | |||
object ConsumeMessageToShow : MessagingAction() | |||
data class ConsumeMessageToShow(val surface: MessageSurfaceId) : MessagingAction() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏽
|
||
/** | ||
* A message observer that updates the provided. | ||
*/ | ||
class MessagingFeature(val appStore: AppStore) : LifecycleAwareFeature { | ||
|
||
override fun start() { | ||
appStore.dispatch(MessagingAction.Evaluate) | ||
appStore.dispatch(MessagingAction.Evaluate(MessageSurfaceId.HOMESCREEN)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏🏽
), | ||
) | ||
|
||
val m = createMessage("message-1") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: maybe message1
😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general this looks good 👏🏽 !
Let's address the failing test. Please let's not land this PR until we cut the release branch for 110 very likely it will happen today.
81ded56
to
e1cc1cd
Compare
Let's wait until we cut the new release Monday the 16th to have full cycle to bake on nightly. |
e1cc1cd
to
5b64739
Compare
Removed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhugman awesome work 🏅 , lets land this 🛩️ !
This pull request has conflicts when rebasing. Could you fix it @jhugman? 🙏 |
5b64739
to
038eb98
Compare
038eb98
to
eb33711
Compare
* Move messaging fml to a separate file * Add surface property to message data * Get messages for just a single surface * Add surface to messaging middleware * ktlint * Add tests for filtering by surface * Add homescreen to default-browser message * Move surface param to MessageActions instead of MessagingMiddleware * Added computed property for surface to message * ktlint * Address reviewer comment * Fixup tests Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
…28423) * Move messaging fml to a separate file * Add surface property to message data * Get messages for just a single surface * Add surface to messaging middleware * ktlint * Add tests for filtering by surface * Add homescreen to default-browser message * Move surface param to MessageActions instead of MessagingMiddleware * Added computed property for surface to message * ktlint * Address reviewer comment * Fixup tests Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
This adds a
surface
parameter to thegetMessages()
method inNimbusMessagingStorage
.It also takes the opportunity to refactor the
messaging
feature in thenimbus.fml.yaml
into a separatemessaging.fml.yaml
.Pull Request checklist
QA
To download an APK when reviewing a PR (after all CI tasks finished running):
Checks
at the top of the PR page.firefoxci-taskcluster
group on the left to expand all tasks.build-debug
task.View task in Taskcluster
in the newDETAILS
section.GitHub Automation
Used by GitHub Actions.