* Create SaplingParamTool.kt class
add clear and validate function
* add new line
* add SaplingParamToolTest.kt class
* fix PR request
* replace with one single line comment
* revert grandle at exact point in time
* revert build grandle to master
* align build.grandle file with the master one
* align with master
Most notably, this enables ZIP-313 and reduced fees. For now, we've pinned to a commit on master. Eventually, we will point to crate.io versions once the release process is better defined.
* Clear the warns build
* Supress inline CurrencyFormatter.kt and Twig.kt
Add FlowPreview into bulild.grandle
Minor change
* Add supres inline at the file level
* Add suppress inline at the file level
Make it easier to restore wallets without knowing their birthday. Those wallets will sync from SaplingActivation without the developer having to hardcode that height into their wallet. We achieve this by allowing the Initializer Config object to specify what to do when the birthdayHeight is null. In general, it is probably easier to use the importWallet and newWallet functions to achieve the same goal with more clarity.
Builder was misnamed. It is moreso a configuration object. Making this change simplified some of the more confusing aspects of creating an initializer and also made it so the initializer.config.new functions can now work as expected. Prior to these changes it was difficult to make an initializer that used a new birthday.
- Exposed primary constructor in initializer and added more convenience functions
- Fix: error handler not being passed through when changing server
- New: warn developer when a critical error occurs but is not covered with a callback
- New: Typed exceptions for missing birthday or viewingKey values during initialization
- New: updated default server for checkpoint tool
The new API for initializing with a viewing key will support all existing uses of the other initializer. So they can be safely merged and the changes to support the new one are fairly straight forward.
Also, iterated on the design of the Initializer to simplify construction and make the API easier to use.
Simplify the builder and also allow it to be a stand-alone configuration item, which would be more useful to React apps that cannot use Kotlins receiver function syntax.
- Extracted parent interface
- Created ViewingKey Initializer to start synchronizing without the seed (only the viewing key is needed)
- Extracted tools from the existing initializer and simlified it a bit
This is an example of a jni call that accepts and returns proto objects. Ultimately, this trades a minor amount of performance for a significant improvement of ease of use. By exchanging protocol buffers, the Kotlin and Rust layers are able to communicate using far more complex objects. Eventually, this type of approach might completely replace the use of a database or sqlite.
Kevin Gorham
Kris Nuttycombe
Adí
Eljo Prifti
Jack Grigg