Poll about Errors tab future

[vbuberen]

Hey everyone.

Chucker evolves pretty fast and becomes better every day thanks to great feedback from the community and contributors hard work. However, there are some features that don't get much feedback on possible improvements. One such feature is ability to capture Throwable errors and show them in Errors tab. Moreover there are even some suggestions asking to disable that tab or remove it completely (like in #88 or here).

While it looks reasonable that Chucker could remove this feature completely and focus just on network part we don't know for sure if this feature is used a lot or everyone just ignores it. Since there is no analytics available we would like to create sort of a poll in this issue and see your opinion.

To vote just put a reaction to this message with emoji.

Available options are:

👍 - Leave Errors tab and errors collection feature.
👎 - Remove Errors tab and errors collection feature.

This poll is valid for 1 month till May 8th so we could gather enough feedback.

We would also love to hear your feedback on whenever you or your team used/use Errors tab and if it was/is helpful, so don't hesitate to leave comments here, in this issue.

[cortinico]

We also got this question on Reddit, I'm dropping the link here so we have it as a reference: https://www.reddit.com/r/androiddev/comments/fvbmw8/chucker_v320_is_out_with_a_lot_of_uiperf/fmifj3n

[ColtonIdle]

It just seems to me like chucker should stick to doing what it does well and what it was created to do. Networking.

I've got other libraries for crashes.

Another example. Charles proxy doesn't try to catch my errors either. 😄

[cortinico]

Quick reminder as this is closing in 2 weeks.

[tpakis]

Just to add to the discussion, I recently wrote a small article about the 2 use cases I found for Chucker, one is of course to log network traffic but the other is to log Uncaught exceptions with a custom crash handler. It's really useful mainly for testers, having both features in only one tool is something that helps a lot, so should you choose to focus on network logs please leave a way (maybe in settings) to enable it for people that find this useful: https://itnext.io/log-uncaught-exceptions-and-network-traffic-with-chucker-for-android-ps-967fe3e0488c?source=friends_link&sk=71105759bd2316d8f5cc420c4dc7d5a7

[vbuberen]

Hi @tpakis.
We will not remove this feature right away. This functionality will be marked as deprecated for 3.3.0 and will be removed for 4.x release, which will have quite a lot changes anyway.

Your use case looks interesting, thanks for sharing.

P.S. It is not good to vote from different accounts. We are trying to get multiple opinions from different people, not same opinion from same people multiple times.

[tpakis]

You are right this was done by accident, so I removed the second vote

@vbuberen for 4.x removed you mean, without possibility of manually enabling it, correct?

[vbuberen]

Yes, correct.

[manthesepeasrock]

I think it should not be removed a great use case that @tpakis gives is that useful to quickly debug QA builds, on my use case the QA team generally knows what to attach when filing a bug and giving the information that is caught on Chucker can really make the process of validating the bug and fixing it really agile, since other solutions require a sync is made (like firebase for example)

I believe that if needed, an option to hide it when configuring Chucker should be preferable

[MiSikora]

I also think it is a usable and useful feature but it is not about usability and usefulness. There are multiple other features that could be done here as well. Screenshot capture, logs preview, and so on. This does not mean that they should exist in this library. Even the description does not indicate that Chucker is a general-purpose tool - An HTTP inspector for Android & OkHTTP. Otherwise, how would you distinguish between what belongs to the library and what doesn't?

In the end, it's up to the authors and this poll but I don't see why this should stay. Single responsibility principle can and should be applied on a library level as well. In my opinion Chucker's responsibility is I want to inspect network calls.

[cortinico]

Totally agree with @MiSikora, I'm biased toward having the library focused on OkHTTP network traffic.

If there are valid use cases, we can still create another repo and host there a ChuckerTeam/Chucker-Errors-only (let's find a better names) version of the library.

At the end of the day, the Network and the Errors feature are completely isolated, they fire two separate push notifications and they live in two separate DB tables. It's reasonable to ask to add a separate dependency if you're interested in catching Errors.

[manthesepeasrock]

I also think it is a usable and useful feature but it is not about usability and usefulness. There are multiple other features that could be done here as well. Screenshot capture, logs preview, and so on. This does not mean that they should exist in this library. Even the description does not indicate that Chucker is a general-purpose tool - An HTTP inspector for Android & OkHTTP. Otherwise, how would you distinguish between what belongs to the library and what doesn't?

In the end, it's up to the authors and this poll but I don't see why this should stay. Single responsibility principle can and should be applied on a library level as well. In my opinion Chucker's responsibility is I want to inspect network calls.

Ok, valid enough

[vbuberen]

I have the same opinion, that Chucker isn't a general QA tool.

For all the other cases there are other solutions, like Hyperion https://github.com/willowtreeapps/Hyperion-Android, for which we will publish official Chucker plugin pretty soon. It is already created in a separate repo and just needs some publishing preparations.

[tpakis]

I also get the point to focus on only one functionality and doing it well. Like better support for GraphQL which I think would be extremely nice (I use heavily GraphQL so I was checking the PR and the proposed changes, I could also contribute some ideas).

My main goal was to make known that this feature is not totally unused. Some ideas proposed here are interesting also, since its really separate both UI and data, the fragment could be attached to a different activity about errors (or even adding extra logs) that could be launched from somewhere else and the main UI focus on network. A second library is also a fine option, dropping it completely is also fine and totally understandable, so it's totally up to you with the direction of the library :)

[vbuberen]

We are closing our poll as the deadline reached.
The option for removing Errors tab got more votes.
Adding a screenshot from the moment of writing this message to fix the result.

Errors tab won't go right away. For the 3.3.0 release all the parts connected with it will be declared as deprecated, so everyone will be aware of coming changes.

Complete removal is expected in 4.x release.

[Shipaaaa]

Hello! I missed this poll. This feature is very useful and helpful for QA and beta testing. It’s easier and faster to open the Chunker than to connecting the phone to the ADB or to finding the crash in the Crashlytics. Maybe you can recommend alternative proven solutions?

[ColtonIdle]

@Shipaaaa as mentioned above, you can use Hyperion. https://github.com/willowtreeapps/Hyperion-Android

[cortinico]

@Shipaaaa As previously mentioned here #321 (comment), we can dump all the code for the Error feature in a self isolated module and make it available as a separate library/module if there is demand for it.

[tpakis]

This is also a very nice idea, people can also extend the functionality of that lib afterwards if anyone is interested

[CsabaMiomni]

Hello! I missed this poll. This feature is very useful and helpful for QA and beta testing. It’s easier and faster to open the Chunker than to connecting the phone to the ADB or to finding the crash in the Crashlytics. Maybe you can recommend alternative proven solutions?

I'm in the same shoes, now I have to find another implementation - or create my own one - that provides me a better QA features. :( I can't ask the client to install Android Studio on a machine and do this and do that, it's ridiculous. :( I've chosen this lib over Chuck because this had the error logging feature. Now it's pointless.

[cortinico]

as mentioned above, you can use Hyperion. willowtreeapps/Hyperion-Android

@CsabaMiomni as mentioned above, you can use Hyperion. Or you can use a older version of Chucker where this feature was still available.

[raquezha]

Sad, we love this feature and used it when debugging along side the network request. We're thinking if we want to upgrade to 4.0.0.

Edit: will try hyperion instead

[ColtonIdle]

Sad, we love this feature and used it when debugging along side the network request. We're thinking if we want to upgrade to 4.0.0.

Edit: will try hyperion instead

hyperion uses chucker for network inspection 😄