Conversation
Instead of relying on initialization during construction invocation of `SentryCrashLogging`, we'll now ask clients to initialize the SDK at the convenient lifecycle moment.
| ) : CrashLogging { | ||
| init { | ||
|
|
||
| override fun initialize() { |
There was a problem hiding this comment.
I don't think this is a must (or if you think it makes sense), but perhaps it can be useful to throw some IllegalStateException or similar to indicate the lack of initialization when performing some key action(s).
There was a problem hiding this comment.
Thanks @iangmaia . I was going back and forth with this, but motivated by your comment, I've added such check in fbcd738 . It works only in debug - I don't want to risk throwing unhandled exception in release for "uninitialized crash logger". But in debug it'll be helpful to spot any initialization issues.
There was a problem hiding this comment.
I think it's a nice compromise, as developers using the SDK will be able to course correct sooner if they're missing something.
Thanks for considering it!
…logging/CrashLogging.kt Co-authored-by: Ian Guedes Maia <iangmaia@users.noreply.github.com>
| internal class AndroidApplicationInfoProvider(context: Context) : ApplicationInfoProvider { | ||
| override val debuggable: Boolean = context.applicationInfo.let { | ||
| it.flags and ApplicationInfo.FLAG_DEBUGGABLE != 0 | ||
| } | ||
| } |
There was a problem hiding this comment.
|
Thanks @iangmaia , ready for the second round! |

Closes #103
Description
This PR introduces
CrashLogging#initializemethod. The motivation for this is to reduce risks of issues like this one: Automattic/simplenote-android#1518 . In other words: let's not assume thatCrashLoggingwill be injected in the main application, but rather enforce it.Testing
You can edit
gradle.propertiesand provide DSN of a test project (you can find it on Sentry) and report some events using sample app.