Closed d4rken closed 9 years ago
At least least this should be opt-in, not on by default.
:+1:
But maybe this can be removed and we don't have to maintain it.
I think it could be useful to users to automatically track exception as Events in their app
Explicitly tracking exceptions could have some usecase, but even then it's almost always replaceable with if-checks, then track a normal event, which is better practice.
Automaticially tracking all exceptions needs strong filtering and extra options on the server side. As i said for small apps 5k-20k active users this could work, but even then i would recommend picking something like Crashlytics that was made for this. Having options to hide processed exceptions, stopping reporting from older app versions etc.
If we venture into higher user counts like 100k-150k users, you will get daily crash that are unrelated to your app, but just got caught in your exception handler. With no server-side organisiation, it will spam the event section until it's unusuable.
I would propose to reduce the crash tracking to method that wraps the normal trackEvent method and just converts an Exception object to a useful message. Then remove everything else including automatic exception catching.
I don't want to throw the current piwik-android-sdk over, I'm just speaking out of experience. Sorry for all the scrutiny.
Oh it's very useful to have your scrutiny actually!
I would propose to reduce the crash tracking to method that wraps the normal trackEvent method and just converts an Exception object to a useful message. Then remove everything else including automatic exception catching.
Would this change the way the exception are tracked, eg. https://github.com/piwik/piwik-sdk-android#dispatching ? if so please submit the change to documentation with your PR
No, it will stay the same, I would basically remove the automatic exception handling and then simplify the exposed API.
I'll make a pullrequest when I'm done with the current one and we can discuss it when everyone can see the changes. I can tag you on the pullrequest if you want.
I'll have a look through the docs though to see if it needs updating.
Alexey did an awesome job with what we already have and i followed this project for some time and wished i could have joined sooner.
I currently have a (very patch worky) self made tracking with json + node.js + couchdb and my goal is to replace that with piwik. It's relatively urgend because i underestimated the user growth and amount of data that is to handle. Piwik to the rescue ;).
Got many more ideas and PRs in mind, i hope @dotsbb will like most of them :o.
My concerns are addressed with PR #33 further discussion can be done there.
I'm looking for a use case or legitimization why we should track and forward exceptions. Is there a plugin for the service tracker that visualizes them well and allows for organization? Or to prevent reports from older apps for solved issue?
In bigger apps with 100k+ users, you always have crashs that are out of your control and after a few weeks the "Crash Event" list would be filled with useless stuff and no way to hide or remove these except manual database alternation. I do not see this being useful except maybe to have screenview tracking like start->screen1->screen2->crash. Although this is cool, with bigger usernumbers, i can't see this being favorable over traditional crash tracking (ACRA, Crashlytics etc.).
At least least this should be opt-in, not on by default. But maybe this can be removed and we don't have to maintain it.