Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add plumbing for sending push notifications #1227

Merged
merged 7 commits into from
Sep 13, 2023

Conversation

klochowicz
Copy link
Contributor

  • store the FCM tokens sent from the app in the coordinator
  • add a notification service that sends push notifications to users (provide a sender as a means to send messages from different parts of the system).

Next step would be actually using this new NotificationService to send notifications.

Copy link
Contributor

@bonomat bonomat left a comment

Choose a reason for hiding this comment

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

A few nits but overall I think this goes into the right direction.

coordinator/Cargo.toml Show resolved Hide resolved
coordinator/src/notification_service.rs Outdated Show resolved Hide resolved
coordinator/src/notification_service.rs Outdated Show resolved Hide resolved
coordinator/src/notification_service.rs Outdated Show resolved Hide resolved
coordinator/src/notification_service.rs Outdated Show resolved Hide resolved
coordinator/src/notification_service.rs Show resolved Hide resolved
@@ -63,12 +63,22 @@ import 'features/stable/stable_value_change_notifier.dart';
final GlobalKey<NavigatorState> _rootNavigatorKey = GlobalKey<NavigatorState>(debugLabel: 'root');
final GlobalKey<NavigatorState> _shellNavigatorKey = GlobalKey<NavigatorState>(debugLabel: 'shell');

void main() {
void main() async {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this work? My limited flutter knowledge says you'd need

Suggested change
void main() async {
Future<void> main() async {

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, can the main be async?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, it works and all the examples in the official Dart documentation show it like this:

https://dart.dev/codelabs/async-await#working-with-futures-async-and-await

mobile/pubspec.lock Outdated Show resolved Hide resolved
coordinator/src/db/user.rs Show resolved Hide resolved
mobile/lib/main.dart Outdated Show resolved Hide resolved
Copy link
Contributor

@holzeis holzeis left a comment

Choose a reason for hiding this comment

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

It would be nice if we could combine the notifications logic for the websocket with the push notifications into a dedicated module.

coordinator/src/routes.rs Show resolved Hide resolved
mobile/lib/main.dart Outdated Show resolved Hide resolved
mobile/native/src/api.rs Outdated Show resolved Hide resolved
@klochowicz
Copy link
Contributor Author

It would be nice if we could combine the notifications logic for the websocket with the push notifications into a dedicated module.

I'm afraid I don't follow you. would you mind to elaborate?

@klochowicz klochowicz force-pushed the feat/store-fcm-tokens-in-coordinator branch 4 times, most recently from 4f4f527 to 3723463 Compare September 13, 2023 06:57
@holzeis
Copy link
Contributor

holzeis commented Sep 13, 2023

It would be nice if we could combine the notifications logic for the websocket with the push notifications into a dedicated module.

I'm afraid I don't follow you. would you mind to elaborate?

No need to action in this PR, but we currently have an api for notifying the user using the websocket and I guess now we get a second for notifying via push notification. It would be nice if we could have a single api to notify the user, e.g. with a combination try first websocket if not possible notify on push notification.

Copy link
Contributor

@holzeis holzeis left a comment

Choose a reason for hiding this comment

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

Let's give it a go if it works 👍

fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
match self {
NotificationKind::ChannelClose => write!(f, "ChannelClose"),
NotificationKind::PositionSoonToExpire => write!(f, "PositionSoonToExpire"),
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 that's the rollover notification?

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 thought about it for a while, but the it's before rollover, and the user can decide whether to rollover or not.
I wonder whether we should also allow notifications after a successful rollover etc?

Copy link
Contributor

@bonomat bonomat left a comment

Choose a reason for hiding this comment

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

LGTM

@klochowicz
Copy link
Contributor Author

It would be nice if we could combine the notifications logic for the websocket with the push notifications into a dedicated module.

I'm afraid I don't follow you. would you mind to elaborate?

No need to action in this PR, but we currently have an api for notifying the user using the websocket and I guess now we get a second for notifying via push notification. It would be nice if we could have a single api to notify the user, e.g. with a combination try first websocket if not possible notify on push notification.

Oh, I see. I'm not sure whether this can be achieved, because they're constraints are different.

  1. Websocket stream is current info to online & authenticated users.
  2. Push notifications is information for users that are can be offline.

It seems that it's easy to draw the line between the content of this information, e.g. there's no reason to send the same info on both channels.
I imagine that the push notification subsystem can be achieved by having their own tokio tasks that monitor for things, blissfully unaware that there is such a thing as websocket stream from the orderbook (and therefore having loose coupling).

Another thing that IMHO makes them logically separate is that the websocket stream comes from orderbook, whereas the push notifications are sent from the coordinator (our LSP).

It seems to be not always triggered.
also:
- Add FCM package,
- Ensure that firebase code is always run
Sometimes the app  would panic at startup (for local deployments for me), and I
    figured it was trivial to make it more resilient in this case.

We now log an error if for whatever reason we couldn't display the node id at
    startup (e.g. node wasn't ready) - this is not a critical bug, and it gets
    logged at later stage anyway.
We need to store FCM tokens to be able to notify the users about important
    events, e.g. when LSP wants to close a channel, or when their position with
    the coordinator is about to expire.
@klochowicz klochowicz force-pushed the feat/store-fcm-tokens-in-coordinator branch from 3723463 to 60c9ee4 Compare September 13, 2023 21:25
Move it into a separate module instead of polluting main.dart
These functions didn't really fit into `order` module.
@klochowicz klochowicz force-pushed the feat/store-fcm-tokens-in-coordinator branch from 60c9ee4 to aaceaee Compare September 13, 2023 21:27
@klochowicz klochowicz added this pull request to the merge queue Sep 13, 2023
Merged via the queue into main with commit e9827cd Sep 13, 2023
7 checks passed
@klochowicz klochowicz deleted the feat/store-fcm-tokens-in-coordinator branch September 13, 2023 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Store user's FCM tokens, correlated with pubkeys
3 participants