The problem with tx is we have 10+ types of them, so we have to either define a class for each one or lose type safety. There’s probably nothing wrong with defining new classes however. It’s just lots of typing =)
If I find time next month after graduating I will see to maybee do some work.
I think I have for most tx type’s already a rougly made class since I need those in my bot
I’ve realized that I can reuse current Transaction class which is basically a bag of values. So I’ve added getBlock(height), getBlock(id), and getTransaction(id) to Node.
Nice updates, but don’t we need everything backwards compatible for as long as possible?
I have updated my code now, but in the past I noticed people that became confused after not being able to use latest update with there old code.
v2 needs Smart Accounts feature to be activated, which is currently the case with testnet only. It seems I need to improve the wording in my announcement…
Not sure about compatibility, I still feel it’s too early to freeze the current API. Or maybe I should maintain two branches in parallel, one of which would be stable
We made such switch in WavesCS library. You can check first line in this MultiSig test which requires TransferTransaction version 2. It sets static field and then it uses in TransferTransaction serialization logic.
So far v2 works on testnet only, pending smart accounts feature activation on mainnet. You can use either library version 0.7 or 0.10 – both support v1 transactions