Few customization ideas

[jakoss]

First of all - i love the design. But from such tool i do require some customization and cooperation with similar tools.

Customization:

• Add option to NOT log into logcat. My scenario is that i'm using Timber application wide. I can add new tree for Pluto, but it will write into logcat, and i have another custom tree for that. So i would like to log into Pluto, but only for the backing database (to later see that in ui)
• Use only tools that user want. For example if somebody does not want (or need) to listen for network events - just do not load that module. Module word is the key, it would be great if every pluto feature had it's own module. This way user can use only the dependencies he uses. Great example of that is Beagle library
• Opt-in features - It would be great if we could turn on/off features. Right now pluto is basically all on. Simplest scenario - cooperation with other uncaught exception handler libraries (we could just turn off crash handling) or maybe somebody is not using SharedPreferences at all (supporting DataStore here would be great)

Cooperation with similar tools

• The setDefaultUncaughtExceptionHandler overrides already set exception handler. It would be great if pluto could store current exception handler and then call it whenever crash happens. Scenario - we are using special flavor "debuggable" for internal QA testing. It's Release build, but with debug tools enabled for QA engineers. We want crashlytics to be enabled on those builds, but it would be also great if debug tools could handle crashes locally. For that, the local debug tool would have to detect crashlytics handler and pass the exceptions to it

Features:

• Support DataStore preferences along the SharedPreferences. This would be the first tool to do that

[jakoss]

If any of that makes sense for you i would be glad to contribute :)

[srtvprateek]

hey @jakoss,
thanks for the ideas for improving the library,
the ideas that you suggested are completely valid and we are already working on customization ideas for Timber integration and feature switch.
The rest of the suggestions also make sense and will help make Pluto super useful for the developer community.

The main reason for making Pluto open-sourced is to allow the developer community to contribute and improve it as per their need, so I would love to see you contributing.
Currently, our contribution guidelines are WIP, will update you once we are ready to accept contributions from the community.

[jakoss]

Awesome, thanks

[srtvprateek]

thanks, @jakoss,
we have updated Pluto to support plugin architecture, now all the debuggers are available as plugins.
we are making the framework open to all developers to create their own debuggers and use with Pluto.

[jakoss]

thanks, I will test that out