-
Notifications
You must be signed in to change notification settings - Fork 22
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
Allow robot created notifications #48
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.
I like this idea, however I'm wondering where it would be better to have users use the network alerts vs the notifications
There should also be some way of unit testing this, the PR for restructuring the NT dependency makes testing it much easier, so it might make more sense to add unit tests for notifications after the rework is complete
lib/pages/dashboard_page.dart
Outdated
var notifications = ntConnection.subscribe("notifications"); | ||
|
||
//dont display a notification when we first connect | ||
bool notificationFirstRun = true; | ||
notifications.listen((p0, p1) { | ||
List<String> data = p0.toString().replaceAll("[", "").replaceAll("]", "").split(","); | ||
if(notificationFirstRun) { | ||
notificationFirstRun = false; | ||
return; | ||
} | ||
Icon icon; | ||
if(data[0] == "INFO") { | ||
icon = const Icon(Icons.info); | ||
} | ||
else if(data[0] == "WARNING") { | ||
icon = const Icon(Icons.warning_amber, color: Colors.orange,); | ||
} | ||
else if(data[0] == "ERROR") { | ||
icon = const Icon(Icons.error, color: Colors.red,); | ||
} | ||
else { | ||
icon = const Icon(Icons.question_mark); | ||
} | ||
|
||
String title = data[1]; | ||
String description = data[2]; | ||
setState(() { | ||
ColorScheme colorScheme = Theme.of(context).colorScheme; | ||
TextTheme textTheme = Theme.of(context).textTheme; | ||
ElegantNotification notification = ElegantNotification( | ||
autoDismiss: true, | ||
showProgressIndicator: true, | ||
background: colorScheme.surface, | ||
width: 350, | ||
position: Alignment.bottomRight, | ||
title: Text( | ||
title, | ||
style: textTheme.bodyMedium!.copyWith( | ||
fontWeight: FontWeight.bold, | ||
), | ||
), | ||
icon: icon, | ||
description: Text(description), | ||
stackedOptions: StackedOptions( | ||
key: 'notification', | ||
type: StackedType.above, | ||
itemOffset: const Offset(0, 5), | ||
), | ||
); | ||
if (mounted) { | ||
notification.show(context); | ||
} | ||
}); | ||
}); |
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 think the listening logic would belong better in a separate class that you pass a function into which is called when a new notification is published. The main reason is because it could eventually cause the method to become a bit cluttered.
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.
Would a robot alert service similar be a good way of going about this?
elasticlib/Elastic.java
Outdated
import edu.wpi.first.networktables.StringArrayTopic; | ||
|
||
public final class Elastic { | ||
private static final StringArrayTopic topic = NetworkTableInstance.getDefault().getStringArrayTopic("notifications"); |
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.
Maybe change the topic to something like "elastic/notifications" in case if there's ever some library that also publishes to a topic called notifications?
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.
Thinking of renaming it to "elastic/alerts" since I think that would make more sense.
Robot alerts vs Elastic Notifications. Maybe an icon on the notification can differentiate the two? Also renaming everywhere to alerts would probably make more sense.
elasticlib/Elastic.java
Outdated
public static void sendAlert(AlertLevel level, String title, String description) { | ||
publisher.set(new String[] {level.toString(), title, description}); | ||
} |
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 think it would be easier to maintain long term if it used a different format that's easier to expand on. Maybe there could be a way of publishing some sort of json map that can have different properties if we want to add more customization later on
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 think a json map would be the way to go here.
Hey thanks for looking at this.
Unit testing is something that I haven't done before (😓), but my summer break starts today, so I will take a look at how to do this and will put in later. |
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.
So far this is looking really good, I think this would be a great addition to the dashboard. Some things that would have to be added (such as unit tests) aren't very easy to do in the main branch, so some parts would have to be added in the NT connection rework branch after this is merged
addresses name conflicts with wpilibs stuff in 2025
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #48 +/- ##
==========================================
- Coverage 45.53% 45.45% -0.08%
==========================================
Files 73 74 +1
Lines 7465 7489 +24
==========================================
+ Hits 3399 3404 +5
- Misses 4066 4085 +19 ☔ View full report in Codecov by Sentry. |
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.
Looks great, I'll have to merge these changes into the rework branch and there might be some slight modifications to work better with the new NT api, but this is ready to put into main
color: Colors.red, | ||
); | ||
} else { | ||
icon = const Icon(Icons.question_mark); |
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.
Love this
@EmeraldWither quick question, what's the reason for having it send all if it ignores the notification on initial connection? Also, I merged all of these changes into the This is definitely a great addition, thanks for making this! |
On the initial connection, when I start listening, it will always call the method with whatever is currently inside the topic, even if it's old/stale data (eg, rebooting elastic will cause the notification so show again even though we haven't actually posted anything). By ignoring the first time that this happens, this allows us to only receive the new data. |
2024-06-18.13-15-08.mp4
Robot code usage:
There are 3 levels of notifications:
INFO:
WARNING:
ERROR:
The idea is that the driver can get a notification when something happens (eg. an arm extends too far and gets disabled).
Users can copy the Elastic class into their robot project, and use those methods to push notifications to the dashboard.