Deactivate game on iOS when sent to background or an incoming call is triggered #6449
Conversation
There was a problem hiding this comment.
Shouldn't the window losing focus be handled by SDL? I.e. isn't this an SDL bug?
Maybe we're handling some events improperly, perhaps we should consider the window to be inactive when we get some events from the event watch (events like "will enter background", "did enter foreground", etc).
osu.Framework.iOS/IOSWindow.cs
Outdated
|
|
||
| callObserver = new IOSCallObserver( | ||
| incomingCall: () => Focused = false, | ||
| endedCall: () => Focused = true); |
There was a problem hiding this comment.
If I end a call when the game is not active (in the background, as I'm probably in the phone app), does it trigger this and make the game Focused?
There was a problem hiding this comment.
Good one, this call observer component is completely detached from whether the app is in foreground or background. This should be addressed in ab7cafa
|
Good observation. There are two things relevant to this:
Additionally this will probably still not handle the "someone is calling" case despite SDL promising that in the wiki, seeing how the events are implemented. And that's likely happening for the same reason mentioned in OP (iOS changing calls to status bar notifications). I think we will still have to handle that case manually because it's specific to us, as we're a rhythm game, where everything is powered by the audio device. |
|
Reported the issue I was seeing on (2) to SDL: libsdl-org/SDL#11627. I think we'll have to move on with what I have in diff for now, I'll add relevant comments and address the scenario noted above. |
|
Will close and split the call handling part now that #6453 has been merged. |
Was hoping that iOS doesn't make me add extra handling for the "incoming call" part but turns out it does (presumably because calls changed from a full app transition to a status bar notification). I considered not handling it altogether but as soon as the user receives a call, the beatmap freezes (as per the issue thread) as the audio is taken away by the presence of the call, and the freeze does not go away until the call is gone. If enough time passes while the beatmap is frozen, osu! dismisses the score from submission due to the audio playback error.