-
-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix UI for emtpy body in request/response #562
Conversation
val text = requireContext().getString(R.string.chucker_body_empty) | ||
result.add(TransactionPayloadItem.BodyLineItem(SpannableStringBuilder.valueOf(text))) | ||
} else { | ||
if (!isBodyPlainText) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be handled in a different way. Otherwise non-blank bodies that are not plain text but decoded from a different format will not show. This can be checked with a Postman proto echo call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you are right, just checked. Not sure how we can handle it elegantly, since we also need to understand whenever the content is decoded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, I'm getting it now. There's one thing I didn't consider when refactoring in #543. isBodyPlainText
was true
by default before (same for responses in #554), so it breaks here.
I'm not sure how to proceed with it. IMHO setting property that body is plain text when there is no body was a bug but this complicates things because we can't do check like this.
when {
isImage -> showImage()
bodyIsNotEmpty -> showBody()
bodyIsPlainText -> showEmptyText()
else -> showEncodedText()
}
Maybe the best way would be to have isBodyEncoded
property instead of isBodyPlainText
? This way combination of conditions should work properly I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isBodyEncoded
would work, I believe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it is something for a follow up PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind fixing it in another PR but wouldn't this make this PR just trade one bug for another?
After typing it I guess not. It will be just removing new functionality, so I'm ok with doing it in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might misunderstood you initially, because I thought that you want to deal with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind dealing with it. I just want get it fixed one way or the other. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, merging this one. Let's discuss that other fix in Slack.
Whoops! Thanks for catching that. I should have been more careful when changing |
📷 Screenshots
Before:
After:
📄 Context
Looks like #555 introduced a bug with payload UI. All empty bodies started to show
encoded or binary body omitted
string while they should be empty. Except fixing this I added a string resources to show in empty bodies transactions, like we do when trying to share transactions.📝 Changes
TransactionPayloadFragment
.🚫 Breaking
Nothing
🛠️ How to test
Run sample app and check some transactions with emtpy requests/responses
⏱️ Next steps
I thing I found one more bug introduced by #555, but want to check how Chucker behaved in
3.4.0
to understand if it is really something new.