A modern programming language that makes developers happier.

kotlinlang

:confetti_ball: *Debug Menu v1.0.4 Just Released!*

This is a brand-new module-based debug menu library
A simple, modular library that adds a floating debug menu to your Android app, allowing you to view analytics events, inspect DataStore preferences, monitor logs, and create custom debugging modules.

*Core Features/Modules:*
• :speech_balloon: *Logging* - Visualise, copy and share logs! (w/ Integration guide with Timber)
• :globe_with_meridians: *Networking* - Monitor network requests/responses, copy body or multiple requests - (w/ Integration guide with OkHTTP)
• :floppy_disk: *DataStore* - Edit &amp; Visualise Any DataStore Values
• :chart_with_upwards_trend: *Analytics* - Visualise Analytics being sent to any provider! 
• :jigsaw: *Dynamic*! 
    ◦ Want a global action? (i.e. toggle translate strings) Add it to the menu!
    ◦ Want to show an action tied to a screen? (i.e. log-in, sign up, fill a form) Add a Lifecycle-Aware action that will only show while the screen is visible!
• :shake: Shake-to-open / :bubbles: Floating Action Button
• :arrows_counterclockwise: *Custom Modules* - If none of the above modules suits you, you can always create your own module!

Notes:
:android-wave: *Pure Android* at the moment, but looking forward to making it multi-platform after initial tests
:gear: If you're interested in a Multiplatform version, please let me know trough the repo.


Github: <https://github.com/Tapadoo/DebugMenu>
Feedback is welcomed!

This is great, I wanted to build exactly something like this for debugging purposes! Please add multiplatform though :pray::pleading_face:

Sure! Could you rise an issue in the repo so that my company also knows that people are interested in this feature? :eyes:

 Thanks for your feedback!

Nice! a quick feedback though, instead of relying on BuildConfig.DEBUG to show the fab, it's better to take advantage of gradle buildTypes. Where you can create an interface, that has implementations in the debug folder (where you show the button) and in the production folder (where you show nothing) + adding in the build.gradle.kts file "debugImplementation(...)"
Like that in the production build, nothing related to debug is included!

Ohhh I see! I like that! Thanks!
So if the user has a custom build type they would need to use the fallback feature, right?

So, if I only provide a debugImplementation, if the user wants to use the debug menu and they have a BuildVariant (i.e. `staging`) they would need to provide a  `matachingFallbacks += listOf("debug")`  so that they pull the right source set, right?

I'm basing this out of *<https://developer.android.com/build/build-variants#resolve_matching_errors|Google's guide>*

Ah yes exactly! But usually when you create another build type (like staging in the example) you can call stagingImplementation(libs.etc..) and you can also create a folder staging where you put the implementation of the main interface. So if I need your lib for debug builds and staging builds, I prefer to explicitly declare their dep with debugImplementation and stagingImplementation

Oh, I see! Thanks for that! I will definitely have a look at that then :)

any time! should write a small article about that haha