Thanks for the review @AmandaRiu! I've addressed your comments in code and some answers to your questions here:

what is the isEndless property of the ShowSnackbar event for and where is it being handled?

It was supposed to be a flag for showing an indefinite snackbar but it's not really useful so I removed it.

It looks like some padding needs to be added below the ::Next:: button on this screen. You don’t really notice it in portrait mode, but in landscape mode it feels very crunched

Fixed.

The Product refund total amount doesn’t align with the right edges of the totals above it, and the button doesn’t align on the left and right edges with the rest of the items.

Fixed.

The total amount color doesn’t match the design which shows it should be #3C3C3C:

Please ignore this for now. The amount text view is actually a button from the original design, which we decided to remove. The actual amount dialog is implemented in one of the following PRs and eventually disabled in the last one. So the correct color can be verified then.

The docs also recommend using a popup contextual menu instead of a dialog since it’s less disruptive and isn’t modal. If the user clicks outside of the menu it just dismisses.

I'm not sure a number picker view inside a context pop up menu would work. It's scrollable and the pop up view would need to be large enough so that it'd be easy to change the value. I guess the whole thing could be converted into a list but if there were a lot of items it could become very long. We can discuss it further if you like but if do decide to change it, let's do it in a separate PR. What do you think?

Ready for another round of review :).

@0nko finished another round. Made a comment in the code about ConstraintLayout. Also the following:

• When processing a refund that has a discount, the discount section is hidden until the user selects an item for refund. Is this intentional?
• I don’t see the option to refund shipping that were in the designs. Is this intentional?

• The parentheses around the discount items from the design are missing
• Should the select all button convert to a select none option once clicked?

When processing a refund that has a discount, the discount section is hidden until the user selects an item for refund. Is this intentional?

Sort of, because not all orders contain discounts. But after thinking about it, it doesn't make sense to show discounts in refunds because items already have the discount included in the price -- this is done by the API (for example, if you have an order of 2 items for $10 each and a discount for $2, the actual price for an item in the refunds would show $9). The user might be confused why the discount amount isn't applied in the total summary, so I removed that line altogether.

I don’t see the option to refund shipping that were in the designs. Is this intentional?

Yeah. We've discovered the API doesn't support shipping refunds. But I already implemented the feature by that time. Because of this, #1623 does show it (a stub) so that it can be reviewed. It's then hidden in the next PR. I kept the code so that it can be used once the API supports it.

Should the select all button convert to a select none option once clicked?

I've implemented this in #1633 to avoid unnecessary refactoring.

The user might be confused why the discount amount isn't applied in the total summary, so I removed that line altogether.

I totally agree. It confused me. I was referring to the discount being hidden even for an order that has a discount applied - it unhides itself after you select an item for a refund.

Yeah. We've discovered the API doesn't support shipping refunds. But I already implemented the feature by that time. Because of this, #1623 does show it (a stub) so that it can be reviewed. It's then hidden in the next PR. I kept the code so that it can be used once the API supports it.

👍

I've implemented this in #1633 to avoid unnecessary refactoring.

👍

But after thinking about it, it doesn't make sense to show discounts in refunds because items already have the discount included in the price -- this is done by the API (for example, if you have an order of 2 items for $10 each and a discount for $2, the actual price for an item in the refunds would show $9). The user might be confused why the discount amount isn't applied in the total summary, so I removed that line altogether.

NM - I see you have this removed now.