Revert "Fix a crash on Android"#15
Conversation
This is so we can set their timeout
This fixes the keep-alive issue for an unkown reason. There is an Apple Technical Support Request for this issue, follow up number 629273694
Return description in case of unknown type
Added a hopeful workaround to the crash from copying serviceData
This is unnecessary and may cause a crash in thread unsafe code
Code review change for a7678c3
Fixed service data crash due to unsafe threads
Conflicts: .gitignore
dragons3d iOS/Android merge
Fix a crash on Android
This reverts commit c179213.
|
We should actually just remove my change that caused this too, it's unneeded now. I'm pretty sure Aaron had a good reason for removing this from Android. |
|
If we remove your commit, the problem will still happen on android. So maybe we need to take the method of disabling subscription requests upon going to background. |
| #pragma mark - Internal | ||
| - (void)didEnterBackground { | ||
| [self.client.heartbeatManager stopHeartbeatIfPossible]; | ||
| [self stopRetryTimer]; |
There was a problem hiding this comment.
How does this start when the game reenters the foreground?
There was a problem hiding this comment.
I am not quite sure about how it works but when I set a breakpoint at startHeartbeat it get called when the game comes back. The stack trace shows this is triggered by some callback.
QA has verified the functionality works fine. Yeah I don't know if there is a better solution to this problem.
|
Why are we making this change? Is there a ticket? |
| #import "PNHelpers.h" | ||
|
|
||
| #ifdef PGDROID | ||
| #import <UIKit/UIKit.h> |
There was a problem hiding this comment.
XCode complains the UIApplication notification is not defined.
I checked in our code base and saw Orlando did something like this elsewhere.
|
If we are doing this to stop PubNub traffic in the background, then I think a safer, better, and cleaner solution would be to tear down the PubNub instance from inside |
|
yes ticket number is DRG-42245. The solution you mentioned would stop all the background pubnub traffic so I really have no idea if it would cause any other problems. Also performance might be another concern? Client would have to join channels and receive messages again every time the player backgrounds the game. And what David mentioned in the original ticket is only concerning subscribe request. |
|
We already fetch history when we return from background (at least I think). And rejoining the channel group is only one request. There would be a minor performance hit, but I think it would be insignificant. I think removing the PubNub instance would be a cleaner and safer solution to this problem. Let me know if you still disagree and we can discuss it. |
0080e68 to
0f0b216
Compare
This reverts commit c179213.