It appears Mixpanel is potentially overwriting what the application may have already set for isIdleTimerDisabled and abusing that API to keep the websocket alive longer. This ends up disabling the idle timer and dimming the screen when your websocket disconnects so our app doesn't stay active when we explicitly need it to based upon high level UX needs.
It feels a bit hacky to be using the idle timer in this way to begin with since that should ideally only be controlled by the app UX needs. Mixpanel overwriting that at a very low level to keep the network layer alive longer feels very wrong and we definitely don't want Mixpanel disabling the idle timer when your websocket disconnects for whatever reason.
I'm considering forking to remove that code, but want to understand the implications first (e.g. do you all really need that versus using background expiration time?)
Thanks in advance for your help; this has caused a lot of debugging pain so just trying to get it cleared up quickly!
Hi there 👋
It appears Mixpanel is potentially overwriting what the application may have already set for
isIdleTimerDisabled
and abusing that API to keep the websocket alive longer. This ends up disabling the idle timer and dimming the screen when your websocket disconnects so our app doesn't stay active when we explicitly need it to based upon high level UX needs.It feels a bit hacky to be using the idle timer in this way to begin with since that should ideally only be controlled by the app UX needs. Mixpanel overwriting that at a very low level to keep the network layer alive longer feels very wrong and we definitely don't want Mixpanel disabling the idle timer when your websocket disconnects for whatever reason.
I'm considering forking to remove that code, but want to understand the implications first (e.g. do you all really need that versus using background expiration time?)
Thanks in advance for your help; this has caused a lot of debugging pain so just trying to get it cleared up quickly!