Portal
instance to connect your Portal MPC Wallet to dApps via WalletConnect. When connecting via Portal Connect, a few things happen in the background:
- You provide a WalletConnect
uri
for Portal Connect to connect with - Portal Connect opens a WebSocket connection to the WalletConnect
uri
- All requests received over the WebSocket are routed to
portal.provider
to perform the request like normal
Installing
ThePortalConnect
class is included in the portal-android
module, so no additional steps are required to start using PortalConnect
in your app.
Initializing
In order to initializePortalConnect
within your app, you’ll need to have a custom Application instance to ensure you can share the Portal
instance between Activities (Alternatively if you are using Dagger2 then you can add it as Singleton to your ApplicationComponent. Idea is that the Portal object should have the same lifecycle as your application). Once this is done, you can initialize Portal
like normal in your MainActivity
, and initialize PortalConnect
within a PortalConnectActivity.
The custom Application class
application
node of your AndroidManifest.xml
. This will register your application class as the class that is used when your app starts.
Initializing Portal
in your Activity
In the Activity where you initialize Portal
, you’ll need to set the Portal
instance on the Application.
portal.createPortalConnectInstance()
.
Connecting via WalletConnect
To connect to a WalletConnect URI, using the mechanism that makes the most sense for your app, capture the WalletConnect URI. The most common practice is to use a QR Code scanner for this. Once you’ve captured the URI, you can call theconnect(uri)
function on your PortalConnect
instance. This will initialize the WebSocket session with the WalletConnect relay and begin passing messages to your Portal Provider using your Portal MPC Wallet.
connect
and disconnect
events to get confirmation that you have successfully connected or if the user disconnects.
Wallet Connect’s Auth API is not currently supported. We have it on our roadmap. Please reach out if this is an urgent feature request.
Handling Session Requests
Session Requests
represent the initial connection request from the dApp to create a new session. These are triggered when Portal responds to the dApp after the connect(uri)
function is called. These events will be triggered with a SessionProposal
object. These objects can be used to display information about the dApp the user is connecting to and the specific permissions being requested by the dApp.
Accepting the dApps proposal
We have a helper methodaddChainsToProposal
. This can be used to add all the chains in your gateway config to the proposal object.
Binding to Session Requests
In order to bind to Session Requests, add an event handler to yourPortalConnect
instance.
Retrieve Session Request
Portal stores session requests for up to 24 hours. This feature can be useful if PortalConnect loses connection with the dApp being used and you want to respond to previous session requests. To retrieve a previous session request, use theemitGetSessionRequest
method. You will need to provide both the requestId
and the topic
.
Important Notes:
- You can only respond to a session request once.
- Ensure you have stored the correct
requestId
andtopic
values to successfully retrieve the session request.
Handle Signing
Each portal connect instance gets created with its own instance of the Portal Provider. This allows users to connect with different chains to different dApps.Listen for signing events
Handle signing approval. This is only required ifautoApprove
is turned off.
Handle Warnings and Errors
Set up a listener forportal_connectError
in order to handle specific errors and warnings from Portal Connect. Check out our Portal Connect Error Codes here.
Switching Chains
In order to switch the active chain for a portal connect instance use theupdateChainId
method.
You must include that
chainId
in the gateway config with a gateway url on initialization of your Portal Object, otherwise, you can not switch chains.