<provider\n android:name=\"androidx.startup.InitializationProvider\"\n android:authorities=\"${applicationId}.androidx-startup\"\n android:exported=\"false\"\n tools:node=\"merge\">\n <meta-data android:name=\"com.adyen.ipp.api.InPersonPaymentsInitializer\"\n tools:node=\"remove\" \/>\n <\/provider><\/code><\/pre>\nTo manually initialize that component at a later point, add the following code to the POS app.<\/p>\n
For version 2.6.0 or later:<\/p>\n
Since the SDK requires the application to be in the foreground to bind to the service, you need to trigger initialization when your main Activity is visible. Use repeatOnLifecycle<\/code> to ensure that the initialization runs when the Activity is in the RESUMED<\/code> state. <\/p>\noverride fun onCreate(savedInstanceState: Bundle?) {\n super.onCreate(savedInstanceState)\n\n lifecycleScope.launch {\n \/\/ Suspend execution until the Activity is RESUMED\n repeatOnLifecycle(Lifecycle.State.RESUMED) {\n val state = InPersonPaymentsTools.initializeManually(this@MainActivity)\n\n if (state is InitializationState.SuccessfulInitialization) {\n \/\/ SDK is ready\n } else {\n \/\/ Handle failure\n }\n }\n }\n}<\/code><\/pre>\nFor versions earlier than version 2.6.0:<\/p>\n
AppInitializer.getInstance(this)\n .initializeComponent(InPersonPaymentsInitializer::class.java)<\/code><\/pre>\nInitialization status check<\/h3>\n
To check the status of the SDK initialization, you can use one of the following options.<\/p>\n
For version 2.6.0 or later:<\/p>\n
when (val state = InPersonPaymentsTools.getInitializationState()){\n InitializationState.SuccessfulInitialization -> {\n \/\/ SDK is ready. You can now safely proceed.\n }\n\n is InitializationState.FailedInitialization -> {\n \/\/ Handle initialization failure. Log errors or notify the user.\n Log.e(\"MyApp\", \"SDK initialization failed: ${state.failureReasons}\")\n }\n\n else -> Unit\n}<\/code><\/pre>\nor for versions earlier than version 2.6.0 if you need more precise control over the state flow:<\/p>\n
InPersonPayments.initialized\n .filter { it == InitializationState.SuccessfulInitialization } \/\/ Wait until it is true.\n .take(1) \/\/ Take only one item.\n .collect { ready ->\n if (ready) {\n val id = InPersonPayments.getInstallationId()\n \/\/...\n }\n }<\/code><\/pre>\nManage POS app dependency initialization<\/h3>\n
The code that you add to the Application.onCreate()<\/code> method is executed for all processes. In some cases, it can be beneficial to skip the re-execution of the code, for example the initialization of your dependency graph or analytics libraries.<\/p>\nThe following method evaluates specific conditions and returns a boolean value that indicates whether the initialization should be skipped.<\/p>\n
if (InPersonPaymentsTools.shouldSkipAppInitialize(context)) {\n \/\/ Perform actions when initialization should be skipped\n} else {\n \/\/ Proceed with application initialization\n}<\/code><\/pre>\nAdditionally, you can use the following functions:<\/p>\n
\n- \n
suspend InPersonPaymentsTools.getInitializationState()<\/code>: this function observes the initialization state of the SDK and pauses the calling coroutine until the SDK initialization finishes and reaches a success or failure state. You can use this suspend function if an action in your app depends on the SDK being fully initialized.<\/p>\n<\/li>\n- \n
suspend InPersonPaymentsTools.initializeManually()<\/code>: this function triggers initialization of the SDK and waits for the initialization to finish.<\/p>\n<\/li>\n<\/ul>\n4. Use the warm-up function<\/h2>\n
To speed up initiating transactions, you can use the warm-up function. This function checks for a session, configuration changes, and security checks if needed.<\/p>\n
As a best practice, call the warm-up function after the SDK has initialized:<\/p>\n
\n- When the POS app starts.<\/li>\n
- When the POS app returns to the foreground.<\/li>\n<\/ul>\n
To call the warm-up function:<\/p>\n
InPersonPayments.warmUp()<\/code><\/pre>\n5. (Optional) Avoid delays<\/h2>\n
You can avoid delays and speed up the transaction by preparing the card reader outside a transaction flow with configuration and security checks.<\/p>\n
When you start a transaction, the Mobile SDK connects with the card reader to check the reader's configuration. If the configuration is not up to date, the Mobile SDK sends the latest configuration files to the reader. This can take up to to 30 seconds. Additionally, the Mobile SDK performs a security check every 24 hours. To avoid a delay during the transaction flow, you can prepare the card reader by running these checks outside the transaction flow.<\/p>\n
It is possible to start a transaction while the card reader preparation is running. There can be a short delay during the transaction while any remaining checks and configuration updates are completed.<\/p>\n
We recommend preparing the device for transaction every 24 hours or when the configuration has changed.<\/p>\n
To prepare the device outside a transaction flow, call the DeviceManager<\/strong><\/span> prepareDeviceForTransaction<\/code> function as follows, where the device<\/code> is the card reader to prepare.<\/p>\n\/\/ Get the DeviceManager\n val deviceManager = AdyenCardReaders.getInstance(context).deviceManager\n \/\/ Listen for when a device is connected\n deviceManager.connectionState.collect { connectionState ->\n if(connectionState is CardReaderState.Connected) {\n val device = connectionState.cardReaderInfo\n \/\/ Prepare the connected device\n deviceManager.prepareDeviceForTransaction(device)\n }\n }<\/code><\/pre>\n6. Manage the Device Manager UI<\/h2>\n
To use the card reader, operators need to:<\/p>\n