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
I still occasionally see log messages like "Sending 1 signals leaving a cache of 0 signals”. It looks like this config option does avoid sending any signals when I call TelemetryDeck.signal(…). However, signals from TelemetryDeck.errorOccurred(…) and the internal TelemetryDeck.Session.started signal are still sent and show up on TelemetryDeck’s Recent Signals page.
My use case is that I have a toggle in my settings screen for users to opt out of analytics. Initializing TelemetryDeck with Config.analyticsDisabled seemed like an appropriate way to honor this without having to add a check everywhere that I send a signal.
Workaround
As an easy workaround, I just made a wrapper around TelemetryDeck that avoids calling TelemetryDeck.initialize(), .signal(…) or .errorOccurred(…) if it should be disabled.
The text was updated successfully, but these errors were encountered:
@daprice Thank you for reporting this! I'm sorry for introducing this issue, it's an oversight in some internal restructuring. But I just fixed it in #211 which should be merged and released in the next version soon!
If, in a SwiftUI lifecycle app, I add the following in the
init()
of theApp
…I still occasionally see log messages like "Sending 1 signals leaving a cache of 0 signals”. It looks like this config option does avoid sending any signals when I call
TelemetryDeck.signal(…)
. However, signals fromTelemetryDeck.errorOccurred(…)
and the internalTelemetryDeck.Session.started
signal are still sent and show up on TelemetryDeck’s Recent Signals page.My use case is that I have a toggle in my settings screen for users to opt out of analytics. Initializing TelemetryDeck with
Config.analyticsDisabled
seemed like an appropriate way to honor this without having to add a check everywhere that I send a signal.Workaround
As an easy workaround, I just made a wrapper around TelemetryDeck that avoids calling
TelemetryDeck.initialize()
,.signal(…)
or.errorOccurred(…)
if it should be disabled.The text was updated successfully, but these errors were encountered: