Overview & Structure
The SDK is heavily based on the builder and factory pattern to create the configuration, service instances and subsequently the objects wrapping the transaction to interact with the aeternity network.
SDK Service Entrypoint
The central access point to all services is made available through the AeternityService which can be obtained via the AeternityServiceFactory. Necessary parameters to f.e. identify the network to use or the endpoints to act against, are defined via the AeternityServiceConfiguration. Within this class, the following parameters can be set
Parameter
Description
Value / Default
baseUrl
endpoint URL of the aeternity node
compilerBaseUrl
endpoint URL of the sophia compiler node
mdwBaseUrl
endpoint URL of the aeternal middleware
network
network to run against - must be considered together with chosen Endpoint URLs
nativeMode
for debug and test purposes - if true, the SDK creates the unsigned transaction from the given model, otherwise the node is called
true
baseKeyPair
the account which is internally used to sign all transactions (if no other private key is passed in the post transaction method)
vertx
the vertx instance which is used within the SDK to call the node interfaces - will be instantiated automatically
targetVM
target VM version - depending on the selected VM, contract related transactions need to specify the respective abiVersion and vmVersion
To actually construct the service configuration and get an instance of the AeternityService, the following steps are necessary. In this example we use a randomly created base key pair
Aeternity Service Capabilities
All provided functions are classified into their purpose for better organization - those will be discussed in the subsequent chapters.
accounts
aeternal
compiler
info
names
oracles
transactions
Last updated