-
-
Notifications
You must be signed in to change notification settings - Fork 47
Support progress styling keys on Android #317
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
base: main
Are you sure you want to change the base?
Changes from all commits
24592ac
80d0d44
850ae95
4428a07
b8496ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -113,11 +113,25 @@ module.exports = { | |
| 'progress_indeterminate', | ||
| 'live_update', | ||
| 'critical_text', | ||
| 'progress_segments', | ||
| 'progress_points', | ||
| 'progress_start_icon', | ||
| 'progress_end_icon', | ||
| 'progress_tracker_icon', | ||
| 'progress_start_color', | ||
| 'progress_end_color', | ||
| 'progress_tracker_color', | ||
| ]; | ||
|
|
||
| androidNotificationKeys.forEach((key) => { | ||
| if (Object.hasOwn(req.body.data, key)) { | ||
| payload.data[key] = String(req.body.data[key]); | ||
| // If the value is an object, stringify it. Convert everything else to a string. | ||
| // This is because FCM data payloads must be strings. | ||
| if (typeof req.body.data[key] === 'object') { | ||
| payload.data[key] = JSON.stringify(req.body.data[key]); | ||
| } else { | ||
| payload.data[key] = String(req.body.data[key]); | ||
| } | ||
|
Comment on lines
+128
to
+134
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did you consider this?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the preferred approach would be option a, since option b would just silently fail with no means to debug. |
||
| } | ||
| }); | ||
| } | ||
|
|
||
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 would like this to be verify with @bgoncal to see if iOS can use them like this or if it's specific to Android.
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 you worried about the data structure or the keys themselves?
iOS will have to map them in the file (currently called) legacy.js anyways so, as long it comes from the user's yaml payload iOS can deal with it.
If the question is regard if iOS can use these keys to create the UI, yes it can, in iOS the live activity is kinda white board, we can draw anything (non-animated) in there, but I havent reviewed the way this is being designed for the user to use, I mean.. is there a more clever way? But then it's better to read the docs to see if it is intuitive enough for the user.
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.
Then let's discuss in home-assistant/companion.home-assistant#1297 the idea is to validate the fields also for you if you can use them later.