85 Remove swap/buy for non-FLOW assets on Flow Wallet mobile

[jeden]

Related Issue

Outblock/FRW#85

Summary of Changes

Need Regression Testing

• Yes
• No

Risk Assessment

• Low
• Medium
• High

Additional Notes

N/A

Screenshots (if applicable)

N/A

[lmcmz]

Let's create a new TokenManager class instead of mixing Token and Wallet up.

[jeden]

Creating a separate class would require major refactoring, as its implementation references the two coin collections, which are defined and used in the wallet manager.
To be clear, this is feasible (and highly recommended), but not in the available time frame.

However, having a separate interface for token-related processing contributes to the separation of concerns, even if, under the hood, the implementation belongs to another manager. From a consumer point of view that is irrelevant.

[jeden]

GIven the changes described below, the TokenManager does not exist anymore

[lmcmz]

Let's just check the token id only

[lmcmz]

The best way to check this, is add inga enum in TokenModel which have .evm and .cadence.
Cause those token fetch from different endpoint, we know if they are EVM or Cadence at the beginning.

FRW-iOS/FRW/Foundation/Model/WalletModels.swift

Lines 90 to 101 in f3c15ff

	struct TokenModel: Codable, Identifiable, Mockable {
	let name: String
	var address: FlowNetworkModel
	let contractName: String
	let storagePath: FlowTokenStoragePath
	let decimal: Int
	let icon: URL?
	let symbol: String?
	let website: URL?
	let evmAddress: String?
	var flowIdentifier: String?
	var balance: BigUInt?

[jeden]

I could add a new field, but there are some issues:

• Decoding of existing items (such as cached) will inevitably fail unless a default value is provided
• To avoid the decoding failure, probably a manual implementation of encoding and decoding are required
• There is at least one case where the type is unknown when using CustomToken, which is then converted to TokenModel.

I can't say if the type is relevant in the CustomToken case (if it is, then the new field should be optional), however I believe this is not a piece of information that belongs to the token itself, because it does not come from the source where the data is retrieved, but it is injected thereafter. A container should hold that information, which is actually what is currently done by using two separate collections.

However, If you believe this is needed, I can do it, but I need some clarifications to the three issues I mentioned above.

[jeden]

Ok maybe I have found a way, I'll push a new commit shortly

[jeden]

@lmcmz pls take a look at this commit and let me know if it makes sense. If not, I'll revert.