Hey, before I continue with decoded/encoded urls I...

# chucker

[MiSikora]

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?

[psh]

At Kotlin Conf 2018 (link:

https://youtu.be/Rvx_BfG3NDo?t=1839▾

) Aaron Sarazan gave a talk “Next Level DSLs” where he points out that builders are 100% compatible with DSLs, and can lead to a DSL later. Java users will always be able to use the builder and Kotlin users can use the extra syntactic sugar of the DSL. Given that issue #141 is currently a step too far, I (personally) think that a builder would be a step in the right direction.

Question for you - is the context a requirement of the interceptor step or the data storage step? If they are initialized separately, is it possible to eliminate the context parameter from the OkHttp interceptor construction and move it to the initialization of Chucker’s data storage?

[MiSikora]

Yes, I agree that the first step should be a builder. And add a DSL on top of it as a next step.

ChuckerInterceptor being tied to Android also bugs me. I want to create an issue or a draft PR to discuss this at some point in the future, but I’m waiting at the moment for some other PRs before proceeding with something as big as making Chucker platform independent.