Conversation
pedronveloso
requested review from
ScottAntonacAP,
psymoon and
valdesekamdem
as code owners
| * If your app already uses Timber, plant your trees **before** calling any Afterpay SDK methods. | ||
| * The SDK will detect existing trees and use them. If no trees exist, the SDK will plant a | ||
| * default DebugTree for DEBUG builds only. |
There was a problem hiding this comment.
Since this is an internal class, how will consumers see this instruction to know the expected calling order?
There was a problem hiding this comment.
I guess this instruction is only for consumers of the debug build of this SDK, which should only be contributors to the SDK rather than real-world apps.
| if (!BuildConfig.DEBUG || loggingDisabled || initialized) return | ||
|
|
||
| synchronized(this) { | ||
| if (!initialized && !loggingDisabled) { | ||
| try { | ||
| if (Timber.treeCount == 0) { | ||
| Timber.plant(Timber.DebugTree()) | ||
| } | ||
| initialized = true | ||
| } catch (e: LinkageError) { | ||
| // android.util.Log not available (unit tests without mocking) | ||
| loggingDisabled = true | ||
| } catch (e: ExceptionInInitializerError) { | ||
| // Timber initialization failed | ||
| loggingDisabled = true | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Is there any benefit to using Timber if we're rewriting all the debug checks etc. anyway? May as well just drop the dep and use android.util.Log directly.
| -assumenosideeffects class timber.log.Timber { | ||
| public *** d(...); | ||
| public *** i(...); | ||
| public *** w(...); | ||
| public *** e(...); | ||
| public *** v(...); | ||
| public *** wtf(...); | ||
| } |
There was a problem hiding this comment.
Is this valid to put in library rules? I.e. is R8 smart enough to not strip these if the consuming app is using them directly? I'm not an R8 expert, but it seems like stripping AfterpayLog calls should be sufficient since Timber is only used internally inside AfterpayLog.
2 participants
This adds much needed logs via Timber (same standard we use on internal codebases). These logs are stripped from the release version of the SDK, so there is no risk of leaking any unintended information on production.