The root issue seemed to be, if a keyboard was shown for a focused EditTextView that was also disabled, older versions of android would crash inside the input manager which was impossible to catch with a try/catch block. The end result was major: some users could not restore their wallets. This work around addresses the problem by keeping the focused view enabled at all times. In theory this could result in some weird behavior but in practice, that's unlikely.
Allow a user to correct common errors by rewinding the chain and scanning again. We provide 3 options: quick - the shortest possible rescan that can occur, based on witnesses. full - rescan all the way back to the wallet's birthday. wipe - delete all sqlite database and begin again from the moment after the user entered their seed phrase.
The SDK now provides hooks for receiving a callback whenever a scan completes that includes information about the number of blocks scanned and duration. Use this info to report device metrics around scan speeds. This is in anticipation of greatly improving these numbers in the near future. Before that, we want to start collecting a baseline measurement.
This is one of the metrics that we want to collect internally at ECC over the term to see how user sentiment changes for the next several months as we work to add a lot of features and improvements.
The intention of this feature is to provide a way for adding the minimum viable implementation of t-addr support. Effectively, just enough to get transparent funds into the wallet's shielded pool. Robust management of UTXOs is and should be outside the scope of a shielded wallet.
Mainly involves using a network parameter rather than a separate build for testnet and mainnet. This network object is also now the source of the SAPLING_ACTIVATION_HEIGHT, which varies by network. The other major change is the way wallet initialization works, particularly around viewing keys. Under the hood, this involves a database migration so it is worth testing the upgrade path.
* New design for Wallet History
* History Row designed
Colour combinations used to design History row as per comment in same branch
Co-authored-by: Mandeep <bhalothiamandeep@gmail.com>
After looking at this more closely, it's clear that a refactor would help so that the view model drives the logic. However, that change is bigger than the scope of this work so I'll save it for an enhancement and just do this small change, instead.
Primarily a developer feature to warn when a local build of the SDK is broken because the Rust libraries did not properly link, which happens occasionally and can be frustrating but should never be seen by an end user. In the event that a broken build does make it to a user, this would at least improve the experience.
There was a logic error that caused the load screen to cover the create/restore screen because the load screen was waiting for the synchronizer to start but it would not start until after the wallet was created (or restored). The simple fix was to turn off the load screen during the create/restore flow and then reactivate it, if needed while creating the syncrhonizer. In almost all cases, users will not see the load screen. However, when there is a race condition and the homescreen attempts to draw before the synchronizer is ready, it will now display a load screen instead.
Existing users of seed-only wallets were getting stuck because the birthday is now stored differently. The previous fix was attempting to just load the latest checkpoint as the birthday but this does not work because the birthday determines how far back the wallet will rewind during a reorg. The end result prevented the wallet from going back as far as it needed. When the birthday isn't known, it makes logical sense to set it to the lowest possible number: Sapling Activation. This also happens to fix the problem because now wallets that are upgrading can rewind beyond the latest checkpoint.
Kevin Gorham
Eljo Prifti
Mandeep
Mandeep
zebambam