It would be nice to see other information reported in the Debugger that is defined by the end-user. Examples would be Analytics events, HTTP calls, or SQL queries. This would bring more information to one single place that would be very useful in local development. And if I could create a standalone Desktop Application or Browser Extension for the debugger, would even be useful for QA/UAT engineers to verify things like analytics are being tracked properly.
This would add a feature where one could register some generic "logging" interface anywhere in their code that also connects to the Debugger. These logging events aren't necessarily part of a ViewModel, but instead would go directly to the Connection and be sent to the DebuggerUI, showing up as an extra panel in the connection view. A basic DSL would allow one to specify properties such as the title and description (shown as list items in the UI) and a map of extra properties. It should also allow one to create IDs for these events and update the status of a single event over time (for example, logging an HTTP call before it's made, then setting the response status code and body after the call finishes).
There should be out-of-the-box adapters available for Okhttp and Ktor HTTP clients, Ballast Analytics, and Sqldelight. End-users would be free to create their own reporters for anything else they would like to track as well.
It would be nice to see other information reported in the Debugger that is defined by the end-user. Examples would be Analytics events, HTTP calls, or SQL queries. This would bring more information to one single place that would be very useful in local development. And if I could create a standalone Desktop Application or Browser Extension for the debugger, would even be useful for QA/UAT engineers to verify things like analytics are being tracked properly.
This would add a feature where one could register some generic "logging" interface anywhere in their code that also connects to the Debugger. These logging events aren't necessarily part of a ViewModel, but instead would go directly to the Connection and be sent to the DebuggerUI, showing up as an extra panel in the connection view. A basic DSL would allow one to specify properties such as the title and description (shown as list items in the UI) and a map of extra properties. It should also allow one to create IDs for these events and update the status of a single event over time (for example, logging an HTTP call before it's made, then setting the response status code and body after the call finishes).
There should be out-of-the-box adapters available for Okhttp and Ktor HTTP clients, Ballast Analytics, and Sqldelight. End-users would be free to create their own reporters for anything else they would like to track as well.