Conversation
feature/template-199-kermit-logger
feature/template-199-kermit-logger
feature/template-199-kermit-logger
ninovanhooff
changed the title
| FirebaseCrashlytics.getInstance().isCrashlyticsCollectionEnabled = true | ||
| Napier.base(CrashlyticsLogger()) | ||
|
|
||
| Logger.setMinSeverity(Severity.Warn) |
There was a problem hiding this comment.
It seems to me that previously we determined which logs would be logged and which would not within CrashlyticsLogger, but now it will be a global filter for all events, correct? Perhaps it is worth retaining the definition of what to do with events within CrashlyticsLogger
It also seems to me that we logged debug and above in Crashlytics, not only warn and above
There was a problem hiding this comment.
You might be right about earlier behavior, but I think logging debug messages in release builds is not the right thing to do. I'm thinking of privacy-sensitive data like user id's that are deliberatly or accidentally logged as debug messages.
What reason would you have for debug logging in release builds?
There was a problem hiding this comment.
In the context of improvement, yes, we need to review the use of logs in release builds
For current applications, we have debug logs, and sometimes it was easier to understand what the user was doing before the error occurred, but I'm not sure if this is always necessary. Also, for example, for HeartEye, we have now left the minimum logging level at INFO - exactly for the purpose of not logging user data that could be missed in DEBUG but still have the context of what is happening
It probably depends on the project, but then we need to emphasize that when creating a project, we need to think about this part as well
feature/template-199-kermit-logger
2 participants
Why is this important?
Notes
implements #199