Streamline blockchain API calls

[chuck-h]

Background The Light Wallet hits the blockchain API pretty hard during app startup (lots of ecosystem tokens, transactions, and user profiles being loaded), which makes for sluggish app start and has raised service issues https://github.com/JoinSEEDS/seeds_light_wallet/issues/1950 . Most of the information is gathered through individual requests for a single data item, while a properly formatted request could return data from many tokens or many transactions in each call. This would potentially reduce the number of API calls and startup delays by a large factor. In situations where an API call can return many rows of data, we must be prepared for it to be delivered in multiple pages.

Suggestion Observe the startup process and search the code for opportunities to make bulk data calls. Implement a common method for paging in bulk calls, and search the code for existing calls that may need paging support. Search for caching opportunities and implement them where justified.

Nik Comments

This is a result of how we handle tokens at the moment. It was never meant to do more than a handful.

Current Architecture

• Wallet retrieves token list from smart contract (token master)
• Wallet gets user balances for all tokens in the known universe (1 call per token)
• Wallet shows all token balances != 0
• Wallet renews balances of all known tokens every now and then or on pull to refresh (1 call per token) - this is because while the user may not have had a balance before, they may have received a token in the meantime, so we need to check all tokens all the time.

Suggested new architecture

• The wallet only shows a few tokens to start, and has an "edit token list" button on the top right or as a "+" card next to the tokens list.
• Each token card refreshes its contents on demand, just like any list. This means the token cards only refresh when they are visible on screen, which limits the number of simultaneous calls to around 3 or 4. Scrolling fast will still generate more calls but it's limited to the number of tokens the users has
• "Edit Tokens" screen makes a call to retrieve all known tokens in the universe from token master contract, and shows them all with on/off toggles - a standard list UI - this screen does not show balances. Only the tokens.
• When wallet renews balances on pull to refresh, it only gets balances for the tokens the user selected - typically that won't be more than 10.

So this architecture can handle an endless number of tokens with ease without hitting the throttle limits.

PS There might be another ticket on this somewhere

[chuck-h]

The list of tokens is held by the tmastr.seeds contract and is downloaded at startup. However new tokens are not added very often. We could add a "last-modified" call to tmastr.seeds and use that for refresh of a local cache. That would let us also check in occasionally for new tokens fairly efficiently if a user keeps the app open for a long time.

Update: https://github.com/JoinSEEDS/seeds-smart-contracts/commit/2eb060954338079fdb29e8f086d321a7dd0e3e97 adds a "changed_time" timestamp to the tokensmaster config table. This is not is a PR yet.

[chuck-h]

We get the list of all approved tokens and their metadata in pages so it is fairly efficient in API calls. Then we go getTokenStat on each token to find its precision. Each of these is a separate API call.

The fact is, we don't need the token precision at all until we need to generate a transfer action. So we could defer this and save a lot of startup API bandwidth.