🔄 fallbackNewDeviceActivationFlow API

🧭 Overview

When a user attempts to activate a new device and REL-ID Verify fails or expires (e.g., due to no response on registered device), the SDK allows a fallback mechanism.

This is enabled through the API: fallbackNewDeviceActivationFlow(), which transitions the app into an alternate activation flow like OTP, email verification, or QR code.

📍 Trigger Scenario

• SDK emits addNewDeviceOptions with "Add New Device using Fallback"
• User chooses fallback option instead of REL-ID notification
• App calls fallbackNewDeviceActivationFlow()

🔧 API: fallbackNewDeviceActivationFlow()

🔥 Description

Initiates a server-configured fallback challenge flow.

💬 Result

Triggers getActivationCode (or another fallback challenge based on backend config)

💻 Platform-Specific Usage

RdnaClient.fallbackNewDeviceActivationFlow((syncResponse) => {
  console.log("Fallback flow initiated:", syncResponse);
});

rdnaClient.fallbackNewDeviceActivationFlow();

com.uniken.rdnaplugin.RdnaClient.fallbackNewDeviceActivationFlow(
  () => console.log("Fallback success"),
  (err) => console.error("Fallback failed", err)
);

RDNAError error = rdna.fallbackNewDeviceActivationFlow();

[client fallbackNewDeviceActivationFlow];

🧾 Follow-Up Event: getActivationCode

The fallback API leads to a new event based on server config. Most commonly:

Event: getActivationCode

📱 UI: Ask user to input the activation code (sent via email/SMS)

➡️ Call setActivationCode(<userEnteredCode>)

🔁 Continuation Flow

1. fallbackNewDeviceActivationFlow() → getActivationCode
2. App shows input screen for code
3. App calls setActivationCode()
4. SDK may follow with:
   • getUserConsentForLDA
   • or getPassword
5. Device is bound and proceeds to getDeviceName

❗ Error Handling

✅ On Success

• Alternate activation challenge issued
• Continues standard activation flow

❌ On Failure

• Show error toast or dialog
• Offer retry or support contact

🔍Note

The fallbackNewDeviceActivationFlow API is invoked on the new device — the one attempting to register and log in.

The new device (i.e. unregistered device) attempts login.

If the user chooses not to proceed with the primary device-based verify flow (e.g. due to notification failure or user cancellation), the new device app calls fallbackNewDeviceActivationFlow().

This triggers an alternate mechanism on the new device itself (e.g. OTP input, QR scan, or other secondary verification methods configured by the server).

✅ Summary:
New device: receives the flow, handles fallback UI, and proceeds to register itself upon success.

Old device: is not involved in the fallback method directly.