This message was deleted.

How about if we cut Chucker

v3.2.0

after https://github.com/ChuckerTeam/chucker/pull/250 gets merged?

Since we mentioned a few times that at some point of time we would have to make minSDK 21 to be up to date with OkHttp I have a suggestion to make it the following way: 1. Chucker with minSDK 21 will be Chucker 4.0 and will occupy current

release

branch. 2. Chucker 3.x.x will move to some

release-archive

branch and will receive some updates (fixes, etc. which don’t require usage of newer OkHttp) for some time (~ 6 months might be enough).

Sure will do 👍 Before we release, I would love to get @Vova Buberenko and other’s opinion on the comments/discussions here: https://github.com/ChuckerTeam/chucker/pull/279#discussion_r395950647 https://github.com/ChuckerTeam/chucker/pull/279#discussion_r395950704

I would like to switch the default branch on Github from

develop

to

release

. The reason - avoid users confusion by having Readme not aligned with latest stable release. For example, recently we had that skip interceptor feature and it was described in Readme visible to all users, while actually it wasn’t deployed in stable releases. Some users might find out library and that feature (for example) could be a killer feature for selection for them and after adding the dependency they would end up without described feature and being frustrated. With

release

being the default branch we can avoid such issue. Yeah, contributors will have to update target branch manually, but it is as big problem as having invalid info visible. Any objections?

@Colton Idle Thanks for sharing your scenario: • Branding: you can override the theme attributes and provide the color you want (same for the icon if you wish) • Library name and strings: you can override the string resources like

<string name="chucker_name">MyNetworkingLibrary</string>

• The error tab will stay till we release 4.0. You can override

<string name="chucker_network_tutorial">

And write something like that this tab is unused and is going to be removed “soon” ™️ .

How do I use Chucker together with mockwebserver? I’m currently trying to test my token interceptor for okhttp using mockwebserver, and that works when the token interceptor is the only interceptor. But when I add chucker, my code hangs when I call

mockWebServer.takeRequest()

. I’m currently mocking chucker. Is that what I should be doing? Here’s what my okhttpclient creation code looks like. Any ideas would be great

fun createOkHttpClient(tokenInterceptor: TokenInterceptor, chuckerInterceptor: ChuckerInterceptor): OkHttpClient {

    val builder = OkHttpClient.Builder().addInterceptor(tokenInterceptor)

    if (BuildConfig.DEBUG) {
        builder.addInterceptor(chuckerInterceptor)
    }
    return builder.build()
}

@voben you can probably use the

-no-op

variant in your test configuration

I’d like to follow up on this topic. Is it possible to make this happen soonish? Or even create a

4.0

branch from

development

branch just for now (or maybe after

3.3.0

is released)? I’d like to play around with some ideas when it comes to the Chucker APIs in the next major release and create issues or PRs.

I'm converting an old app of mine from Chuck to Chucker. For some reason in Chucker 3.2.0 the response sizes all say -1B. This wasn't happening in chuck. I did a quick search on github and didn't find anything. Anyone have any ideas?

