0

I have been having a weird problem with the SDK, both on Android and iOs.

The problem is as goes: after using the sdk and going through transitions to the foreground/background sometimes the app I implemented received a message through the sdk, but was unable to decode the data.

Until that point all is ok, it just fails and we are able to track that. However sometimes, after being unable to decode the payload once, all further messages received produce a decoding error.

My solution on Android was to re-instantiate the client and it solved the issue there.

However on iOs, where the sdk seems more reliable(which means its harder to reproduce the bug) I couldn't find a way to force killing the client to re-instantiate it.

Just calling stop and then making the pointer to it null would be enough?

How do I force restart the client on iOs?

I couldn't find in the best practices a way to restart the client.

Arthur Sady Cordeiro Rossetti
  • 361
  • 4
  • 6
  • 1
    Did you follow the best practices for foreground/backgrounding from https://developers.chirp.io/docs/using-chirp/best-practices? You shouldn't need to restart. Please also make sure you are using the latest versions of the SDK. – joextodd Aug 05 '19 at 16:05
  • Yes, I followed the best practices document for starting and stoping the sdk and having it centralised. I really can't explain why the problem happens, I just know that on Android I was able to at least break the pattern of decoding errors by reseting the client. But I couldn't achieve the same thing on iOs. On iOs instead of resetting the Sdk, I tried stopping and starting again but that didn't work as I expected. – Arthur Sady Cordeiro Rossetti Aug 05 '19 at 16:18
  • Can you list the devices and OS versions that this is happening on? We can try reproduce the issue here. – joextodd Aug 20 '19 at 08:47
  • On iOs its been a long time since I was able to reproduce, but, on Android, on Samnsung S7 Android 8 if I try repeatedly to toggle between foreground and background it eventually happens, my solution for this has been to restart the sdk and it has been working well so far, but I could not identify what triggers it specifically. – Arthur Sady Cordeiro Rossetti Aug 30 '19 at 23:41

1 Answers1

1

This certainly should not be happening, however the fact you are getting the received callback triggered with a failure suggests that the audio i/o is not completely broken.

Although this is not recommended, to answer your question, once there are no more references to the SDK, i.e., the dealloc method is called, then the SDK is destroyed and memory is freed.

joextodd
  • 694
  • 4
  • 9