-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Improve navigation structure #6135
Improve navigation structure #6135
Conversation
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 reviewed only small part of this pull request for now. Let me know what do you think about proposed changes. I'm okay if you disagree with them, however I will be very pleased if they will be introduced :)
@@ -502,6 +506,114 @@ public static void setBaseCurrencyCode(String baseCurrencyCode) { | |||
return currencies; | |||
} | |||
|
|||
public static List<TradeCurrency> getAllInteracETransferIdCurrencies() { |
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.
What about creating static field with supported currencies in InteracETransferAccount
instead:
//...
public final class InteracETransferAccount extends PaymentAccount {
public static final List<TradeCurrency> SUPPORTED_CURRENCIES = List.of(new FiatCurrency("CAD"))
//...
also for other account types (Strike, TikkieId etc.).
As a alternative add SUPPORTED_CURRENCIES
into PaymentMethod
instead of PaymentAccount
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.
Yes, I agree that it would make more sense to move this information closer to the Domain. I didn't spend too much time yet on bigger refactorings to prevent too many unexpected side effects by changing too much. But yes, I think moving it the PaymentMethod would make sense. Although it is a 1:1 relationship all the time AFAIK, but I think it would be a better fit for the PaymentMethod, which is used by the Payment Account.
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.
After looking at the code, I revert my opinion and also think adding it to the concrete account implementation is the better way to do this.
@@ -106,6 +113,114 @@ public static boolean isPaymentAccountValidForOffer(Offer offer, PaymentAccount | |||
return acceptedCountryCodes; | |||
} | |||
|
|||
public static List<TradeCurrency> getTradeCurrencies(PaymentMethod paymentMethod) { |
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 think this method breaks open-closed principle. Refactoring steps suggestion:
- make
PaymentMethod
abstract class, and create dedicated classes, f.e.:
public class SepaPaymentMethod extends PaymentMethod {
public SepaPaymentMethod () {
super("SEPA", 6 * DAY, DEFAULT_TRADE_LIMIT_HIGH_RISK);
}
}
- use created classes in constructors of every
PaymentAccount
, f.e.:
public SepaAccount() {
super(new SepaPaymentMethod());
}
- To generate list of supported payment methods use similar approach like in
AssetRegistry
:
static {
for (PaymentAccount account : ServiceLoader.load(PaymentAccount.class)) {
registeredAccounts.add(account);
}
}
public Stream<PaymentMethod> getAvailablePaymentMethods() {
return registeredAccounts.stream().map(account -> account.getPaymentMethod());
}
- maybe instead loading
PaymentAccount
instances we should loadPaymentMethod
instances - see point 5
-
Add
List<TradeCurrency> getSupportedCurrencies()
intoPaymentMethod
-
PaymentMethod
<->PaymentAccount
seems to be 1:1 relationship. I think it could be used to additional refactoring. f.e. to replacePaymentAccountFactory
(which also breaks open-closed principle) withpaymentMethod.createAccountInstance()
WDYT ? It could be big refactoring, I didn't analyzed how many changes in codebase it could induce.
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 agree in general with your comment, but this will be a hell of a refactoring and testing. I'd keep it for a separate effort to not completely blow this PR out of proportion.
…ifferent assets Still missing correct create and take offer handling
if currency does not support previous selected payment method in a different currency.
eb010e7
to
a8189d7
Compare
and fix lots of minor issues
take-offer-to-sell-bsq.movcreate-offer-to-buy-xmr.movbasic-navigation-walk-through.mov |
Checked it out, looks good! (Some niggles need ironing out).
|
Thanks for testing - I'll look at the BSQ Swap issue you experienced in more detail. It did work for me, so it is kind of weird. I'll post an update today as soon as I'm through with my testing. @Market View: It can be that there is an issue. I only fixed the behavior on the buy/sell buttons, but not on the triggers in each row. Quite a bit of changes this change caused in the end 😅 |
@jmacxx I just tested it again to create a Buy BSQ and a Sell BSQ offer using BSQ Swaps and it worked as expected for me. Is there a specific flow you used to generate this issue? The only case where this could happen IMO is that BSQ Swap didn't switch to the BsqSwapCreateOfferView in your case using the regular CreateOfferView. |
I'll try it with a fresh account without any Altcoin accounts next. Maybe that causes this weird behavior. |
Otherwise it would display the old 'Buy BTC' and 'Sell BTC' navigation
Ok - now I'm able to reproduce the issue. It is as I expected caused with a fresh account with only one BSQ account. |
@jmacxx Just fixed your issue with 1712f74 |
I'm probably already quite blind by all these changes, but I haven't found anything obvious anymore comparing it with v1.8.4 on Mainnet. I'll proceed with the one open refactoring and might do some performance optimizations and clean-ups (and create some new bugs of course 🤪 ) |
Found one "not obvious" kind of issue - preferred currency set to crypto has impact to fiat logic:
Sorry for being pain 🥺 |
No worries! Better you find the bug than users. Should be fixed now. |
After doing some Mainnet tests I found some more edge cases with the preferred currency, which needs some minor improvements - will do it tomorrow. |
de9be4c
to
89926d1
Compare
I think it is now in a state ready for a final review testing @jmacxx @xyzmaker123 There is one UX problem IMO opinion that needs to get solved which we have already for a long time and I'm not 100% sure how we want to solve it best. Let's assume you want to buy XMR. But all those offers doesn't fit your need and you want to create an own offer to buy XMR. So what would you expect now? ATM for a new user we close the popup show a notification that you can manage your offers in portfolio. If you close this notification and/or are an existing user it will bring you back to the list of XMR offers that can be bought. But of course there is not your offer visible as it is under Sell > XMR as you created an offer to buy XMR. Shall we navigate the user instead to the buy XMR offers under Sell > XMR instead? @UX-P What is your take on this? |
@ripcurlx looks good! Also, in regards to the create offer screen, instead of 'choose trading account' could the header text read ' Create offer' so that it is clear to the user they are now creating an offer. |
ACK - I created a few offers on regtest, took them etc. and everything worked okay. Also tested scenarios that has issues before, and now everything is okay. Good job! |
Sure - I can do the same for "Take offer" as well. I'll adapt the navigational behavior as well. |
389aeb9
to
4447435
Compare
@UX-P It will now look like this: |
If it is a crypto currency and not a fiat currency
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.
ACK - based on #6135 (comment)
Based on #6092 this is the PR that implements all required changes.
I hope I have covered everything, but it is a lot of testing.
Anyone who wants to give it a shot and provide feedback is more than welcome.
This PR also includes improvements in other areas as well (e.g. only Payment methods are shown in filter for selected currency) and many more.