-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplified Collectors #496
Conversation
/** | ||
* Created by Lukas on 12.08.2016. | ||
*/ | ||
public class CustomDataColletor extends Collector { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo in name
Definitely need to keep USER_CRASH_DATE as it says when the crash actually happened. |
* | ||
* @return priority of this collector | ||
*/ | ||
public int getPriority() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a priority?
If a Collector is configured then it should be called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was meant to provide control over the execution order to the collectors, but it is probably overengineering to do so.
Ok, backwardscompatibility is probably more important than the negligible improvement of sending two strings less. |
Resolved merge conflicts (rebase onto master) |
Currently there is no standard way to talk to a Collector. Every collector sort of does its own thing: Some are static, some require an instance and every call has different parameters.
This aims at standardizing all these collectors, which greatly reduces the code inside CrashReportDataFactory.
While it might look differently, this actually doesn't change any of the underlying logic, it just cleans it up.
However I noticed we ignore some of the configuration: While it makes sense to always send the Stacktrace and a report id, I think IS_SILENT, USER_APP_START_DATE and USER_CRASH_DATE do not qualify for an always-include and should be optional.