Converting an old app went fairly smoothly yesterday. Awesome job everyone. Here are the issues/things I noticed that were still hard from a new user perspective: 1. Setting the notification priority (I tried to set it to MIN from an old Github issue I found, but the icon still appears in the status bar, and while requests come in the icon changes spots in the status bar every 50ms and so it's pretty distracting. Would be nice to have an option to keep this as a MIN with no icon in the status bar (I thought setting it to MIN priority did that?) 2. The -1B issue from above. It would be nice to do the same thing that charles does, which is to just show the size even if the content length isn't there 3. Charles show mynetworkcall.something.com:412 vs chucker only showing mynetworkcall.something.com (👀 the port number is missing in chucker which is unfortunate if your api makes heavy use of those port numbers) 4. For large responses it would still be nice to "Share as file" so that it saves the file, and shares it to slack automatically in one action 5. Save as file unfortunately leaves off the request headers + body and the response headers. It just seems to be the response body. This is weird because it's a different behavior than what you get if you try to Share as text 6. Click on the notification to open Chucker clears the notification. =( You need to open the app again to get it to post, and then you can access it again.

I have an issue where a single network call out of the 50 that my app makes does not show a response body in chucker. If I look in charles, I can see the response body. I've tried: 1. setting break points in charles in order to remove the entire body except for a single field and the response STILL does not show 2. removing almost all response headers, and still no response body appears even if I remove all headers Is this a known issue by any chance?

Woah! Very weird. I just updated my Retrofit type to

Response<MyResponseType>

instead of

Response<Void>

and now everything shows in chucker... going to dig a bit more because that does NOT seem right. Even with Response<Void> I should be getting a proper body showing in chucker. Edit: Yep. Changed back to

Response<Void>

and now chucker shows an empty response. This is not how Chuck used to work? Still investigating...

Just chiming back in here with another use case that is degraded now as of the latest chucker. Similar to the last issue, but with this issue, if I crash in my moshi converter then the result doesn't show in the inspector. It's a "regression" in features in a way because if I was on the train and something crashed due to an invalid backend value I could easily go in and check which is not the case anymore. I know in the convo above the solution was basically "this just isn't how chucker was made to be used" but I hope that someone can see that these two use cases aren't that far fetched, and in the spirit of being an on device network inspector (like Charles proxy, but on your phone) we should try to see if there is any good way to add this functionality back in?

Lots of bug fixes and features since 3.2.0 in April https://github.com/ChuckerTeam/chucker/milestone/9?closed=1 Any chance to cut a 3.3.0 release soon, or is there something else we're trying to get in?

We have just released 3.3.0! Feedback is highly welcome. https://github.com/ChuckerTeam/chucker/releases/tag/3.3.0

Question about the "Added empty state UI for payloads, so no more guessing if there is some error or the payload is really empty" feature in 3.3 I'm using 3.3 and I don't see an empty body state, but before filing a bug I want to make sure it's actually a bug and not my misinterpretation. For example, in Chucker I see a response of this:

X-Content-Type-Options: nosniff 
X-XSS-Protection: 1; mode=block 
Cache-Control: no-cache, no-store, max-age=0, must-revalidate 
Pragma: no-cache 
Expires: 0 
Strict-Transport-Security: max-age=2100 ; includeSubDomains 
X-Frame-Options: DENY 
Date: Fri, 02 Oct 2020 01:22:11 GMT 
Transfer-Encoding: chunked 
Connection: keep-alive

in Charles I see this

HTTP/1.1 200 
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=2100 ; includeSubDomains
X-Frame-Options: DENY
Date: Fri, 02 Oct 2020 01:22:11 GMT
Transfer-Encoding: chunked
Connection: keep-alive

In this case, the payload to me is "empty" but I don't see an empty state. Is this because I still have headers? Will I see empty state if headers are missing as well?

Hey guys! I've just found the channel and first would like to tell you my thanks! You are really doing great job! In my personal project, I just felt that it would be better to clear all transaction history every time app opens Because the old history makes noises and confusions. After some investigation, I found that

RetentionManager

It has ONE_HOUR minimum but it may not be enough for everyone. I'd prefer to have

retentionPeriod : Long

instead of enum. Before I create a feature request, I wanted to ask here first in case of I missed sth. Please tell me, if I did. And let me know your thoughts about having long retentionPeriod. Thanks in advance :)

Does Chucker support any way to dump multiple requests' logs simultaneously?

Moved to: https://github.com/ChuckerTeam/chucker/issues/531

Hello, I'm thinking to have a switch or a dev option to enable/disable chucker notification logging, Is there a way to toggle this without creating a new interceptor?

Hey, cannot find

.addBodyDecoder(decoder)

builder method in v3.4.0. Can someone help?

Hi all, I'm trying to implement clickability to transaction body line items. This feature is requested by our team since our requests contains urls for next requests. What do you think of adding this to Chucker? https://github.com/ChuckerTeam/chucker/compare/develop...bilgehankalkan:feature/clickable-url

I am getting issues while compiling latest develop from jitpack. Can someone help please

java.lang.RuntimeException: Duplicate class kotlinx.coroutines.AbstractCoroutine found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.Active found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitAll found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitAll$AwaitAllNode found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitAll$DisposeHandlersOnCancel found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitKt found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitKt$awaitAll$1 found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitKt$awaitAll$2 found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitKt$joinAll$1 found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.AwaitKt$joinAll$3 found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.BeforeResumeCancelHandler found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.BlockingCoroutine found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.BlockingEventLoop found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)
  Duplicate class kotlinx.coroutines.BuildersKt found in modules jetified-kotlinx-coroutines-core-1.4.1.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.1) and jetified-kotlinx-coroutines-core-jvm-1.4.3.jar (org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.4.3)

any suggestion/ideas how to have chucker intercept a dedicate/manual connection such as https://github.com/tus/tus-android-client?

I'm exploring using ktor to build the networking layer of my next app, but losing chucker would suck. Anyone using ktor right now and have a chucker replacement or would the chucker team ever consider using something like ktor?

Oh interesting. The 3.5.2 artifact seems available to me?

This might be a dumb question, but I'm working on a new project that is using firebase firestore instead of a typical REST api. I would love it if there was still some way to sniff out network activity locally without having to use charles. Has anyone had experience with this and chucker?

I don't really know how dependencies end up working in a library, but it seems like chucker exposes the androidx.viewbinding library. For example, if I use the debug variant of the chucker lib, then I can see and import viewbinding, but in the release variant of chucker there is no viewbinding. Is this worth filing a bug to remove viewbinding from being exposed to consumers of chucker lib?