Closed jkmassel closed 5 years ago
Nice work @jkmassel!
Would it be possible to keep the Sentry specific logic out of Tracks? I really like the way you have made the behavior generic but I don't love the fact that Sentry
is still a direct dependency here. What do you think?
Does this mean that Tracks will receive crash reports or that we're letting the Tracks client set up crash reporting?
Should this PR include an update to the README file?
Does this mean that Tracks will receive crash reports or that we're letting the Tracks client set up crash reporting?
We'll be letting the Tracks client set up crash reporting – Sentry will receive crashes for the foreseeable future.
Should this PR include an update to the README file?
Good call – will do!
@shiki – requesting your eyes on this because you had some great comments on the Android architecture.
This PR adds support for using Tracks as a wrapper around any crash logging service – in this case, Sentry.
If, in the future, apps needed to work with another crash logging provider, it'd be simple enough to swap out the implementation without disrupting any of the other applications.
Additionally, a lot of the low-level bookkeeping work is now represented here, ensuring that we don't have code duplication in many different applications. This will become more important as features such as log processing are added.
Sample implementations:
https://github.com/Automattic/simplenote-ios/pull/304 https://github.com/Automattic/simplenote-macos/pull/325