Skip to content

Support progress styling keys on Android - #317

Open
inukiwi wants to merge 5 commits into
home-assistant:mainfrom
inukiwi:feature/android_progress_styling
Open

Support progress styling keys on Android#317
inukiwi wants to merge 5 commits into
home-assistant:mainfrom
inukiwi:feature/android_progress_styling

Conversation

@inukiwi

@inukiwi inukiwi commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

This PR contains two parts:

  • Addition of keys for progress style notifications
  • Serialization of objects to prevent the value from becoming "[Object object]" when converting to string

Copilot AI review requested due to automatic review settings June 17, 2026 15:21

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Expands supported Android notification payload keys and improves how FCM data payload values are serialized to meet FCM’s “strings only” requirement.

Changes:

  • Added additional progress_* keys to androidNotificationKeys.
  • Updated payload construction to JSON-stringify object values while stringifying primitives.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread functions/android.js
Comment on lines +128 to +134
// 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]);
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Did you consider this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The 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.
I'll update handlers.js to include some error handling and returning it to Home Assistant

Comment thread functions/android.js
Comment on lines +116 to +123
'progress_segments',
'progress_points',
'progress_start_icon',
'progress_end_icon',
'progress_tracker_icon',
'progress_start_color',
'progress_end_color',
'progress_tracker_color',

Copy link
Copy Markdown
Member

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.

Copy link
Copy Markdown
Member

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.

Copy link
Copy Markdown
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants