This simple PR introduce an async/await version of all the callback based methods. All new async endpoints exist alongside the callback based ones, it therefore doesn't introduce any breaking change, just a larger choice. Tests have also been simplified, which is a double benefit as it also tests the proxying logic (async endpoints are just wrappers around existing callback based methods).

All RxSwift Dependencies were removed from tests.

Next step: Move RxSolana to separate package and remove RxSwift dependency from Solana package.

@ajamaica when I separate RxSolana package I can send you an archive to your email or I can make a repo in my repositories and give you a link so you can download and publish it in yours and then I will remove it from mines. Let me know what you would prefer.

It's currently not possible to send custom transactions to your own Solana program with this package as-is. TransactionInstruction does not have a public init which means you can't create and send one from outside the package.

Longer term it may be desirable to have full Anchor support, but in the mean-time (and for programs that don't use Anchor) it would be useful to be able to create and send custom instructions.

#83 discusses a possible way to do this by creating a TransactionInstruction and then sending it with solana.action.serializeAndSendWithFee - however, without a public initialiser this isn't actually possible from outside.

It would be good to discuss the options, a public init would be the simplest, but it may also be desirable to have static helpers like createCustomInstruction which could be made generic and specialised on a CustomInstruction interface, allowing external code to implement custom instructions and then create/send them. Has this been thought about much?

Describe the bug Attempting to build a project that has Solana.swift as a dependency in SPM fails to build with a linker error, Undefined symbol: __swift_FORCE_LOAD_$_XCTestSwiftSupport

To Reproduce Steps to reproduce the behavior:

1. Create a new project (I've tried both an iOS app and a framework, both behave the same)
2. Add Solana.swift as a dependency in SPM
3. Build the target
4. See build failure Undefined symbol: __swift_FORCE_LOAD_$_XCTestSwiftSupport

Expected behavior The project should build

Screenshots

Closes https://github.com/ajamaica/Solana.Swift/issues/178

• Made serialization process reserve space for null signatures instead of trimming them
• Fixed public Transaction.Signature model to actually be public

Resolves #148

This is being created as DRAFT for discussion.

• The feature added is described in the README.
• Change is additive in a single file, with one exception: a change to make findProgramAddress public.
• Note that findProgramAddress could actually be internal - but it seems like it should be a public utility function for any programs using this package (fixes #144 too).
• Sadly, the existing tests are broken (see #149), and I didn't write any new tests for this - I would love to add some tests but I'm trying to encourage some discussion around how to best achieve this (Anchor support) before spending lots of time on it. It works for our Anchor program, and provides a cleanish way for apps to talk directly to their own Solana programs.
• I know there's a separate Anchor.swift repo, but it appears to be abandoned.
• There are many fancy things that could be done - parsing IDL; property wrappers to provide function parameter hints and auto-implement serialization; but this seems like a good place to start discussion. It's simple, it works, it can be extended.
• I put all the Anchor support code in one file, but its location is probably wrong, and perhaps some of these bits could be elsewhere - I welcome discussion/suggestions on how to tidy this up.

Hello Arturo!

I've added a boolean flag similar to --allow-unfunded-recipient of Solana CLI to fund the creation of the account by sending SOL to it. Please review, if there's anything you'd want me to tweak — let me know.

Thanks

Hello, all!

This PR is for the "typed action template" system we've discussed a couple times. The idea is that, while the current formulation to perform transactions is relatively convenient generally, if you're working with another paradigm, like Rx, Combine, or Swift's new structured concurrency, then the callback format can be inconvenient, and rewriting custom implementations that shim each and every action that can be performed is not only arduous, but ultimately somewhat self-defeating.

So in this PR, I'm suggesting the addition of (optional — you can still have actions without writing one, of course!) "Action Templates" — struct-based versions of the instructions to perform a given action that you can hand directly to the Action class to perform instead of calling a method it owns.

I've gone through a bunch of different iterations of what this could look like, but eventually, I concluded it's probably best just to keep this simple.

In practice, here's how that looks, using a completion handler:

let action = Action(...) // configure the "Action" class exactly as you would now
let request = ActionTemplates.GetTokenWallets(...) // Build a request with the ActionTemplate representing what you want to do.
action.perform(request) { result in
    // perform any actions you want here, just like berfore
}

But the real power here, and the reason I think this is important to do, is in the fact that this will prevent us from writing dozens of identical-looking variations on each action in the API in each tool. So instead of writing dozens of Combine implementations, we can write one extension, which will support all the current and future actions:

public extension Action {
   func publisher<T: ActionTemplate>(for actionTemplate: T) -> AnyPublisher<T.Success, Error> {
            Future<T.Success, Error> { promise in
                self.perform(actionTemplate) { promise($0) }
            }.eraseToAnyPublisher()
    }
}

And supporting structured concurrency is similarly straightforward:

public extension Action {
    func perform<T: ActionTemplate>(_ actionTemplate: T) async throws -> T.Success {
        try await withCheckedThrowingContinuation { continuation in
            perform(actionTemplate) { continuation.resume(with: $0)}
        }
    }
}

Rx, being nearly identical to these two except the addition of imperatively building a disposable, is left as an exercise for the reader :P.

I think introducing a system like this will be crucial to the longevity of the APIs here, and it will allow us to split out dependencies on things like Combine, Rx, and Swift 5.5/iOS 15 without having to write hundreds of lines in the packages to support them.

This PR bumps the build and test step to use the new macOS 11 GH actions option, which will enable us to check against other Swift features in the future, as well as (more importantly for now) just putting us in step with the platform and up to date with the way other open source projects are configuring themselves.

Since the Swift requirements are not changing, we should not begin using any new features in the frameworks, but this seems like a good maintenance change.

In this PR: Removed RxSolana from Solana package Removed RxSolana examples from README.md

I created a package https://github.com/DezorkIT/RxSolana.Swift, for now it looks at a branch in my fork. After this PR will be merged it needs to be updated with a link to your repo, a version tag and a change in a second step in docs in the "Installation" paragraph. After that you can move it to your repositories.

A proposal: RxSolana had to be moved to a separated package, because there is other reactive frameworks besides RxSwift, for example native Combine. And there is also async/await for those who doesn't want/like reactive stuff. In the current version you have to have RxSolana dependency, which comes with RxSwift, even if you don't want to use it.

Before moving to isolated package: Current version of Solana.Swift has tests which requires RxSolana, they had to be rewritten first.

In this PR: Added RunLoopSimpleLock for testing. Which is simpler version of RunLoopLock.swift Removed rx from some tests, I will do the same for other tests in coming weeks Commented out "testDerivedKeychain" test because there is no "Keychain" entity

Would love to hear your thoughts and opinions on that.

Description

• There were some issues with formatting transaction hashes in encoded JSON objects. Certain characters were getting escaped twice in the JSON field values, leading to them to fail to simulate.

Work Completed

• Updated the parameters on the JSON encoder to tell it not to escape JSON string values
• NOTE: The fix uses a feature only available on iOS 13+. Is it acceptable to update the minimum version to this, or does a fix need to be found that also works on older versions?

Testing

• Transactions which were failing to simulate now simulate and complete successfully

Describe the bug I'm currently using MW to create unsigned transactions, return to frontend, serialize and sign. After signing and sending the transaction I'm getting "Signature Verification Failed" error from the chain.

I'm using serialize function with requiredAllSignatures and verifySignatures parameters as true and getting no error. However, when sending on-chain this error occurs. When I checked the serialized data created for same transaction on web3.js and Solana.Swift library there were some differences in UInt8 array.

To Reproduce Steps to reproduce the behavior:

1. https://api.magiceden.dev or https://docs.hyperspace.xyz/hype/developer-guide/ can be used to create the NFT transactions.
2. Create the transaction object from the retrieved tx.
3. Partial sign, serialize and send the transaction on chain.
4. See error

Expected behavior Transaction should go through and be successful on chain.

Screenshots

I am using this library for solana spl token transfer. I can successfully created token account for sender but not able to create token account for receiver. As i have no secret key of receiver so how can i create token account for receiver can anyone help please?

The tests are currently failing, and it appears some use the real NetworkingRouter and actually talk to a GenesysGo devnet node.

This is undesirable for a number of reasons.

Fix is to implement a mock version of SolanaRouter that provides appropriate responses for each test case.

Describe the bug Action.sendSPLTokens always fails with a destination address of an original account address (the address of SOL account), no matter if there is an existing associated token address under the original account. The action only works when "to" and "from" are both associated token addresses other than their owners.

Expected behavior If I did not get the design intention wrong, the action should check if the destination passing in is an associated token address or an original address. If it is an original address, the program will find its associated token address registered under the mint, or create a new one if not existing. However I'm getting errors under both conditions.

I'm using the mint address of USDC in my tests on testnet: CpMah17kQEL2wqyMKt3mZBdTnZbkbfx4nqmQMFDP5vwp