Radix Connect for Mobile

[GhenadieVP]

Radix Connect for Mobile implementation.

This PR is the Wallet integration of Sargon's RadixConnectMobile API - radixdlt/sargon#122. All of the RCfM logic is in Sargon, while Wallet is responsible for intercepting the DeepLink and present the request to the user.

What has been done

• Added the simple DeepLink setup that allows the Wallet to receive deep link requests.
• Integrated Sargon's RadixConnectMobile which responsible for parsing the deep link request, establish the session and send back the response.
• Integrated the RadixConnectMobile into RadixConnect client, so the requests received over deepLink are then propagated in the app the same way as requests from WebRTC or from within the Wallet.
• Added the new deepLink route, so the Wallet acts accordingly depending when this route is involved.
• Add the origin verification screen, as well a generic way of showing it if a request does not have the origin pre-verified.

Demo

https://drive.google.com/file/d/1REicQe4gyIXMAKoifMS2pERMuYmrNsQr/view?usp=sharing&t=73.

[GhenadieVP]

will be replaced with Sargon version once the related PR is merged in Sargon

[danvleju-rdx]

Looks good!
Left some minor comments.
Will do more testing after Sargon PR merge.

[matiasbzurovski]

Looking very clean!

[Sajjon]

@Sendable on all function types?

[GhenadieVP]

Not needed, as those functions are only called from the main thread.

[Sajjon]

Hmm should client be Sendable?

[GhenadieVP]

Not needed, it is used only from the main thread really. I could add it for the sake of it, but it will not be useful.

[Sajjon]

Im unsure if this passes complete Isolation check? Since state is references referenced/mutated from multiple closures.

Might be solved with @TaskLocal?

[GhenadieVP]

but all of the closures are not executed in a concurrent context, there will not be two concurrent deepLinks to be handled at the same time.

[Sajjon]

I think this is not needed any more, if you use @DependencyClient macro on DeepLinkHandlerClient.

[Sajjon]

perhaps a small unit tests for this? Just calling save and then load and assert the correct session data is loaded?

[Sajjon]

I guess P2P.RTCIncomingMessage does not exist in Sargon? preventing this struct to be implemented in Swift Sargon?

What if you make this struct generic?

// This will be `Sargon.RadixConnectMobile` (vs `SargonUniFFI.RadixConnectMobile`)
public struct RadixConnectMobile<Storage, Message> where Storage: SessionStorage {
   private let radixConnectMobile: SargonUniFFI.RadixConnectMobile // N.B. `SargonUniFFI.`
   ... incomingMessagesSubject: AsyncReplaySubject<Message> ...

   public init(storage: Storage) {
       self.radixConnectMobile = SargonUniFFI.RadixConnectMobile.live(sessionStorage: storage)

   }
}

extension RadixConnectMobile {
    func incomingMessages() async -> AnyAsyncSequence<Message> {
		...
	}
}

Then it can be placed in Swift Sargon, with all the benefits that entails:

• Easy to write unit tests
• Getting code coverage measurements

[GhenadieVP]

I don't quite follow your suggestion, why I would make this generic when it is specific to RadixConnectMobile.

P2P.RTCIncomingMessage does not exist in Sargon, since it does not yet know about messages from WebRTC or from the Wallet itself; also it is highly specific to iOS.

[Sajjon]

P2P.RTCIncomingMessage does not exist in Sargon,

that is my point, P2P.RTCIncomingMessage does not exist in Sargon. But a generic type T can be declared ("exist") in Sargon. Thus this struct RadixConnectMobile<T> can exist in Sargon. Which works, since this type does not actually create any T or read any fields of T. And having Swift code In Sargon has the above mentioned two advantages:

• Easy to write unit tests
• Getting code coverage measurements

VS the terrible DX of writing unit tests in iOS app repo - without code coverage.

[GhenadieVP]

I see, we can get to this at some later point when we can unify the channel of incoming message on both platforms.

[CyonAlexRDX]

Sweet! LGTM