It is important to be very explicit about the network and not make any assumptions for ease of use because that resulted in numerous bugs while transitioning away from the old two library setup.
squash explicit network
A unified viewing keys serves as a grouping of keys that are all related to the same account but do not have spend authority. This is most important when initializing the database for scanning.
* 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
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.
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
Kevin Gorham
Adí
Eljo Prifti