Empty state for payloads #325
Conversation
| // Invalidating menu, because we need to hide menu items for empty payloads | ||
| requireActivity().invalidateOptionsMenu() | ||
|
|
||
| payloadBinding.loadingProgress.visibility = View.GONE |
There was a problem hiding this comment.
I'm not really sure what is going here. Why is this view first set to VISIBLE and then to GONE in the same lambda?
There was a problem hiding this comment.
It is a ProgressBar. We show it when trying to fetch the payload and hide when it is fetched.
There was a problem hiding this comment.
But is it suspended or something? Wouldn't it result always in GONE since the code is executed in one function?
There was a problem hiding this comment.
No, it works fine with showing progress on screen opening and hiding it properly.
There was a problem hiding this comment.
Ahh… I checked the code out in the IDE. Process payload suspends so it allows for changing progress visibility. Too bad it is not that obvious via GH. :(
...y/src/main/java/com/chuckerteam/chucker/internal/ui/transaction/TransactionPayloadAdapter.kt
Show resolved
Hide resolved
library/src/main/res/layout/chucker_fragment_transaction_payload.xml
Outdated
Show resolved
Hide resolved
.../src/main/java/com/chuckerteam/chucker/internal/ui/transaction/TransactionPayloadFragment.kt
Outdated
Show resolved
Hide resolved
Co-Authored-By: Nicola Corti <corti.nico@gmail.com>
|
What about the idea of moving |
Yeah definitely 👍 Are you going to take care of this? |
|
Yes |
📷 Screenshots
📄 Context
This PR closes #276 by checking request or response payload and showing corresponding state in case any of them is empty.
📝 Changes
TransactionPayloadAdateris declared and gets its items.RecyclerViewtoonViewCreated, so we could get rid of logcat messagesNo adapter attached.📎 Related PR
This PR would require some updates in #305 and #323, since there were changes in same classes.
⏱️ Next steps
While working on this PR I came to conclusion that we should move
processPayloadmethod toTransactionViewModel, because it is left from times when we had noViewModels at all and because transformation of items into view items looks like a job forViewModel.However, I would postpone it till #305, #323 and my planned PR with search improvement gets merged to avoid too much updates requirements for those PRs.