-
Notifications
You must be signed in to change notification settings - Fork 23
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
Conversation
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 few nits but overall I think this goes into the right direction.
@@ -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 { |
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.
Does this work? My limited flutter knowledge says you'd need
void main() async { | |
Future<void> main() async { |
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.
Also, can the main be async?
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.
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
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.
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? |
4f4f527
to
3723463
Compare
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. |
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.
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"), |
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 that's the rollover
notification?
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 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?
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.
LGTM
Oh, I see. I'm not sure whether this can be achieved, because they're constraints are different.
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. 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.
3723463
to
60c9ee4
Compare
Move it into a separate module instead of polluting main.dart
These functions didn't really fit into `order` module.
60c9ee4
to
aaceaee
Compare
Next step would be actually using this new NotificationService to send notifications.