@shamim-emon Thanks for addressing the drawer settings persistence issue. I appreciate your work on this.

I see that using K9 in this case is a quick fix, but it introduces a dependency on an outdated legacy module. Our goal is to minimize dependence on such modules, as they can harm build times, use outdated methodologies, and are subject to rewrites.

Instead, I propose moving the showAccountSelector setting into the DrawerConfig. Adding a new DrawerConfigWriter to the NavigationDrawerExternalContract and a use case SaveDrawerConfig to the DomainContract, would enable us to write tests and follow our new architecture.

I understand that dynamic updates are currently problematic, as the implementation needs to sit on top of K9. While this might look like boilerplate, it's necessary for addressing the architectural issues with K9 in the future.

As an alternative approach, I was considering a solution similar to GeneralSettingsManager and RealGeneralSettingsManager, where changes would be exposed through a flow-based interface and values are updated via a separate call enabling a unidirectional data flow. Something like DrawerConfigManager exposing a Flow<DrawerConfig> and a save(config: DrawerConfig) which emits changes to the flow while handling persistence and sync with K9 internally.

Let me know if you have further questions.

@wmontwe I see the concern with this approach. I will move forward with your suggestion. I don't have any question at the moment but if anytime comes up, I will be sure to ask. Thank you!