5

We are currently building a framework (closed source static library) that will communicate with some Smart home devices via Wi-Fi. This framework will be used by 3rd party developer to build their own applications (mainly mobile application) in order to communicate with those devices.

Currently, we have split opinions on if the framework should generate any visible logs (say a log file, or event logger) on a release version (we will supply a debug and a release version to 3rd party developers).

Reasons to have logs:

  • Logs are always helpful if we need to find out the root cause of unexpected error.
  • Any form of logs is always good
  • Getting the logs information from mobile phone should be easy. (By app user or support desk technician)
  • We can prove it is application developers' fault if they blame it to us.
  • Some issues may only happen in production that cannot be reproduce on test environment.
  • Log files are not big anyway. A small log file that use some of the device storage shouldn't be an issue.
  • All servers application/API always have logs.
  • Reverse engineer is always possible via decompile, so it shouldn't really matters.

Reasons to not have logs:

  • Framework doesn't own the application.
  • Most users have no idea how to get the log files out of application's storage (hence less likely to be able to get it), so don't add something that will not be used
  • Application developer should be able to pinpoint the problem by their own logs/debug method before coming to us
  • Risk of exposing too much information to end users.
  • No other frameworks seems to do it (e.g. Facebook SDK/Google SDK)
  • Taking up device storage. Every byte count.
  • It is the responsible of the framework user (developer) to have their own logs/crash reporting if they want to.
  • Debug version with console/debugger logs should be enough for developers.

So basically we are not able to get into an agreement. Just wondering what does the wider community think about this if you are the developer that use a closed source static library on a client application.

  • 3
    Opinion based: Never log in Release builds. – shallowThought Jan 19 '17 at 7:30
  • At least about Facebook SDK you're wrong github.com/facebook/facebook-android-sdk/blob/master/facebook/… – Eugen Martynov Jan 24 '17 at 5:49
  • I would appreciate logging for any long, complex, tricky operations. And I suppose from your library nature it is exactly a case. – Eugen Martynov Jan 24 '17 at 5:52
  • @EugenMartynov I guess I didn't make it clear enough. I meant it would have logging turn on (without option for 3rd party developers). Obviously having an option could be the way to go, and it become the responsibility of the 3rd party developers. – CHey Jan 25 '17 at 20:26
4

Can you not make it configurable? Almost any Android library that does network requests I know does one of the following:

  1. Have a config file and/or setter on some class where you can activate logging and set the log level
  2. Read out if the app is build as debuggable and log accordingly

As a developer I would be pretty annoyed if a library would come in two flavors (debug and release) or just decides for me. Also logging in production on mobile is a no go as it can be read by absolutely anyone with access to the device.

  • I can't really say much for Android as I am mostly iOS. However, I do agree with your point that the developer should be able to provide a logger or set a log level via configuration. – CHey Jan 25 '17 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.