Problems after migration to version 2.0+

Hello, thanks again for the great library.

We have faced several issues after migration to beagle drawer-layout. I see that now the base implementation uses a fragment under the hood. It introduced a few problems:

1. We use Accessibility an application and now OverlayFragment request focus all the time due to he is a root 🙂
2. Due to we have a legacy code we sometimes replace fragment in android.R.id.content and in this case we lose Beagle on this screen)

Thanks a lot.

[pandulapeter]

One more update: I’ve played around a bit with the back stack listener in this commit and there is a slight chance that these changes will fix your second issue. Theoretically now the OverlayFragment should be re-added to the top of the stack every time the stack changes.

If you haven’t given up on the library yet, could you give it a try? These changes are part of the new v2.0.3 release.

[pandulapeter]

Hi,

Sorry to hear about these problems. Both of your issues make perfect sense and come down to some core design decisions on my side. Unfortunately, I don’t yet have a good solution, but let me give you some explanations, maybe together we will figure something out:

1. OverlayFragment is indeed added on top of every Activity: in case of the drawer it is responsible for Beagle’s UI (the old versions’ hacky way of removing the root View of every Activity and “injecting” a DrawerLayout instead was glitchy, hacky and probably introduced more problems - this solution feels a lot cleaner). Furthermore it also handles persmissions / Activity results (for the screenshot / screen capture features) and hosts the OverlayView which provides a way for drawing over the UI (for example the KeylineOverlaySwitchModule relies on it). Obviously OverlayFragment should not affect the functionality of the underlying app in any way apart from these. I didn’t work with accessibility that much, do you maybe know a simple fix for not stealing the focus? How can we forward these events without knowing what’s below?

2. Three ideas: a) If your legacy code happens to rely on the FragNav library, this workaround might help. b) I could add an optional lambda to the Beagle configuration’s Behavior object: it would receive an Activity type parameter and would expect an ID resource in response that can be used as OverlayFragment’s container. Unfortunately this also would need some refactoring of your legacy codebase to add empty FrameLayouts over the Activities. Anyway, would this help? c) What do you think, in the addOverlayFragment() function of this class, if we used add() instead of replace() - could that fix your issue? Probably not, since in your case your own implementation seems to be calling replace() after Beagle, so the debug menu wouldn’t be added to the top (and we could also introduce some unwanted stack handling issues).

All in all: I’ll let you know if I have any other ideas but right now the best that I can say is that in release builds your app will work as expected (the noop library surely won’t break focus handling). Do you maybe have any ideas that we could try? If you have the time and feel like experimenting, maybe consider cloning this repository (here is a guide that will help with the module structure).

Thanks for the bug report!