https://kotlinlang.org logo
Join the conversationJoin Slack
Channels
100daysofcode
100daysofkotlin
100daysofkotlin-2021
advent-of-code
aem
ai
alexa
algeria
algolialibraries
amsterdam
android
android-architecture
android-databinding
android-studio
androidgithubprojects
androidthings
androidx
androidx-xprocessing
anime
anko
announcements
apollo-kotlin
appintro
arabic
argentina
arkenv
arksemdevteam
armenia
arrow
arrow-contributors
arrow-meta
ass
atlanta
atm17
atrium
austin
australia
austria
awesome-kotlin
ballast
bangladesh
barcelona
bayarea
bazel
beepiz-libraries
belgium
berlin
big-data
books
boston
brazil
brikk
budapest
build
build-tools
bulgaria
bydgoszcz
cambodia
canada
carrat
carrat-dev
carrat-feed
chicago
chile
china
chucker
cincinnati-user-group
cli
clikt
cloudfoundry
cn
cobalt
code-coverage
codeforces
codemash-precompiler
codereview
codingame
codingconventions
coimbatore
collaborations
colombia
colorado
communities
competitive-programming
competitivecoding
compiler
compose
compose-android
compose-desktop
compose-hiring
compose-ios
compose-mp
compose-ui-showcase
compose-wear
compose-web
connect-audit-events
corda
cork
coroutines
couchbase
coursera
croatia
cryptography
cscenter-course-2016
cucumber-bdd
cyprus
czech
dagger
data2viz
databinding
datascience
dckotlin
debugging
decompose
decouple
denmark
deprecated
detekt
detekt-hint
dev-core
dfw
docs-revamped
dokka
domain-driven-design
doodle
dsl
dublin
dutch
eap
eclipse
ecuador
edinburgh
education
effective-kotlin
effectivekotlin
emacs
embedded-kotlin
estatik
event21-community-content
events
exposed
failgood
fb-internal-demo
feed
firebase
flow
fluid-libraries
forkhandles
forum
fosdem
fp-in-kotlin
framework-elide
freenode
french
fritz2
fuchsia
functional
funktionale
gamedev
ge-kotlin
general-advice
georgia
geospatial
german-lang
getting-started
github-workflows-kt
glance
godot-kotlin
google-io
gradle
graphic
graphkool
graphql
graphql-kotlin
graviton-browser
greece
grpc
gsoc
gui
hackathons
hacktoberfest
hamburg
hamkrest
helios
helsinki
hexagon
hibernate
hikari-cp
hire-me
hiring
hongkong
hoplite
http4k
hungary
hyderabad
image-processing
india
indonesia
inkremental
intellij
intellij-plugins
intellij-tricks
internships
introduce-yourself
io
ios
iran
israel
istanbulcoders
italian
jackson-kotlin
jadx
japanese
jasync-sql
java-to-kotlin-refactoring
javadevelopers
javafx
javalin
javascript
jdbi
jhipster-kotlin
jobsworldwide
jpa
jshdq
juul-libraries
jvm-ir-backend-feedback
jxadapter
k2-early-adopters
kaal
kafka
kakao
kalasim
kapt
karachi
karg
karlsruhe
kash_shell
kaskade
kbuild
kdbc
kgen-doc-tools
kgraphql
kinta
klaxon
klock
kloudformation
kmdc
kmm-español
kmongo
knbt
knote
koalaql
koans
kobalt
kobweb
kodein
kodex
kohesive
koin
koin-dev
komapper
kondor-json
kong
kontent
kontributors
korau
korean
korge
korim
korio
korlibs
korte
kotest
kotest-contributors
kotless
kotlick
kotlin-asia
kotlin-beam
kotlin-by-example
kotlin-csv
kotlin-data-storage
kotlin-foundation
kotlin-fuel
kotlin-in-action
kotlin-inject
kotlin-latam
kotlin-logging
kotlin-multiplatform-contest
kotlin-mumbai
kotlin-native
kotlin-pakistan
kotlin-plugin
kotlin-pune
kotlin-roadmap
kotlin-samples
kotlin-sap
kotlin-serbia
kotlin-spark
kotlin-szeged
kotlin-website
kotlinacademy
kotlinbot
kotlinconf
kotlindl
kotlinforbeginners
kotlingforbeginners
kotlinlondon
kotlinmad
kotlinprogrammers
kotlinsu
kotlintest
kotlintest-devs
kotlintlv
kotlinultimatechallenge
kotlinx-datetime
kotlinx-files
kotlinx-html
kotrix
kotson
kovenant
kprompt
kraph
krawler
kroto-plus
ksp
ktcc
ktfmt
ktlint
ktor
ktp
kubed
kug-leads
kug-torino
kvision
kweb
lambdaworld_cadiz
lanark
language-evolution
language-proposals
latvia
leakcanary
leedskotlinusergroup
lets-have-fun
libgdx
libkgd
library-development
linkeddata
lithuania
london
losangeles
lottie
love
lychee
macedonia
machinelearningbawas
madrid
malaysia
mathematics
meetkotlin
memes
meta
metro-detroit
mexico
miami
micronaut
minnesota
minutest
mirror
mockk
moko
moldova
monsterpuzzle
montreal
moonbean
morocco
motionlayout
mpapt
mu
multiplatform
mumbai
munich
mvikotlin
mvrx
myndocs-oauth2-server
naming
navigation-architecture-component
nepal
new-mexico
new-zealand
newname
nigeria
nodejs
norway
npm-publish
nyc
oceania
ohio-kotlin-users
oldenburg
oolong
opensource
orbit-mvi
osgi
otpisani
package-search
pakistan
panamá
pattern-matching
pbandk
pdx
peru
philippines
phoenix
pinoy
pocketgitclient
polish
popkorn
portugal
practical-functional-programming
proguard
prozis-android-backup
pyhsikal
python
python-contributors
quasar
random
re
react
reaktive
realm
realworldkotlin
reductor
reduks
redux
redux-kotlin
refactoring-to-kotlin
reflect
refreshversions
reports
result
rethink
revolver
rhein-main
rocksdb
romania
room
rpi-pico
rsocket
russian
russian_feed
russian-kotlinasfirst
rx
rxjava
san-diego
science
scotland
scrcast
scrimage
script
scripting
seattle
serialization
server
sg-user-group
singapore
skia-wasm-interop-temp
skrape-it
slovak
snake
sofl-user-group
southafrica
spacemacs
spain
spanish
speaking
spek
spin
splitties
spotify-mobius
spring
spring-security
squarelibraries
stackoverflow
stacks
stayhungrystayfoolish
stdlib
stlouis
strife-discord-lib
strikt
students
stuttgart
sudan
swagger-gradle-codegen
swarm
sweden
swing
swiss-user-group
switzerland
talking-kotlin
tallinn
tampa
teamcity
tegal
tempe
tensorflow
terminal
test
testing
testtestest
texas
tgbotapi
thailand
tornadofx
touchlab-tools
training
tricity-kotlin-user-group
trójmiasto
truth
tunisia
turkey
turkiye
twitter-feed
uae
udacityindia
uk
ukrainian
uniflow
unkonf
uruguay
utah
uuid
vancouver
vankotlin
vertx
videos
vienna
vietnam
vim
vkug
vuejs
web-mpp
webassembly
webrtc
wimix_sentry
wwdc
zircon
Powered by Linen
chucker
  • g

    gammax

    01/02/2020, 4:39 PM
    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
    v
    • 2
    • 3
  • o

    Olivier

    01/03/2020, 12:42 PM
    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.
    👍 1
    v
    g
    • 3
    • 4
  • o

    Olivier

    01/03/2020, 12:42 PM
    Thread about #141
    g
    v
    • 3
    • 8
  • v

    Vova Buberenko

    01/03/2020, 5:29 PM
    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.
    g
    • 2
    • 1
  • v

    Vova Buberenko

    01/03/2020, 6:53 PM
    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
    g
    • 2
    • 2
  • v

    Vova Buberenko

    01/07/2020, 7:23 PM
    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.
    g
    • 2
    • 1
  • v

    Vova Buberenko

    01/09/2020, 10:17 AM
    ☝️ 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.
    ❤️ 1
    g
    • 2
    • 1
  • v

    Vova Buberenko

    01/12/2020, 8:06 PM
    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/
    g
    • 2
    • 1
  • v

    Vova Buberenko

    01/13/2020, 5:48 AM
    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).
    g
    • 2
    • 1
  • c

    Colton Idle

    01/23/2020, 8:03 AM
    Excited for
    3.1.0
    ! Great work!
    🙏 2
    g
    • 2
    • 1
  • g

    gammax

    01/23/2020, 1:32 PM
    @Vova Buberenko should be pull the trigger? 🚀
    v
    • 2
    • 3
  • v

    Vova Buberenko

    01/24/2020, 9:09 PM
    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.
    g
    c
    • 3
    • 2
  • g

    gammax

    01/24/2020, 10:25 PM
    Going to try my branch out of curiosity. Anyway looks like JitPack doesn't like too many
    /
    in the branch name
    v
    • 2
    • 2
  • c

    Colton Idle

    01/24/2020, 10:42 PM
    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.
    g
    • 2
    • 3
  • v

    Vova Buberenko

    01/24/2020, 10:46 PM
    @gammax Trying to get your fix, but no luck. Copied version from JitPack
    g
    • 2
    • 3
  • g

    gammax

    01/24/2020, 11:17 PM
    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
    v
    • 2
    • 2
  • g

    gammax

    01/24/2020, 11:57 PM
    @Vova Buberenko can you take care of the release notes change? Or should I do it?
    v
    • 2
    • 1
  • g

    gammax

    01/25/2020, 12:43 AM
    I've updated the PR. Now it consistently fail/succeed on the sample app
    v
    • 2
    • 1
  • m

    MiSikora

    02/10/2020, 5:26 PM
    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?
    p
    • 2
    • 2
  • g

    gammax

    02/20/2020, 8:23 PM
    Hey @Vova Buberenko 👋 Are you taking care of #233 and #246 or should I do them?
    v
    • 2
    • 4
  • c

    Colton Idle

    02/21/2020, 2:00 AM
    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.
    v
    • 2
    • 1
  • v

    Vova Buberenko

    02/26/2020, 8:14 AM
    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.
    g
    • 2
    • 2
  • g

    gammax

    02/29/2020, 9:54 PM
    Hope it’s not a problem.
    v
    • 2
    • 1
  • g

    gammax

    02/29/2020, 9:55 PM
    Maybe someone else from the community can pick this up 😄 @Benoit Vermont @Olivier
    m
    • 2
    • 1
  • v

    Vova Buberenko

    03/04/2020, 10:02 AM
    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
    g
    • 2
    • 2
  • n

    Nikhil

    03/06/2020, 6:38 PM
    any plans to migrate to kotlin coroutines ?
    m
    v
    • 3
    • 16
  • h

    Hitanshu Dhawan

    03/11/2020, 6:40 AM
    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 🙂
    v
    • 2
    • 7
  • v

    Vova Buberenko

    03/20/2020, 9:19 PM
    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.
    g
    h
    • 3
    • 6
  • g

    gammax

    03/21/2020, 6:27 PM
    We should probably discuss about this: https://github.com/ChuckerTeam/chucker/issues/56
    k
    v
    s
    • 4
    • 17
  • p

    psh

    03/21/2020, 9:24 PM
    I notice that https://github.com/ChuckerTeam/chucker/pull/270 will introduce coroutines into Chucker for processing payloads off the main thread. Would you be on board with an issue suggesting we carry that refactor a few steps further by moving away from
    LiveData
    in the HttpTransactionDao and moving to Flow + suspend functions, and only expose the result to the GUI (in MainViewModel) using
    LiveData
    ?
    g
    m
    v
    • 4
    • 6
