zec
/
zcash-android-wallet-sdk
mirror of https://github.com/zcash/zcash-android-wallet-sdk.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
zcash-android-wallet-sdk/src/main/java/cash/z/wallet/sdk/data/Synchronizer.kt

36 lines
1.2 KiB
Kotlin
Raw Normal View History

Create synchronizer and add layer of business logic onto the data layer App is functional and displays transactions
2019-01-02 21:31:12 -08:00
package cash.z.wallet.sdk.data
Create mock synchronizer to help with driving the UI. After experiencing several issues that make it more difficult to test send behavior, including the amount of time required to wait for blocks to get mined when testnet is slow, it became obvious that it was time to investigate mocking. Most of the behavior in the SDK is driven by channels so the mock only has to focus on putting useful data in the expected channels at the right time. One tradeoff here was the need to make all the synchronizer properties private, that way any implementation can achieve compatability without necessasily leveraging the same combinations of building blocks. This tradeoff felt acceptable given that these dependencies can be injected and available as singletons, if needed. This also had a side effect of elevating several channels into the Synchronizer interface, rather than reaching into the synchronizer to directly access those dependencies. Another benefit is that it's now easier to see what matters most to the app, particularly which channels are essential.
2019-02-14 13:43:06 -08:00
import cash.z.wallet.sdk.dao.WalletTransaction
import kotlinx.coroutines.CoroutineScope
Create synchronizer and add layer of business logic onto the data layer App is functional and displays transactions
2019-01-02 21:31:12 -08:00
import kotlinx.coroutines.channels.ReceiveChannel
Create mock synchronizer to help with driving the UI. After experiencing several issues that make it more difficult to test send behavior, including the amount of time required to wait for blocks to get mined when testnet is slow, it became obvious that it was time to investigate mocking. Most of the behavior in the SDK is driven by channels so the mock only has to focus on putting useful data in the expected channels at the right time. One tradeoff here was the need to make all the synchronizer properties private, that way any implementation can achieve compatability without necessasily leveraging the same combinations of building blocks. This tradeoff felt acceptable given that these dependencies can be injected and available as singletons, if needed. This also had a side effect of elevating several channels into the Synchronizer interface, rather than reaching into the synchronizer to directly access those dependencies. Another benefit is that it's now easier to see what matters most to the app, particularly which channels are essential.
2019-02-14 13:43:06 -08:00
interface Synchronizer {
Create synchronizer and add layer of business logic onto the data layer App is functional and displays transactions
2019-01-02 21:31:12 -08:00
Create mock synchronizer to help with driving the UI. After experiencing several issues that make it more difficult to test send behavior, including the amount of time required to wait for blocks to get mined when testnet is slow, it became obvious that it was time to investigate mocking. Most of the behavior in the SDK is driven by channels so the mock only has to focus on putting useful data in the expected channels at the right time. One tradeoff here was the need to make all the synchronizer properties private, that way any implementation can achieve compatability without necessasily leveraging the same combinations of building blocks. This tradeoff felt acceptable given that these dependencies can be injected and available as singletons, if needed. This also had a side effect of elevating several channels into the Synchronizer interface, rather than reaching into the synchronizer to directly access those dependencies. Another benefit is that it's now easier to see what matters most to the app, particularly which channels are essential.
2019-02-14 13:43:06 -08:00
/* Lifecycle */
fun start(parentScope: CoroutineScope): Synchronizer
fun stop()
Create CompactBlockProcessor and refine responsibilities of collaborators The synchronizer now primarily collaborates with a downloader, processor and repository; each with a more focused set of responsibilities. The downloader streams blocks into a channel, the processor saves blocks from that channel and scans for transactions, the repository exposes transaction change events.
2019-01-23 02:45:26 -08:00
Create mock synchronizer to help with driving the UI. After experiencing several issues that make it more difficult to test send behavior, including the amount of time required to wait for blocks to get mined when testnet is slow, it became obvious that it was time to investigate mocking. Most of the behavior in the SDK is driven by channels so the mock only has to focus on putting useful data in the expected channels at the right time. One tradeoff here was the need to make all the synchronizer properties private, that way any implementation can achieve compatability without necessasily leveraging the same combinations of building blocks. This tradeoff felt acceptable given that these dependencies can be injected and available as singletons, if needed. This also had a side effect of elevating several channels into the Synchronizer interface, rather than reaching into the synchronizer to directly access those dependencies. Another benefit is that it's now easier to see what matters most to the app, particularly which channels are essential.
2019-02-14 13:43:06 -08:00
/* Channels */
// NOTE: each of these are expected to be a broadcast channel, such that [receive] always returns the latest value
fun activeTransactions(): ReceiveChannel<Map<ActiveTransaction, TransactionState>>
fun allTransactions(): ReceiveChannel<List<WalletTransaction>>
fun balance(): ReceiveChannel<Long>
fun progress(): ReceiveChannel<Int>
Create CompactBlockProcessor and refine responsibilities of collaborators The synchronizer now primarily collaborates with a downloader, processor and repository; each with a more focused set of responsibilities. The downloader streams blocks into a channel, the processor saves blocks from that channel and scans for transactions, the repository exposes transaction change events.
2019-01-23 02:45:26 -08:00
Create mock synchronizer to help with driving the UI. After experiencing several issues that make it more difficult to test send behavior, including the amount of time required to wait for blocks to get mined when testnet is slow, it became obvious that it was time to investigate mocking. Most of the behavior in the SDK is driven by channels so the mock only has to focus on putting useful data in the expected channels at the right time. One tradeoff here was the need to make all the synchronizer properties private, that way any implementation can achieve compatability without necessasily leveraging the same combinations of building blocks. This tradeoff felt acceptable given that these dependencies can be injected and available as singletons, if needed. This also had a side effect of elevating several channels into the Synchronizer interface, rather than reaching into the synchronizer to directly access those dependencies. Another benefit is that it's now easier to see what matters most to the app, particularly which channels are essential.
2019-02-14 13:43:06 -08:00
/* Status */
suspend fun isOutOfSync(): Boolean
suspend fun isFirstRun(): Boolean
Add a layer of logic for bubbling up errors This allows the app to show an error dialog rather than crashing silently
2019-02-24 15:59:07 -08:00
val address: String
/**
* Called whenever there is an uncaught exception.
*
* @return true when the error has been handled and the Synchronizer should continue. False when the error is
* unrecoverable and the Synchronizer should [stop].
*/
var onSynchronizerErrorListener: ((Throwable?) -> Boolean)?
Create CompactBlockProcessor and refine responsibilities of collaborators The synchronizer now primarily collaborates with a downloader, processor and repository; each with a more focused set of responsibilities. The downloader streams blocks into a channel, the processor saves blocks from that channel and scans for transactions, the repository exposes transaction change events.
2019-01-23 02:45:26 -08:00
Create mock synchronizer to help with driving the UI. After experiencing several issues that make it more difficult to test send behavior, including the amount of time required to wait for blocks to get mined when testnet is slow, it became obvious that it was time to investigate mocking. Most of the behavior in the SDK is driven by channels so the mock only has to focus on putting useful data in the expected channels at the right time. One tradeoff here was the need to make all the synchronizer properties private, that way any implementation can achieve compatability without necessasily leveraging the same combinations of building blocks. This tradeoff felt acceptable given that these dependencies can be injected and available as singletons, if needed. This also had a side effect of elevating several channels into the Synchronizer interface, rather than reaching into the synchronizer to directly access those dependencies. Another benefit is that it's now easier to see what matters most to the app, particularly which channels are essential.
2019-02-14 13:43:06 -08:00
/* Operations */
suspend fun sendToAddress(zatoshi: Long, toAddress: String)
fun cancelSend(transaction: ActiveSendTransaction): Boolean
Create synchronizer and add layer of business logic onto the data layer App is functional and displays transactions
2019-01-02 21:31:12 -08:00
}