On a side note: I'm working on a fix for https://github.com/ChuckerTeam/chucker/issues/82 @Olivier or @Vova Buberenko are you guys up for a review? Is not that big but kinda critical

In my job, the developer merges his PR. But I rather prefer the

reviewer

do it, because he's

the one who agreed the code

. And yes, we can use the

Draft

label.

Thread about #141

Talking about roadmap - I believe we should discuss and plan timelines for at least 2 things: 1. Bumping minimum supported Android version to 5.0. We would need it in order to be up to date with components used in the library, like OkHttp. 2. Decide what to do with AsyncTasks, which are going to be deprecated quiet soon. Sure, they still will be functional, but we need to prepare anyway. Personally I am Ok with

coroutines

approach, like one of recently closed PRs suggested. We just need to plan deadlines and list them somewhere, so users are aware.

I see different code styles in conditions like

when

and

if

quite a lot last time. Let’s agree on some type of uniform style? For example, regarding curly braces we could rely on Google’s style https://developer.android.com/kotlin/style-guide#braces

Yes, correct. I would like to have only

RetentionPeriod

visible. Because now I can easily do things, like on an attached screenshot below from almost any place with access to context and it works just fine. Ideally, such things shouldn’t be visible to users at all. So, I am annotating class as

Deprecated

and creating its copy in

internal

package, but without enum and with created

RetentionPeriod

class. Also, I will add a comment with explanation and

use …

link, so users could see what change is going to happen in future. Is it correct? If so, it now seems that I should do it in a separate PR instead of trying to do in my current one with visibility fixes.

☝️ Any other thoughts on this? Just published a new article mentioning Chucker https://proandroiddev.com/migrating-to-viewpager2-89354b9b068d Expect to get some new users for the library :) Actually, it wasn’t some sort of ads for the library, etc. Just wanted to have a real project as an example and at that time I already pushed a few PRs to Chucker and it looked a good candidate for the topic.

Let’s enable

Project boards

on Github and put our planned work there? We could put more than one release there and also we can make it more visible to users on future plans/

Also, let's not add more PRs into 3.1.0 milestone - we already have quite a lot there and some of the stable versions users already awaiting for a fixed version (I mean fixes like big payload).

Excited for

3.1.0

! Great work!

@Vova Buberenko should be pull the trigger? 🚀

My point of view here is that we should completely remove

Throwable

processing along with

Errors

tab from Chucker. Chucker should concentrate on network stuff and, possibly, on notifications capturing, like one of users suggested.

Going to try my branch out of curiosity. Anyway looks like JitPack doesn't like too many

/

in the branch name

Which is kind of my point about how is it able to log with no issues and in this case just because we're grabbing the string it's causing some other issues? Anyway. I can't really help here. Mostly curious if there was some sort of guarantee that chucker doesn't touch anything.

@gammax Trying to get your fix, but no luck. Copied version from JitPack

I'm still investigating who forces the version of OkIO. Anyway, if you see the

null

it means you're running on OkIO version

1.15.0

@Vova Buberenko can you take care of the release notes change? Or should I do it?

I've updated the PR. Now it consistently fail/succeed on the sample app

Hey, before I continue with decoded/encoded urls I’d like to change how ChuckerInterceptor is initialized. I need this because encode/decode option should be configurable before start and just adding stuff to constructor is bad. Instead of using constructor I’d like to add a builder along the lines of Moshi, OkHttp, Retrofit or other popular libraries. I’d like to keep the old constructor for compatibility reasons but mark it as

@Deprecated

. I believe using a builder would help to add configurability to Chucker. On the other hand I know that there is pending PR https://github.com/ChuckerTeam/chucker/pull/141 so I’m not sure what to do. What do you guys think?

Hey @Vova Buberenko 👋 Are you taking care of #233 and #246 or should I do them?

Question about "Add switching between encoded and decoded URL formats. #233" Why would one want to switch between those? I'm not really familiar with URL encoding and what have you, so sorry for the newb question.

Are there any benefits of this move? From my point of view it might be eventual switch to Github Packages for distribution and some additional Actions, which might improve our development flow. Despite that fact I am not sure that we should do it now. I would really love to see us finishing some features and PRs (like https://github.com/ChuckerTeam/chucker/issues/69 ), since they really should be our top priority and do things like switching CIs in the meantime and only if it is worth it.

Hope it’s not a problem.

Maybe someone else from the community can pick this up 😄 @Benoit Vermont @Olivier

Thanks for clarifications. I am not sure that the point with forks is worth to consider at this moment of library developement. But as to Actions - I am in for it, but let’s gather a list of Actions we need or would like to see in the repo and after it we could see on how we should prioritize this migration to Github Actions completely. I will start the list of Actions I suggest to consider: 1. https://github.com/marketplace/actions/codecov 2. https://github.com/marketplace/actions/sonarcloud-scan 3. https://github.com/marketplace/actions/add-an-issue-reference - to add or replace PendingRP 4. https://github.com/marketplace/actions/automatic-revert

any plans to migrate to kotlin coroutines ?

Hey, as Moshi is a successor to Gson and all the future developments will be done on Moshi instead of Gson. It’s a good time to migrate. It also has benefits like lower size, Kotlin support etc. I have migrated the code base from Gson to Moshi. Please have a look. https://github.com/ChuckerTeam/chucker/pull/272 Do let me know if any changes/improvements are required 🙂

Would like to note here as well that I did some benchmarking of JSON libs for particular Chucker use case and results aren’t that great for Moshi. While I also believed that Moshi should be a winner, it turned up not exactly like that. Here is more info: https://github.com/ChuckerTeam/chucker/pull/272#issuecomment-601911563 In case someone would like to run tests and won’t run into the mentioned issue there, please share results in that PR discussion.

We should probably discuss about this: https://github.com/ChuckerTeam/chucker/issues/56