ZcashLightClientKit/Sources/ZcashLightClientKit/Modules/Service/GRPC/LightWalletGRPCService.swift

343 lines
11 KiB
Swift
Raw Normal View History

//
// ServiceHelper.swift
// gRPC-PoC
//
// Created by Francisco Gindre on 29/08/2019.
// Copyright © 2019 Electric Coin Company. All rights reserved.
//
import Foundation
import GRPC
import NIO
import NIOHPACK
import NIOTransportServices
typealias Channel = GRPC.GRPCChannel
2021-09-17 06:49:58 -07:00
extension LightdInfo: LightWalletdInfo {}
extension SendResponse: LightWalletServiceResponse {}
2021-09-17 06:49:58 -07:00
/**
Swift GRPC implementation of Lightwalletd service
*/
enum GRPCResult: Equatable {
2021-09-17 06:49:58 -07:00
case success
case error(_ error: LightWalletServiceError)
}
protocol CancellableCall {
func cancel()
}
extension ServerStreamingCall: CancellableCall {
func cancel() {
self.cancel(promise: self.eventLoop.makePromise(of: Void.self))
}
}
protocol LatestBlockHeightProvider {
func latestBlockHeight(streamer: CompactTxStreamerAsyncClient) async throws -> BlockHeight
}
class LiveLatestBlockHeightProvider: LatestBlockHeightProvider {
func latestBlockHeight(streamer: CompactTxStreamerAsyncClient) async throws -> BlockHeight {
do {
let blockID = try await streamer.getLatestBlock(ChainSpec())
guard let blockHeight = Int(exactly: blockID.height) else {
throw LightWalletServiceError.generalError(message: "error creating blockheight from BlockID \(blockID)")
}
return blockHeight
} catch {
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
let serviceError = error.mapToServiceError()
throw ZcashError.serviceLatestBlockHeightFailed(serviceError)
}
}
}
class LightWalletGRPCService {
let channel: Channel
2021-09-17 06:49:58 -07:00
let connectionManager: ConnectionStatusManager
let compactTxStreamer: CompactTxStreamerAsyncClient
let singleCallTimeout: TimeLimit
let streamingCallTimeout: TimeLimit
var latestBlockHeightProvider: LatestBlockHeightProvider = LiveLatestBlockHeightProvider()
2021-09-17 06:49:58 -07:00
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
var connectionStateChange: ((_ from: ConnectionState, _ to: ConnectionState) -> Void)? {
get { connectionManager.connectionStateChange }
set { connectionManager.connectionStateChange = newValue }
}
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
let queue: DispatchQueue
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
convenience init(endpoint: LightWalletEndpoint) {
2021-09-17 06:49:58 -07:00
self.init(
host: endpoint.host,
port: endpoint.port,
secure: endpoint.secure,
singleCallTimeout: endpoint.singleCallTimeoutInMillis,
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
streamingCallTimeout: endpoint.streamingCallTimeoutInMillis
2021-09-17 06:49:58 -07:00
)
}
2021-09-17 06:49:58 -07:00
/// Inits a connection to a Lightwalletd service to the given
/// - Parameters:
/// - host: the hostname of the lightwalletd server
/// - port: port of the server. Default is 9067
/// - secure: whether this server is TLS or plaintext. default True (TLS)
/// - singleCallTimeout: Timeout for unary calls in milliseconds.
/// - streamingCallTimeout: Timeout for streaming calls in milliseconds.
init(
host: String,
port: Int = 9067,
secure: Bool = true,
singleCallTimeout: Int64,
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
streamingCallTimeout: Int64
) {
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
self.connectionManager = ConnectionStatusManager()
self.queue = DispatchQueue.init(label: "LightWalletGRPCService")
self.streamingCallTimeout = TimeLimit.timeout(.milliseconds(streamingCallTimeout))
self.singleCallTimeout = TimeLimit.timeout(.milliseconds(singleCallTimeout))
2021-09-17 06:49:58 -07:00
let connectionBuilder = secure ?
ClientConnection.usingPlatformAppropriateTLS(for: NIOTSEventLoopGroup(loopCount: 1, defaultQoS: .default)) :
ClientConnection.insecure(group: NIOTSEventLoopGroup(loopCount: 1, defaultQoS: .default))
let channel = connectionBuilder
.withConnectivityStateDelegate(connectionManager, executingOn: queue)
.connect(host: host, port: port)
2021-09-17 06:49:58 -07:00
self.channel = channel
compactTxStreamer = CompactTxStreamerAsyncClient(
2021-09-17 06:49:58 -07:00
channel: self.channel,
defaultCallOptions: Self.callOptions(
timeLimit: self.singleCallTimeout
2021-09-17 06:49:58 -07:00
)
)
2019-10-31 15:43:09 -07:00
}
2021-09-17 06:49:58 -07:00
deinit {
_ = channel.close()
_ = compactTxStreamer.channel.close()
}
func stop() {
_ = channel.close()
}
func latestBlock() async throws -> BlockID {
do {
return try await compactTxStreamer.getLatestBlock(ChainSpec())
} catch {
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
let serviceError = error.mapToServiceError()
throw ZcashError.serviceLatestBlockFailed(serviceError)
}
}
2021-09-17 06:49:58 -07:00
static func callOptions(timeLimit: TimeLimit) -> CallOptions {
2021-09-17 06:49:58 -07:00
CallOptions(
customMetadata: HPACKHeaders(),
timeLimit: timeLimit,
messageEncoding: .disabled,
requestIDProvider: .autogenerated,
requestIDHeader: nil,
cacheable: false
)
}
}
// MARK: - LightWalletService
extension LightWalletGRPCService: LightWalletService {
func getInfo() async throws -> LightWalletdInfo {
do {
return try await compactTxStreamer.getLightdInfo(Empty())
} catch {
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
let serviceError = error.mapToServiceError()
throw ZcashError.serviceGetInfoFailed(serviceError)
}
}
func latestBlockHeight() async throws -> BlockHeight {
try await latestBlockHeightProvider.latestBlockHeight(streamer: compactTxStreamer)
}
func blockRange(_ range: CompactBlockRange) -> AsyncThrowingStream<ZcashCompactBlock, Error> {
let stream = compactTxStreamer.getBlockRange(range.blockRange())
var iterator = stream.makeAsyncIterator()
return AsyncThrowingStream() {
do {
guard let block = try await iterator.next() else { return nil }
return ZcashCompactBlock(compactBlock: block)
} catch {
let serviceError = error.mapToServiceError()
throw ZcashError.serviceBlockRangeFailed(serviceError)
}
}
}
2020-12-09 15:57:23 -08:00
func submit(spendTransaction: Data) async throws -> LightWalletServiceResponse {
do {
let transaction = RawTransaction.with { $0.data = spendTransaction }
return try await compactTxStreamer.sendTransaction(transaction)
} catch {
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
let serviceError = error.mapToServiceError()
throw ZcashError.serviceSubmitFailed(serviceError)
2021-04-01 07:27:26 -07:00
}
}
func fetchTransaction(txId: Data) async throws -> ZcashTransaction.Fetched {
var txFilter = TxFilter()
txFilter.hash = txId
do {
let rawTx = try await compactTxStreamer.getTransaction(txFilter)
return ZcashTransaction.Fetched(rawID: txId, minedHeight: BlockHeight(rawTx.height), raw: rawTx.data)
} catch {
[#361] Introduce ZcashError (#1005) This PR introduces `ZcashError` enum. This enum represents any error that can be thrown inside of the SDK and outside of the SDK. Also `ZcashError` is used in `LightWalletGRPCService` and handled in `CompactBlockProcessor` as example. Why enum? First I tried this with some structure which contained code, message and underlyingError. Problem was when some specific place in the SDK would like to attach some additional data to error. I didn't want to add some generic dictionary to store anything with the error. So I used enum to identify error. Each member can have specified amount of associated values. So specific error can bring some context data. And it's type safe. Each error has also a code. Relationship between errors and codes is 1:1. It may looks bit redundant but it's important. The client app now can choose how to process errors. Either identify those by the error itself or by code. Definition or errors and codes is in `ZcashErrorDefinition`. And then `ZcashError` and `ZcashErrorCode` are generated by Sourcery. Thanks to this it is easier to maintain the final code. And it gives us ability to generate any kind of documentation for the errors and codes. I created simple example of this in this PR. And it doesn't make the SDK completely dependent on the Sourcery. Final structures aren't super complicated and can be written manually if needed. [#923] Update error handling in DatabaseStorageManager.swift - cleanup of DatabaseStorageManager, not used anymore - ZcashError for SimpleConnectionProvider Revert "[#923] Update error handling in DatabaseStorageManager.swift" This reverts commit 94e028d31a0f6635800c297eb741db74c6a6ff45. Fix script which generates ZcashError [#922] Update error handling in DatabaseMigrationManager.swift Closes #922 [#923] Update error handling in DatabaseStorageManager.swift - The DatabaseStorageManager is not used so I deleted it - SimpleConnectionProvider's errors updated Fix tests [#955] Update error handling in SaplingParameterDownloader Closes #955 [#936] Update error handling in NotesDao Closes #936 [#935] Update error handling in BlockDao Closes #935 [#931] InternalSyncProgress.computeNextState doesn't need to throw Closes #931 [#950] Update error handling in rust backend Closes #949 Closes #950 [#941] Update error handling in AccountEntity Closes #941 [#928] Update error handling in FSCompactBlockRepository Closes #928 [#925] Update error handling in BlockDownloaderService (#974) - BlockDownloaderService errors updated [#924] Update error handling in BlockDownloader (#973) - BlockDownloaderStream nextBlock updated [#942] Update error handling in TransactionEntity (#977) - ZcashTransaction init errors converted to the ZcashError [#939] Update error handling in TransactionDao (#976) - TransactionRepositoryError removed and replaced with ZcashError - all TransactionDAO errors converted to ZcashError [#943] Update error handling in ZcashCompactBlock Closes #943 [#945] Update error handling in Memo Closes #945 [#934] Update error handling in Checkpoint Closes #944 Closes #934 [#938] Update error handling in PendingTransactionDao Closes #938 [#926] Update error handling in BlockEnhancer - WIP, switching to transaction repository to unblock this ticket [#926] Update error handling in BlockEnhancer - enhancer's errors done [#926] Update error handling in BlockEnhancer (#994) - cleanup [#952] Update error handling in DerivationTool Closes #952 [#932] Update error handling in BlockValidator Closes #932 [#940] Update error handling in UnspentTransactionOutputDao Closes #940 [#946] Update error handling in WalletTypes Closes #946 [#954] Update error handling in WalletTransactionEncoder Closes #954 [#953] Update error handling in PersistentTransactionManager Closes #953 [#956] Update error handling in Initializer Closes #956 [#947] Update error handling in Zatoshi (#996) - Zatoshi's errors converted to ZcashError [#927] Update error handling in UTXOFetcher (#997) - UTXOFetcher resolved Use let instead of var where applicable In the SDK `var` was used on places where `let` would be sufficient. And default strategy in Swift should use use `let` until mutability is required. So all these places are changed. No logic is changed. [#933] Update error handling in CompactBlockProcessor - CompactBlockProcessor's errors refactored to ZcashError [#933] Update error handling in CompactBlockProcessor #999 - comments addressed [#951] Update error handling in SDKSynchronizer - SDKSynchronizer's errors refactored to ZcashError [#951] Update error handling in SDKSynchronizer (#1002) - comments resolved Make DerivationTool constructor public DerivationTool.init should be public. This was removed by accident when adopting async. [#361] Add changelog
2023-04-24 14:15:20 -07:00
let serviceError = error.mapToServiceError()
throw ZcashError.serviceFetchTransactionFailed(serviceError)
}
}
func fetchUTXOs(for tAddress: String, height: BlockHeight) -> AsyncThrowingStream<UnspentTransactionOutputEntity, Error> {
return fetchUTXOs(for: [tAddress], height: height)
2021-04-01 07:27:26 -07:00
}
func fetchUTXOs(
for tAddresses: [String],
height: BlockHeight
) -> AsyncThrowingStream<UnspentTransactionOutputEntity, Error> {
guard !tAddresses.isEmpty else {
return AsyncThrowingStream { continuation in continuation.finish() }
}
let args = GetAddressUtxosArg.with { utxoArgs in
utxoArgs.addresses = tAddresses
utxoArgs.startHeight = UInt64(height)
}
let stream = compactTxStreamer.getAddressUtxosStream(args)
var iterator = stream.makeAsyncIterator()
return AsyncThrowingStream() {
do {
guard let reply = try await iterator.next() else { return nil }
return UTXO(
id: nil,
address: reply.address,
prevoutTxId: reply.txid,
prevoutIndex: Int(reply.index),
script: reply.script,
valueZat: Int(reply.valueZat),
height: Int(reply.height),
spentInTx: nil
)
} catch {
let serviceError = error.mapToServiceError()
throw ZcashError.serviceFetchUTXOsFailed(serviceError)
}
}
}
func blockStream(
startHeight: BlockHeight,
endHeight: BlockHeight
) -> AsyncThrowingStream<ZcashCompactBlock, Error> {
let stream = compactTxStreamer.getBlockRange(
BlockRange(
startHeight: startHeight,
endHeight: endHeight
),
callOptions: Self.callOptions(timeLimit: self.streamingCallTimeout)
)
var iterator = stream.makeAsyncIterator()
return AsyncThrowingStream() {
do {
guard let compactBlock = try await iterator.next() else { return nil }
return ZcashCompactBlock(compactBlock: compactBlock)
} catch {
let serviceError = error.mapToServiceError()
throw ZcashError.serviceBlockStreamFailed(serviceError)
}
}
}
func closeConnection() {
_ = channel.close()
}
}
2021-09-17 06:49:58 -07:00
// MARK: - Extensions
extension ConnectivityState {
func toConnectionState() -> ConnectionState {
switch self {
case .connecting:
return .connecting
case .idle:
return .idle
case .ready:
return .online
case .shutdown:
return .shutdown
case .transientFailure:
return .reconnecting
}
}
2021-09-17 06:49:58 -07:00
}
extension TimeAmount {
static let singleCallTimeout = TimeAmount.seconds(30)
static let streamingCallTimeout = TimeAmount.minutes(10)
}
extension CallOptions {
static var lwdCall: CallOptions {
CallOptions(
customMetadata: HPACKHeaders(),
timeLimit: .timeout(.singleCallTimeout),
messageEncoding: .disabled,
requestIDProvider: .autogenerated,
requestIDHeader: nil,
cacheable: false
)
}
}
extension Error {
func mapToServiceError() -> LightWalletServiceError {
2021-09-17 06:49:58 -07:00
guard let grpcError = self as? GRPCStatusTransformable else {
return LightWalletServiceError.genericError(error: self)
}
return LightWalletServiceError.mapCode(grpcError.makeGRPCStatus())
}
}
extension LightWalletServiceError {
static func mapCode(_ status: GRPCStatus) -> LightWalletServiceError {
switch status.code {
case .ok:
2021-09-17 06:49:58 -07:00
return LightWalletServiceError.unknown
case .cancelled:
return LightWalletServiceError.userCancelled
case .unknown:
2021-04-08 10:18:16 -07:00
return LightWalletServiceError.generalError(message: status.message ?? "GRPC unknown error contains no message")
case .deadlineExceeded:
return LightWalletServiceError.timeOut
default:
return LightWalletServiceError.genericError(error: status)
}
}
}
class ConnectionStatusManager: ConnectivityStateDelegate {
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
var connectionStateChange: ((_ from: ConnectionState, _ to: ConnectionState) -> Void)?
init() { }
func connectivityStateDidChange(from oldState: ConnectivityState, to newState: ConnectivityState) {
[#209] Add support for multiple instances of the SDKSynchronizer Closes #209. [#845] Introduce ZcashSynchronizerAlias enum Closes #845. [#852] SDKSynchronizer using queues label based on the alias Closes #852. [#847] Remove posibility to use DatabaseStorageManager as singleton Closes #847. [#850] Remove synchronizerConnectionStateChanged notification Closes #850. [#855] Add check if the Alias is already used Closes #855 - Added `UsedAliasesChecker` utility which is used to register aliases that are in use. - `prepare()` and `wipe()` methods now check if the current alias can't be used and if not then `InitializerError.aliasAlreadyInUse` is thrown/emitted. - Some public methods that could cause harm if used with the Alias that is already in use now throw `SynchronizerError.notPrepared`. Thanks to this the client app is forced to call `prepare()` first. And `prepare()` does check for the Alias. - Added tests for new conditions. [#849] Make InternalSyncProgress aware of the Alias Closes #849. [#853] Only instance with default Alias migrates legacy cache DB Closes #853. [#851] Apply the Alias to the URLs Closes #851. - `Initializer` now updates paths according to alias before paths are used anywhere in the SDK. - Paths update can fail. It would be incovenient for the client apps to handle errors thrown from `Initiliazer` constructor. So the error is then handled in `SDKSynchronizer.prepare()` or `SDKSynchronizer.wipe()`. [#846] Stop using SDKMetrics as singleton (#862) - metrics are not longer a singleton - tests fixed - metrics outside init of the synchronizer [#848] Make logger aware of the alias - logger is now an instance passed throughout the sdk instead of a static proxy [#848] Make logger aware of the alias (#868) - comments addressed [#848] Make logger aware of the alias (#868) - returning protocol back Fix typos [#856] Add possibility to test multiple synchronizers in the sample app Closes #856. - Added `alias` property to `Synchronizer`. - Added `SyncBlocksListViewController` which provides UI to use multiple synchronizers at once. [#209] Add changelog - Add changelog for #209. - Overall improve readability of the rendered changelog. Tickets references are now prefixed with `###` instead of `- `. Fix compilation
2023-03-22 05:47:32 -07:00
connectionStateChange?(oldState.toConnectionState(), newState.toConnectionState())
}
}