-
Notifications
You must be signed in to change notification settings - Fork 9
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
Track plugin statuses and send status #267
Comments
Did you have a particular notion on the status payload content? |
Something like
would that do it, or would something more/different be needed? |
Looks good. I guess the two main questions this helps answer are is there a problem in the pipeline from device-->pRMT-->server. In the device-->pRMT we will have the various status values and in the second case pRMT-->server we have last success. The only other thing I can think of is if there is some plugin specific "error" e.g. device reports some problem like incorrectly worn or sensor fail. Though perhaps this type of generalisation is out of scope here. maybe also cc/ @sboettcher |
partially related RADAR-base/radar-prmt-android#106 |
Ok good point. Third topic
Could also work, with a central logging component similar to the component storing plugin statuses. This partially duplicates the crashlytics database we already have though, which provides much more detail, like surrounding logs and stack trace. |
Agree with all of this. I suppose one thing to keep in mind, if the connection to the server cannot be established for some reason, then we won't get this info. But then the problem is not related to the plugins of course. Is there a way already built-in to track any notifications (e.g. disconnect) sent by the app/plugins, possibly via firebase? Or are these not related? Unfortunately, I probably won't be able to seriously contribute code to this in the future. But I will definitely be available for testing. |
Yes tracking notifications could be another metric. There’s already a centralized notification manager that could track this. |
Request: have a means to diagnose what the status of each plugin is.
Add a provider as part of the application plugin that will track:
It would need a central component part of the RadarApplication that keeps this information in memory for a limited amount of time and add an offset to each message to avoid duplicate messages. There could be a pull and a push mechanism, so when the plugin starts up it can query the status history, and after that the central component will forward data to a listener.
The text was updated successfully, but these errors were encountered: