Add Google Analytics individually for trip/stop problem reports

[barbeau]

In the current Google Analytics implementation, we're reporting a generic "problem report" metric in ReportProblemFragmentBase:
https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/src/main/java/com/joulespersecond/seattlebusbot/ReportProblemFragmentBase.java#L117

However, as far as I can tell this won't provide any separate reporting for trip/stop reports, and I'd like to be able to record what reports of each type are submitted.

So, this analytics event should probably be moved to the sendReport() method of the subclasses ReportStopProblemFragment and ReportTripProblemFragment, and a separate label should be included (or another way to distinguish the report types).

@cagryInside Could you please confirm this is correct, and if so submit a quick fix for this? We should fix this before pushing the next beta based on master, and would need to fix in develop too.

[barbeau]

Also, if iOS has the same behavior, can you please open a similar ticket on the OBA iOS project with a pointer to the code and referencing this issue?

Thanks!

[cagryInside]

@barbeau Yes, this event should be moved to ReportStopProblemFragment and ReportTripProblemFragment classes.
However, in IOS, the same sendReport labeled event triggered for ReportStopProblemFragment and ReportTripProblemFragment classes. I think, for consistency, we should keep the same structure with ios and add this into the proposal.

[barbeau]

@cagryInside I really want to get a handle on separate trip/stop problem reporting in the next release, since that will help us when designing the feedback improvement (#187), and will give us some "before" data for how people used the app, as compared to after our improved process to handle issue reports.

One solution would be to report both - a generic category (as-is), and then add the specific events to the stop/trip problem reporting to the subclasses. Thoughts?

[barbeau]

And, we'd add the new specific events to the proposal for iOS as well.

[cagryInside]

@barbeau

One solution would be to report both - a generic category (as-is), and then add the specific events to the stop/trip problem reporting to the subclasses.

I agree on the solution. For now, we can report the generic one and also specific events to the stop/trip problem. And, when we release the new issue reporting improvement (#187), we should rearrange the analytics labels.

One question:
Should we keep the generic "problem report" event in ``ReportProblemFragmentBase`?

[cagryInside]

@barbeau sorry, I miss understood. I thought I implemented the "problem report" event different then IOS. Now, I checked, the current android implementation is exactly same with IOS. So, please ignore the following comments:

@barbeau Yes, this event should be moved to ReportStopProblemFragment and ReportTripProblemFragment classes.

One question:
Should we keep the generic "problem report" event in `ReportProblemFragmentBase?

So, as a new proposal, we can also add specific events to the stop/trip problem reporting to the subclasses (ReportStopProblemFragment and ReportTripProblemFragment)

[barbeau]

@cagryInside No problem. Yes, let's keep the current generic "problem report" event in ReportProblemFragmentBase so we match iOS, and add specific events to the stop/trip problem reporting to the subclasses (ReportStopProblemFragment and ReportTripProblemFragment).