When using a third party library, which type of lo...

# android

[Lukas K-G]

When using a third party library, which type of logger would you prefer that the lib is using?
1️⃣ slf4j
2️⃣ Timber
3️⃣ let me provide my own implementation of a logger interface to the library
4️⃣ something else, please state in the comment.

If you would take your time and comment a reason why would be highly appreciated.

[Grégory Lureau]

Locking a library to a logger solution means some projects/teams will just not be able to use your library. Don't force a dependency when you can just define an interface and be flexible enough to work with any other libraries.
Also you can provides another library to provides the implementation, so that it's even easier to use your library. (Like Room provides a rxjava2 and a rxjava3 additionnal libraries without forcing rxjava in the core lib.)

[Lukas K-G]

Thanks for the valuable input @Grégory Lureau!

[gildor]

which type of logger would you prefer that the lib is using

If it is an Android library, it’s also completely fine to use android.util.Log, but you should provide some way toenable/disable logging for your users

[Kamil Kalisz]

But using plain android.util.Log will have some drawbacks, like no possibility to save/store logs

[Lukas K-G]

Good point @Kamil Kalisz, I guess that kinda depends on the type of library you are providing and if storing logs is required or if it is enough to have the option to enable logging for a debug session.

[gildor]

But using plain android.util.Log will have some drawbacks, like no possibility to save/store logs

If it can be useful for particular library, sure, but never had a case when I want to save logs from 1 particular library

I usually want to save all logs, not logs from particular library and just use logcat from the app instead

[Adam Powell]

Libraries shouldn't log. If something happens in library internals that you might want to know about, it should offer an event listener/callback/stream as part of its API and if you want to listen and log it as the integrating developer, that's your business

[Adam Powell]

For anything that can happen in library internals either it's not important enough to log and shouldn't logspam, or it's important enough to have a real event API so that no one ever feels like they want to parse log strings as an informal event API

[Lukas K-G]

That's a very interesting take. Don't you think that there might be some scenario where exposing logs could be helpful? E.g. something goes wrong for the lib user that is not easy to reproduce, in this case including these logs with the error report could be very helpful.

[Grégory Lureau]

Agree with @Adam Powell but I still think it's better to provide more info just in case, and you can still decide to not re-use those logs on your app if you want. I wish all libs allow me to debug easily just by adding a light implem and redirect to my logging tools. Indeed a prod-ready bullet-proof library with all edge cases already handled and providing well defined callbacks are way better but I feel like all libs are not created equals and allowing debugs could be great for investigating some cases.

[Adam Powell]

"log it just in case" is a great way to create user privacy incidents, plus we have some rather strong data from the Android device ecosystem that spurious logging and string formatting for logging is responsible for a highly nontrivial amount of battery drain in real world use. For cases where debugging info is actually useful, if a log message would be useful for debugging, a Throwable reported to a callback is even better.

[gildor]

Libraries shouldn’t log

Many google libraries do log, and often it helpful for things like analytics (or any other complex SDKs)

[Lukas K-G]

Thanks for the discussion here, very valuable input for me. 🙇

[Adam Powell]

@gildor they do, and my opinion above is based on experience with that. 🙂 We're likely to institute some policies about Jetpack libraries logging in the future that restrict it.

[Grégory Lureau]

Is it not enough to use Proguard to drop some calls to Logger interfaces in production and when you don't need them? I expect Proguard to remove 99% of String formatting and avoid perf issues.