Skip to main content

React Native Guide

Plugin for RN applications that utilize Credify Collection SDK to collect data from devices, supports only Android platform.

This plugin acts as a wrapper for Credify Native SDK.

To gain access application will need user permission on these permissions:

caution

SDK collection method will only collect data if the permission is granted, for example if user only accepted location and call logs, collection method will return a JSOn object with these two only to avoid exceptions

  • SMS: READ_SMS
info
  • Minimum SDK Required 21
  • Target SDK Required 31+

General usage guide

1. Install the SDK

Install the wrapper:

npm i react-native-credify-plugin

Using Android native modules in React doesn't support expo-managed workflow, application must be prebuilt with full control over Android platform.

If you are using an expo project, run the following command to rebuild the Android platform application.

npx expo prebuild

2. Reviewing Permissions

Make sure that your application includes the following permissions in Android manifest file:

<uses-permission android:name="android.permission.READ_SMS" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.USE_BIOMETRIC" />

3. Importing library

You can start using the SDK using the following import

import {
collectData,
initialize,
requestPermissions,
setUserID,
setUserInfo,
getPermissionsStatus,
} from 'react-native-credify-plugin'
//...

4. Initializing the SDK

To start using SDK functionalities SDK must be initialized with some identifiers that will be used to tag information collected with the user that is using the application. Usually initialization should take place right after user login.

Sample Initialization

useEffect(() => {
initialize('your token goes here')
.then(() => {
// ideally after login, user identifier must be set to tag all collected data with the user
// user id can be set
setUserID('<logged in user ID>')
// or use this method tag all collected data with more user-related info
setUserInfo(
'<User ID here>',
'<user full name here>',
'<mobile number here>',
)
})
.catch((error) => {
console.log('error:', error)
// when an exception is thrown it probably means there was a critical error while initializing, check error code and error message inside the exception for more information.
})
})

5. Requesting Permissions

User consent / approval on permissions is needed to run the collection method, to do so you can choose one of the following options:

  1. Ask user for permission from inside the client application code (can be useful if client application wants to show custom UI before asking for permissions)
  2. Or you can simply call the SDK method requestPermissions which requests permissions for collection items that your application can collect.
requestPermissions()

6. Requesting permissions

SDK provies a method to get status of each enabled collection type and permissions that are accepted and/or rejected, this method can be used to check which collection types will be collected and sent.

Permission status will be checked for all collection types that are enabled.

Sample Permissions Status Response

{
"accepted_permissions": ["android.permission.READ_SMS"],
"rejected_permissions": [],
"enabled_collection": {
"SMS_LOG": true,
"DEVICE_INFO": true
}
}

Sample Permissions Status Request

getPermissionsStatus()

7. Collecting and Sending Data

After gaining proper approval, you can can call CollectData to collect and send collected data securely.

// collect data
collectData()
.then((data) => {
// data returned contains a JSON Object that contains each type of data collected and status of collecting and sending the data
// result 200 means success
// other results might indicate error, please check the error codes below for more information.
// use data
// data contains session_id property which contains and ID related to collection process and can be used in debugging
})
.catch((error) => {
console.log('error:', error)
// when an exception is thrown it probably means there was a critical error while initializing, check error code and error message inside the exception for more information.
})

The result of collection is a JSON string that can be decoded and can have one of the 2 formats:

  1. in case of remote data collection:
{
"sms_log": "200",
"session_id": "<UDID Here>"
}

each collection type will have a property that contains HTTP code for the remote request response code session_id contains a unique UDID that gets sent on each request in the collection process and can be used in debugging

  1. local data collection
{
"sms_log": { ... },
}

each collection type will have a property that contains the result of the data collected

Error Codes and Debugging

Initialization error codes

Error CodeDescriptionRecommendation
100Activity or Context nullMake sure the activity is not null and avoid placing initialization in splash activity
104Credify API configuration responded but configuration is null or mismatchingUpdate your Credify SDK
Invalid token, response code ...Credify API configuration responded with non-success status codeReview your token and make sure it is valid
103Unhandled ExceptionCheck logcat logs for more info

Collection error codes

These are returned on each data type collected

Error CodeDescriptionRecommendation
200Data was collected and sent properly
100Activity or Context nullMake sure the activity is not null and avoid placing initialization in splash activity
104Credify API configuration responded but configuration is null or mismatchingUpdate your Credify SDK
103Unhandled ExceptionCheck logcat logs for more info
other valuesMeans that data was collected properly, but a network/service error occurred while sendingGet in touch with Credify Team to investigate further

Debugging

Simply run your application in debug mode and filter logcat logs with the tag name "CredifySDK", logs messages under this tag contains log of all steps taken by the SDK and contains informational logs, logical errors, handled native exceptions and unhandled native exceptions.