Confirm flow-jvm-sdk complies with Flow SDK guidelines

[jereanon]

Confirm the flow-jvm-sdk meets all the items in the Flow SDK Guidelines

Consistent

• [x] Usage of ubiquitous language, supporting same user stories, common versioning will bring consistency across SDKs. Consistency is important as it brings familiarity between implementations, easier transitions, and a common practice for implementations.

Accessible

• [x] Accessibility is an important aspect of each SDK and it means how easy is for a developer to start using and implementing the SDK. Great documentation makes SDK more accessible. The guidelines define rules around the documentation and also example templates to write it.

Reliable

• [x] Reliability is of the highest importance for any piece of software. It is achieved by having good tests, but also and almost more importantly common rules around handling changes, and backward compatibility, since the SDK is not meant to act as a standalone product but as an integrated part in another product it is important that it doesn't break that piece of software. Changes are inevitable and we will provide guidance on how to tackle them without hurting anyone.

User Stories

Blocks:

• [x] retrieve a block by ID
• [x] retrieve a block by height
• [x] retrieve the latest block

Collections:

• [x] retrieve a collection by ID

Events:

• [x] retrieve events by name in the block height range

Scripts:

• [x] submit a script and parse the response
• [x] submit a script with arguments and parse the response

Accounts:

• [x] retrieve an account by address
• [x] create a new account
• [x] deploy a new contract to the account
• [x] remove a contract from the account
• [x] update an existing contract on the account

Transactions:

• [x] retrieve a transaction by ID
• [x] sign a transaction (single payer, proposer, authorizer or combination of multiple)
• [x] submit a signed transaction
• [x] sign a transaction with arguments and submit it

Networking

Access nodes currently support two APIs:

• [ ] REST

• [x] GRPC

Versioning

• [x] Changes in the codebase should reflect with versioning. We advise using semantic versioning format. Following this versioning format will allow you to comply with other guidelines such as handling breaking changes etc. Once the codebase is stable enough you should establish a release schedule and make sure it always includes all changes from sporking.

Cadence

• [ ] Implementing the above-mentioned user stories will require you to supply the transactions with a cadence code. To avoid making mistakes in the cadence code we advise you to use our templates defined in the repo [TBD]

Cadence Templates

Error Handling

• [x] Writing code by exercising defensive design is a good way to avoid unexpected errors. Handle errors gracefully and in language idiomatic way. Provide the best context as part of the error message as you can, this will allow the user of the SDK to quickly debug the problem.

Logging

• [x] Logging is an optional functionality of the SDK and it is meant to be of assistance to the developer implementing your SDK, however, please be careful that logging is implemented as an isolated module and it should be possible to disable it. It is advisable to also use third-party logging libraries which should be plugged into the SDK.

Testing

• [x] Writing good tests is a crucial task in pursuit of reliability. We will assist you with our testing data [TBD] you can use to mock responses for each user story. After implementing unit tests you should add integration tests by using our testing mock APIs found here [TBD]. Mock API exposes the same API interface as the access node and returns mock results which you can assert.

CI & CD

• [x] Follow best practices in optimizing the integration and deployment workflow. Make sure tests are being run as part of the CI and all released versions of the SDK are passing the tests.