Android: Call UICommon::Init at app start instead of emulation start #8190
Conversation
| } | ||
| }); | ||
| // Registers the DirectoryStateReceiver and its intent filters | ||
| LocalBroadcastManager.getInstance(context).registerReceiver( |
There was a problem hiding this comment.
Is this a 1:1 thing? It feels like it would just be a list of receivers, each notified in turn when something happens.
If it is indeed a list, I'd expect any older invocations to still be alive; rendering the last paragraph of the comment above slightly fuzzy.
Unless we want it to be like that; then we're probably supposed to call unregisterReceiver in case directoryStateReceiver is not null.
...not that it matters too much, since you keep creating new instances in the places where it is used; so they'd likely end up running anyways.
There was a problem hiding this comment.
I was assuming that the old directoryStateReceiver would get deallocated once we create a new directoryStateReceiver, but I suppose that might not be true since the LocalBroadcastManager keeps a reference to it... Since I'm not entirely sure how it works, I think I'll just change the comment to say that multiple calls is not a supported use case, because that's how I've been thinking of it while writing the code.
There was a problem hiding this comment.
Actually, I'll just delete the part of the comment that mentions multiple calls.
There was a problem hiding this comment.
I don't know, but if it works anything close to C# wrt the GC, it should still be referenced by the LocalBroadcastManager (and the closure itself should still be referencing the passed runnable, keeping it alive as well)
There was a problem hiding this comment.
Disregard my previous comment – I've realized that multiple calls should not be encouraged, because if old DirectoryStateReceivers indeed are kept around (which is likely), the way we do unregistration means that newer calls will get dropped rather than old calls. I will make the comment say that multiple calls is not a supported use case.
JosJuice
force-pushed
the
android-init
branch
4 times, most recently
from
b1726ba to
d4a21b8
Compare
|
rebase pls |
Much of our native code assumes that UICommon::Init has been called (for reasons such as wanting to access the user's settings), so not calling it until emulation start heavily limits what native code we can use in the Android GUI (except during emulation).
Preparation for the next commit.
Much of our native code assumes that
UICommon::Inithas been called (for reasons such as wanting to access the user's settings), so not calling it until emulation start heavily limits what native code we can use in the Android GUI (except during emulation).This should not be merged before https://bugs.dolphin-emu.org/issues/11767 has been addressed, because the third commit of this PR makes that race condition worse if my thinking is correct.