Skip to content
This repository has been archived by the owner on Feb 20, 2023. It is now read-only.

EXP 2991: Add surface to messaging fml #28423

Merged
merged 14 commits into from
Jan 17, 2023

Conversation

jhugman
Copy link
Contributor

@jhugman jhugman commented Jan 5, 2023

This adds a surface parameter to the getMessages() method in NimbusMessagingStorage.

It also takes the opportunity to refactor the messaging feature in the nimbus.fml.yaml into a separate messaging.fml.yaml.

Pull Request checklist

  • Tests: This PR includes thorough tests or an explanation of why it does not
  • Screenshots: This PR includes screenshots or GIFs of the changes made or an explanation of why it does not
  • Accessibility: The code in this PR follows accessibility best practices or does not include any user facing features. In addition, it includes a screenshot of a successful accessibility scan to ensure no new defects are added to the product.

QA

  • QA Needed

To download an APK when reviewing a PR (after all CI tasks finished running):

  1. Click on Checks at the top of the PR page.
  2. Click on the firefoxci-taskcluster group on the left to expand all tasks.
  3. Click on the build-debug task.
  4. Click on View task in Taskcluster in the new DETAILS section.
  5. The APK links should be on the right side of the screen, named for each CPU architecture.

GitHub Automation

Used by GitHub Actions.

@jhugman jhugman requested review from a team as code owners January 5, 2023 21:21
@jhugman jhugman marked this pull request as draft January 5, 2023 21:22
@t-p-white t-p-white self-assigned this Jan 6, 2023
notification-config:
polling-interval: 180 # 3 minutes

objects:
Copy link
Contributor

@t-p-white t-p-white Jan 6, 2023

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?

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, thanks 👍

@jhugman jhugman force-pushed the jhugman/exp-2991-add-surface-to-messaging-fml branch 2 times, most recently from 6149e95 to 50a37d6 Compare January 6, 2023 16:38
@jhugman jhugman marked this pull request as ready for review January 6, 2023 16:39
@jhugman jhugman requested a review from t-p-white January 6, 2023 19:58
Comment on lines 211 to 212
MessagingMiddleware(
surface = MessageSurfaceId.HOMESCREEN,
messagingStorage = analytics.messagingStorage,
),
Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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 MessagingMiddlewarewould 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.

Copy link
Contributor

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 :) .

@jhugman jhugman force-pushed the jhugman/exp-2991-add-surface-to-messaging-fml branch 2 times, most recently from 6074e23 to a5c4f82 Compare January 10, 2023 14:03
@@ -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()
Copy link
Contributor

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))
Copy link
Contributor

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")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: maybe message1 😅

Copy link
Contributor

@Amejia481 Amejia481 left a 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.

@Amejia481 Amejia481 added the 🙅 waiting Issues that are blocked or has dependencies that are not ready label Jan 10, 2023
@jhugman jhugman force-pushed the jhugman/exp-2991-add-surface-to-messaging-fml branch 2 times, most recently from 81ded56 to e1cc1cd Compare January 11, 2023 18:15
@Amejia481
Copy link
Contributor

Let's wait until we cut the new release Monday the 16th to have full cycle to bake on nightly.

@jhugman jhugman force-pushed the jhugman/exp-2991-add-surface-to-messaging-fml branch from e1cc1cd to 5b64739 Compare January 17, 2023 11:03
@jhugman jhugman added pr:needs-landing-squashed PRs that are ready to land (squashed) [Will be merged by Mergify] and removed 🙅 waiting Issues that are blocked or has dependencies that are not ready labels Jan 17, 2023
@jhugman
Copy link
Contributor Author

jhugman commented Jan 17, 2023

Removed waiting label following merge.

Copy link
Contributor

@Amejia481 Amejia481 left a 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 🛩️ !

@mergify
Copy link
Contributor

mergify bot commented Jan 17, 2023

This pull request has conflicts when rebasing. Could you fix it @jhugman? 🙏

@jhugman jhugman force-pushed the jhugman/exp-2991-add-surface-to-messaging-fml branch from 5b64739 to 038eb98 Compare January 17, 2023 12:08
@jhugman jhugman force-pushed the jhugman/exp-2991-add-surface-to-messaging-fml branch from 038eb98 to eb33711 Compare January 17, 2023 13:44
@mergify mergify bot merged commit c332f1b into main Jan 17, 2023
@bors bors bot deleted the jhugman/exp-2991-add-surface-to-messaging-fml branch January 17, 2023 15:21
t-p-white pushed a commit to t-p-white/fenix that referenced this pull request Jan 17, 2023
* 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>
JohanLorenzo pushed a commit to mozilla-releng/staging-firefox-android that referenced this pull request Jan 25, 2023
…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>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
pr:needs-landing-squashed PRs that are ready to land (squashed) [Will be merged by Mergify]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants