* 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.
This helps with managing the race condition at startup where existing wallets want to show data quickly but need to wait for the synchronizer to be fully ready, which often happens slower than how long it takes the screen to draw itself.
We now take metrics on how long devices are taking to create transactions so we can begin to understand which devices are in having a bad user experience and later know precisely how much our performance improvements have helped. We also now track submission response errors to help us pinpoint when and why transactions are failing. This is very useful as the canopy grace period expires and transactions begin to not appear for some testers.
Previously, wallets would crash before launching because only the seed was stored. Now, the wallet works with only viewkeys so these older wallets need to store that value at least once. This does that and also adds troubleshooting code to try and find any similar edge cases and report on whether this work around corrected the issue. For internal use only, of course.
Previously, certain phones could press cancel to bypass biometrics. Others couldn't even enter the send flow. Google's library for this is still not stable but it has improved and the underlying issue that contributed to these bugs has been corrected.
Eljo Prifti
Mandeep
Kevin Gorham
Mandeep
zebambam