Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Timber gives us a better way to log errors or debug statements over the default logging utility. In the PR, the library has been configured in such a way that for debug builds all the logs will be printed to the logcat and for the release builds only statements logged with the priority ERROR will be sent to Crashlytics. It is important to send only a limited number of logs to Crashlytics as it remembers only the last eight reports.
A general rule of thumb that I followed is the exceptions that might occur due to backend response and our logic should be reported so that we can update or fix such things. And exceptions such as IOExceptions (during disk IO) or NetworkExceptions can be ignored as this is something that is dependent on runtime and cannot be handled by us.
Critical exceptions are logged with ERROR
Exceptions that are critical but not needed to send to Crashlytics are logged with priority WARN.
Exceptions of least priority are just logged as DEBUG.
Logs are sent to firebase as expected