After a transaction was sent, the old value would linger. That's fine in the case of a failure so the user can try again but it is not okay after completing a transaction. The issue was that the fragment was staying in memory and it's UiModel was still available. The fix is to let the SendViewModel be the source of truth about what amount the user has entered.
Previously, it would chop off the last transaction which happens to be what users are most interested in seeing. This was happening because the scroll was being called before the list contents were fully loaded from the database so we were scrolling to the top of an empty list.
This is important because sync times are getting longer, every day. If users can see and input a more accurate birthday, then they will have dramatically improved sync times.
Addresses #183 but still allows the UI to show things as it did, before. We removed the aggressive address parsing because it is not necessary and might lead to vulnerabilities.
Avoids shell injection by verifying that the supplied value is a file. Also allows for spaces in the file path, which probably fixes certaind devices that were crashing when trying to open logs.
Whenever something is scanned that is not a proper address for the given network, the user will be presented with that value and an error message. This requires a bit of additional support in the SDK but, for now, a workaround is enough.
Replaced doBeforeTextChanged and doAfterTextChanged calls with a TextWatcher
Moved the limitDecimalPlaces code to the EditText ext
Implemented uniform currency formatter functions
Hugely simplified limitDecimalPlaces code
This fixes all cases related to the user's locale
Adds a zero in front of the amount if dot is entered on the send screen
Prevents and removes odd leading zeroes in the address text input on the send screen
- clarify that this is maintained by ECC
- delete duplicate sentence about the wallet threat model (kept in the disclaimers, deleted in the intro).
- delete "Traffic analysis, like in other cryptocurrency wallets, can leak some privacy of the user." --we agreed that we didn't want to give off the impression that our wallet is worse than other apps, when it is actually better for privacy.
- delete "We recommend backing up your seed and using this with amounts of funds..." --we reiterate that this is not a product, and Taylor has looked at our code enough to feel confident about our wallets not losing funds.
- delete "We aim to make it as beautiful as it is useful. Internally, we will continue to extensively use it to innovate and interate on everything from [protocol changes](https://electriccoin.co/blog/introducing-heartwood/) to [lottie animations](https://lottiefiles.com/popular). Of course, Zcash has a strong history of being open-source, even when it's difficult. It would be easier to keep this internal-only so that we could fill it with crash-reporting and feedback tools but, instead, we decided to disable those things and make it available as a community resource." -- this takes away from the point that this is only for dogfooding, and that this is not a product.
Addresses https://github.com/zcash/zcash-android-wallet/issues/143 by placing everything behind a user setting that can be enabled in the future by users who want to continue helping us improve the user experience. For the most part, this will just be turned on for internal company releases in order to continue learning and improving the app.
Kevin Gorham
Hlib
Linda Lee