Open wir3z opened 1 month ago
Can you take a look to see if this is an acceptable direction for the PR?
Still outstanding:
I think we clearly stated #1618 this enhancement should not be done in the location
message but by implementing a new status
message
Thanks for the PR!
i agree with @ckrey here - if there's device-specific, largely static status information, let's have that in a new message type published on an /info
topic. Otherwise we're just bloating the location message with data that largely doesn't change from location to location.
No problem! I'll get that refactored into a different message structure.
Any options on using true/false vs 1/0? Thoughts on 1/0 is the end consumer could sum those results. If it was non-zero then it was not optimal (using the Windows error code type mentality here...)
Migrated to the status command and response as request. I still need to figure out the unit tests for it, but a couple questions:
1) The schema was presented as this:
`{
"_type": "status",
... generic attributes (if any)
"android": { "wifi": true/false, "ps": true/false, "bo": true/false, "hib": true/false, "loc": "app location permissions" }` Is there a need to nest that as "android" or "ios" if that is already known from the request headers? 2) If this status message is to fire on a change, where would you like that to be checked? On each location message generation? Or just keep it as an on-demand command?
if that is already known from the request headers
by which I assume you mean HTTP request headers. If so, please keep in mind that MQTT doesn't have those, so I'd be in favor of making clear from this payload that it's Android/iOS. Nesting isn't necessary; an attribute with the OS would suffice IMO.
like described here: https://github.com/owntracks/android/issues/1618#issuecomment-1951394338
like described here
If iOS is spelled iOS
, then Android should be spelled Android
, whereby I would use lowercase only on both.
if that is already known from the request headers
by which I assume you mean HTTP request headers. If so, please keep in mind that MQTT doesn't have those, so I'd be in favor of making clear from this payload that it's Android/iOS. Nesting isn't necessary; an attribute with the OS would suffice IMO.
Good point! I'll get that added and pushed up.
Do you have guidance on what the proper formatting of the files should be? It's failing that portion of the build, but unsure what it is unhappy about.
I updated the changelog + added in the MQTT unit tests. Let me know if there is anything else I'm missing. Let me know if the ktfmt failure is on my side, or part of the build process.
Added in the status to be sent with a user trigger location to match iOS #778. This PR is ready for review now.
Is the ktfmt failures due to formatting in the files I touched or a PR cannot process that? Thanks!
Ok, figured out the ktfmt secret sauce. :) Cleanup is done and ready for submission.
Added additional return fields to the JSON packet to indicate if the user's mobile device settings are currently in a state that negatively impacts location performance.