DP-701 queue #53
DP-701 queue #53
Conversation
| throw KeyStoreErrors.noSecretKey | ||
| } | ||
|
|
||
| return try KeyUtils.sign(message: message, signingKey: signingKey) | ||
| } | ||
|
|
||
| fileprivate func secretKey(passphrase: String) -> [UInt8]? { |
There was a problem hiding this comment.
@yosriz be aware of changes like this, removing the passphrase externally, in order to move the ios sdk closer to androids
There was a problem hiding this comment.
cool, make sure you run regression tests on import/export cause we don't have tests there (are we?)
| - Parameter network: The `Network` to be used. | ||
| - Parameter appId: The `AppId` of the host application. | ||
| */ | ||
| public init(with nodeProviderUrl: URL, network: Network, appId: AppId) { |
There was a problem hiding this comment.
@yosriz another change to unify the sdks is removing the network function bubble in ios. using a shared singleton now like android.
There was a problem hiding this comment.
in general, the bubble is not necessarily a bad thing, that basically can serve as dependency injection (in our case we can't do it more nicely with a DI framework). the singleton is a thing we got from stellar.
anyway, a relatively new thing is that we want to avoid completely breaking the API, so please deprecate the old ones and do not remove completely.
| @@ -126,6 +96,7 @@ public struct PaymentInfo { | |||
| Amount in `Kin` of the payment | |||
| */ | |||
| public var amount: Kin { | |||
| // ???: the amount should be quark going into kin and not kin into kin | |||
There was a problem hiding this comment.
@yosriz this is a comment for me to look into at a later time. it appears at first glance like its wrong.
There was a problem hiding this comment.
Payment queue seems good overall 👍
The tasks queue is not finished yet, so I didn't get down to small details, overall there should be:
- implementing payments merging, might affect the way the
OperationQueueworks, as you cannot remove operation directly from the queue (can you update it?), we had a similar issue with Android, so, you can talk to Amitai as well if needed. - propagate fee from the
QueueManager, fetch minimum if fee wasn't set. - implement interceptor mechanism (can be null, in the payment queue, there's a single one for every payments transaction, while in transaction params there's dedicated instance for each call (= transaction).
- you should have eventually a test that fire payments like expected from the public API, and verify that transactions eventually land successfully/not successfully in the blockchain.
- tests are failing now
this is a pr mainly for the payments queue and its tests