[WCM] Detect installed wallets

[radeknovis]

No description provided.

[alexander-lsvk]

Just food for thought:
A long time ago I tried to solve the problem with the manual editing of supported wallet lists and stopped at some point. I'm not sure whether it makes sense at all, but maybe you will find it useful and polish it into a solid solution.

It is possible to modify LSApplicationQuerySchemes on compile using some script i.e.

BASE_PLIST="${SRCROOT}/WalletApp/Other/Info.plist"

/usr/libexec/PlistBuddy -c 'Add :LSApplicationQueriesSchemes array' "$BASE_PLIST"
/usr/libexec/PlistBuddy -c 'Add :LSApplicationQueriesSchemes: string metamask' "$BASE_PLIST"
/usr/libexec/PlistBuddy -c 'Add :LSApplicationQueriesSchemes: string trust' "$BASE_PLIST"
/usr/libexec/PlistBuddy -c 'Add :LSApplicationQueriesSchemes: string showcase' "$BASE_PLIST"

If you want to support this list dynamically (explorer api what not) it is also possible to request them while building, smth like:

WALLETS_SCHEME=${TEMP_DIR}/wallets-scheme.json
BASE_PLIST="${SRCROOT}/WalletApp/Other/Info.plist"

curl -o $WALLETS_SCHEME https://walletconnect.com/wallets-scheme.json

jq -c '.[]' $WALLETS_SCHEME | while read scheme; do
    /usr/libexec/PlistBuddy -c 'Add :LSApplicationQueriesSchemes: string $scheme' "$BASE_PLIST"
done

For developers, it will be enough to add the script above to Build Phases

[radeknovis]

This is probably a great way how to deal with it forward, but for now, we are sticking to simple solution and mentioning it in docs that in order to detect installed wallets they need to populate these LSApplicationQueriesSchemes

[alexander-lsvk]

I feel that ModalViewModel is going to be a bit overloaded with this "Recent Wallets" logic and it looks a bit like a good place for potential bugs because of sorting/comparing/adding/moving/removing. I do not claim that there are bugs, but I would use more stable solution for such a task as LRU Cache algorithm.

You can create a separate object, which will be responsible for storing and handling recent objects limited by capacity, and add some tests to make sure this always works as expected.

But it's not mandatory, just another food for thought 😁

[radeknovis]

I moved some of the logic to the RecentWalletsStorage object and tidied up the sorting logic to be more declarative.

[flypaper0]

as I understand every sort iterations: sortByOrder, sortByInstalled ... will trigger UI update es wallets is @published. Is here any was to do it in one UI update?

[radeknovis]

Actually, since it is in a single computed property like this, which does not sort in place but returns a new ordered sequence, it should trigger a single UI update once it orders everything.

var filteredWallets: [Listing] {
        wallets
            .sortByOrder()
            .sortByInstalled()
            .sortByRecent()
            .filter(searchTerm: searchTerm)
}

One concern might be that we are doing unnecessary iterations since order and installed won't change, so I will extract those to run only once.

[flypaper0]

we already have wallet instance here, why we need to search wallet by id in setLastTimeUsed again?

[radeknovis]

The wallet instance here is the one loaded from UserDefaults, while the one I'm matching in setLastTimeUsed is part of my wallets state property.

[flypaper0]

Could you explain why we are storing without lastTimeUsed please?

[radeknovis]

It should never happen that we store it without lastTimeUsed, so I've added this just as an extra check If we ever do.

[arein]

@ignaciosantise how did you solve this?

[ignaciosantise]

dapps will have to modify their info.plist/android manifest manually to support the feature: https://docs.walletconnect.com/2.0/advanced/walletconnectmodal/about#for-ios