Refactor the 'Report errors to a service' page

[neiljaywarner]

Page URL: https://docs.flutter.dev/cookbook/maintenance/error-reporting Page source: https://github.com/flutter/website/tree/master/src/docs/cookbook/maintenance/error-reporting.md

Description: This page leaves you with a confused feeling if you've never used Sentry - its popularity relative to Crashhlytics is probably very low

[sfshaza2]

@brianegan

[brianegan]

Thanks, @neiljaywarner -- it's a fair point! The reason I didn't use crashlytics: At the time, the Flutter team had only provided the Sentry plugin and no Crashlytics plugins existed.

It looks like there are now a couple of different plugins available on Pub that support crashlytics, but it's funny, I've continued to use sentry myself b/c it was working well for me and haven't evaluated them closely!

@sfshaza2 What are your thoughts on creating a recipe specifically for Crashlytics? If I do, how should I choose between the available plugins on pub -- I can definitely perform a general review of the code, maintenance, etc and make a subjective assessment. However, I wasn't sure if that was good enough in this case, since this could set an "accidental" standard that this is the Crashlytics plugin "The Flutter Team Endorses."

[brianegan]

@Sfshaza Any more thoughts from you or the team on this one? I think I recently saw an official crashlytics plugin being developed, for example.

[atsansone]

@brianegan : It looks like a Firebase Crashlytics package exists. Should we look to integrate this into the docs?

[neiljaywarner]

I think it's far and away the most common one?

Plus firebase and flutter get together quite a bit

....sent from my phone

On Mon, May 22, 2023, 10:26 PM Anthony Sansone @.***> wrote:

@brianegan https://github.com/brianegan : It looks like a Firebase Crashlytics package https://pub.dev/packages/firebase_crashlytics exists. Should we look to integrate this into the docs?

— Reply to this email directly, view it on GitHub https://github.com/flutter/website/issues/2315#issuecomment-1558456947, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXBGYPGICWFTEQK7XUGFU3XHQU73ANCNFSM4GTK47XA . You are receiving this because you were mentioned.Message ID: @.***>

[brianegan]

@atsansone Yah, totally makes sense now that there's a supported first-party / flutter favorite package. My previous comment was 4 years old before there was an official package.

Overall, the popularity difference between Crashlytics and Sentry doesn't look monumental (98% popularity compared to 100% popularity).

Therefore, perhaps keeping & renaming the current recipe and adding another recipe for Crashlytics might make sense?

[sfshaza2]

@miquelbeltran, please review

[miquelbeltran]

Personally, I am not sure if a cookbook recipe is required here when the official docs from the product pages, e.g. https://firebase.google.com/docs/crashlytics/get-started?platform=flutter already cover this and are up to date.

I think we could replace the Sentry tutorial part with links to the official documentation, like we do in the Stage Management options list: https://docs.flutter.dev/data-and-backend/state-mgmt/options so we don't promote one over the other.

[ericwindmill]

I agree with Miguels comment here. Given that the official docs are thorough, I would rather not add to our maintenance load. I also agree with the original comment: Sentry is far less popular than Crashlytics.

I recommend we either remove the Sentry recipe altogether and replace it with nothing, or we add a link to the both the Sentry and Crashlytics docs somewhere.

@sfshaza2 @atsansone WDYT?

[parlough]

I think it's fine to remove the Sentry recipe and not add one for Crashlytics, instead adding a general section titled something like "Track app crashes and errors" to https://docs.flutter.dev/testing/errors. It could also be a new page.

The section could talk a little background about why, and then link to the resources for various providers (Sentry, Crashlytics, Datadog, etc).

[ericwindmill]

I think it's fine to remove the Sentry recipe and not add one for Crashlytics, instead adding a general section titled something like "Track app crashes and errors" to https://docs.flutter.dev/testing/errors. It could also be a new page.

The section could talk a little background about why, and then link to the resources for various providers (Sentry, Crashlytics, Datadog, etc).

This sounds like a good plan to me.

I also did my due diligence, and they Sentry cookbook is among the ~10 lowest performing pages, measured by pageviews.

[neiljaywarner]

I've been considering looking into sentry, partly because it's mentioned here and flutterfire cli wasnt doing that great for android analytics+crashlytics+flavors etc, but they might've finally fixed that..

firebase crashlytics is so common and free and keeps improving (ide integrations, insights etc) and plays nicely with firebase analytics, etc.

having a really good tutorial/video for hello world/counter app with dev and prod flavor and all platforms and firebase analytics and firebase crashlytivs would be so nice because they are painful to setup adn needed in basically every serious app.

On Tue, May 21, 2024 at 10:17 AM Eric Windmill @.***> wrote:

I think it's fine to remove the Sentry recipe and not add one for Crashlytics, instead adding a general section titled something like "Track app crashes and errors" to https://docs.flutter.dev/testing/errors. It could also be a new page.

The section could talk a little background about why, and then link to the resources for various providers (Sentry, Crashlytics, Datadog, etc).

This sounds like a good plan to me.

I also did my due diligence, and they Sentry cookbook is among the ~10 lowest performing pages, measured by pageviews.

— Reply to this email directly, view it on GitHub https://github.com/flutter/website/issues/2315#issuecomment-2122869687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXBGYM2OKU5AI63K6YSWXLZDNQPHAVCNFSM4GTK47XKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGI4DMOJWHA3Q . You are receiving this because you were mentioned.Message ID: @.***>

[atsansone]

@parlough : I'll leave it to you to refactor changes in this space. Thanks!

[parlough]

I'm not going to have time to work on this any time soon, so I'm unassigning myself. Happy to help anyone that wants to tackle this though, thanks!