Powered by Linen
Title
p

psh

03/21/2020, 9:24 PM
I notice that https://github.com/ChuckerTeam/chucker/pull/270 will introduce coroutines into Chucker for processing payloads off the main thread. Would you be on board with an issue suggesting we carry that refactor a few steps further by moving away from
LiveData
in the HttpTransactionDao and moving to Flow + suspend functions, and only expose the result to the GUI (in MainViewModel) using
LiveData
?
g

gammax

03/22/2020, 10:22 AM
I have to admit, that I’m also a bit hesitant in moving to coroutines. Every third party dependency that we add (coroutines, LiveData, Flow, etc.) is posing more complexity/resolution time on the end user. On the other hand moving to Flow sounds like a potential way to be up to date with the development standards. I don’t think I’m the right person to give a final call here honestly, but happy to discuss.
m

MiSikora

03/22/2020, 2:19 PM
My 5 cents here. Personally I’d love to see
LiveData
being dropped or at the very least used only on the
ViewModel
layer. Aside from other problems, using it for anything else is really painful as it does not provide a good way to do intermediate background work and requires strange solutions like this one - https://github.com/ChuckerTeam/chucker/blob/bee88133909a3daa42d9eca7516aafd8a0a68487/library/src/main/java/com/chuckerteam/chucker/internal/support/LiveDataUtils.kt#L46.
v

Vova Buberenko

03/22/2020, 7:32 PM
From my point of view we should do this further migration. The only point here - let’s do splitting of
Transaction
into
Response
and
Request
first as discussed here https://github.com/ChuckerTeam/chucker/issues/259 and think about introducing Flow after. P.S. I am both glad and not that we are getting so mush attention and contributions from the community, since we have a lot of cool things which move library forward, but at the same time we have too many contributions in different directions, which make it quite hard to align everything right in terms of some uniform approach / architecture.
g

gammax

03/22/2020, 11:17 PM
I am both glad and not that we are getting so mush attention and contributions from the community,
Seems like getting that
ROADMAP.md
file in the root could be useful now. This will help people to align with the long term vision.
v

Vova Buberenko

03/22/2020, 11:39 PM
It is my fault that I promised to create a project board quite a long time ago and constantly delayed it. Will fix that ASAP and we will have priorities here as well.
g

gammax

03/24/2020, 12:26 AM
It is my fault that I promised to create a project board quite a long time ago and constantly delayed it
I was not pointing finger 😅 It was more like: we should definitely define a roadmap somehow and get a guideline also for external contribs. That would be really helpful to provide pushbacks on “wild” PRs.
View count: 6