You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In the past we were using a custom NavController.OnDestinationChangedListener which was doing mostly the same work as yours does, which was to log a startView to RUM, but at the same time we were also logging the navigation event to our normal logs, since very often as we are looking at some user's flow (by using the "View in context" feature in the logs), we want to be able to see the logs we write down, and in-between them also see the navigation events, to see when exactly each log was sent in relation to where in the app they are navigating to.
Describe the solution you'd like
One possible approach is that the ComposeNavigationObserver can take in an optional lambda with the signature ((destination, route, arguments) -> Unit)? = null where we can provide it with a custom lambda to run on each successful navigation event, and in this line that lambda can be called, and we can do whatever we want with it, in our case log to datadog.
With that said, if you can think of a more tight integration with datadog, meaning that instead of a generic lambda it can be something more specific to log to datadog then I could see that happening too, I would love to hear your thoughts on this.
Describe alternatives you've considered
What we must do at this moment to make this work is provide our own custom NavController.OnDestinationChangedListener again, either as a replacement to the one provided by datadog completely, so we'd drop using NavigationViewTrackingEffect. Or adding a custom one which only does what I described, so those two can live at the same time, but in reality then we'd be doing double the work by attaching two lifecycle listeners and two navigation listeners for no reason.
The text was updated successfully, but these errors were encountered:
Hello @StylianosGakis,
Just to be sure that I understand, you are using DD for logs? Could you please describe further the use case? Are you interested in logging to console in addition to sending to RUM, or are we talking about sending a log event to DD logs?
Hello Jonathan 👋
Yeah basically I would also like to log using Timber, which in our case logs to the local logcat in debug (Good for dev experience), but also to com.datadog.android.log.Logger in the production environment
@StylianosGakis We're adding this to our backlog, though it may take some time to get to it. If this is urgent, please feel free to submit a PR to the repo with the change - an optional lambda sounds like a reasonable solution here
Is your feature request related to a problem? Please describe.
In the past we were using a custom
NavController.OnDestinationChangedListener
which was doing mostly the same work as yours does, which was to log astartView
to RUM, but at the same time we were also logging the navigation event to our normal logs, since very often as we are looking at some user's flow (by using the "View in context" feature in the logs), we want to be able to see the logs we write down, and in-between them also see the navigation events, to see when exactly each log was sent in relation to where in the app they are navigating to.Describe the solution you'd like
One possible approach is that the
ComposeNavigationObserver
can take in an optional lambda with the signature((destination, route, arguments) -> Unit)? = null
where we can provide it with a custom lambda to run on each successful navigation event, and in this line that lambda can be called, and we can do whatever we want with it, in our case log to datadog.With that said, if you can think of a more tight integration with datadog, meaning that instead of a generic lambda it can be something more specific to log to datadog then I could see that happening too, I would love to hear your thoughts on this.
Describe alternatives you've considered
What we must do at this moment to make this work is provide our own custom
NavController.OnDestinationChangedListener
again, either as a replacement to the one provided by datadog completely, so we'd drop usingNavigationViewTrackingEffect
. Or adding a custom one which only does what I described, so those two can live at the same time, but in reality then we'd be doing double the work by attaching two lifecycle listeners and two navigation listeners for no reason.The text was updated successfully, but these errors were encountered: