DexCare SDK Frequently Asked Questions

I found an issue with the iOS/Android SDK. Where can I provide details?

Non-urgent bug reports can be added as issues against the DexCare SDK download GitHub repositories:

For issues that require immediate action, you can submit a ticket on the DexCare Service Desk. Your DexCare contact will have provided you access and instructions on how to access it.

  • For complete outages, select priority of P1. P1 issues will page our on-call engineers for immediate response.
  • For partial outages that are affecting the ability to use the platform or SDK, select P2.
  • All other defects or enhancement requests are P3.

What screens and user interface are included with the SDK?

The DexCare SDK will display its own screens for the virtual visit waiting room, video conference, and chat inside the virtual visit. All other UI must be built and owned by your app.

What modes of care are supported within the SDK?

The DexCare SDK supports creation of the following types of visits:

  • Scheduled for a particular Provider (Primary Care)
  • Scheduled Retail
  • On-Demand Virtual
  • On-Demand Phone

Can the SDK be used without signing the user in first?

Yes and No. The SDK has some endpoints that do not require a valid OAuth2 access token, however any bookings (retail, virtual, etc), requires a valid OAuth2 access token retrieved from your Identity.

You can use the SDK without a valid access token to for example, load timeslots available to book.

What languages are the Android and iOS SDKs written in?

Kotlin for Android, Swift for iOS.

We aim to stay at the latest versions of these languages.

Absolutely! We support both iOS Universal Links and Androids App Links. These are supported on the th.care sub domain. So as an example, when a user schedules a virtual visit, we will send an email with a rejoin link (contained in the th.care sub domain). If universal links or app links are set up, this will automatically open your mobile app.

Note: You must set up this yourself on your app and it is not handled by the SDK. If you would like this set up for your app, please send in a DexCare service desk ticket with the appropriate information needed for the server to serve.

What if the Google Play store rejects a DexCareSDK app due to manifest permissions?

Your app should provide a dialog or layout to display a Prominent Disclosure (PD) request to your users.

The following permissions are used during a virtual visit video call (TokBox SDK needed):

  • Manifest.permission.CAMERA,
  • Manifest.permission.RECORD_AUDIO,
  • Manifest.permission.READ_PHONE_STATE,
  • Manifest.permission.BLUETOOTH_CONNECT

Note that the above permissions are runtime permissions so your app needs to show an information dialog before starting a virtual visit so the user can accept their usage. The user will then be able to start a video call with the doctor.

Below are additional permissions for which app developers need to display the PD details:

android.permission.BLUETOOTH_CONNECT
OpenTok Android SDK requires this permission to be enabled for API level 31 and above.
android.permission.READ_PHONE_STATE
OpenTok Android SDK requires this permission in API level 22 and lower, and 31 and above.
android.permission.CAMERA
Used by OpenTok, if your app does not use the default video capture and does not access the camera, you can remove this permission.
android.permission.RECORD_AUDIO
If your app does not use the default audio device and does not access the microphone, you can remove this permission.
android.permission.MODIFY_AUDIO_SETTINGS
If your app does not use the default audio device and does not access the microphone, you can remove this permission.
android.permission.BLUETOOTH
The default audio device supports Bluetooth audio. If your app does not use the default audio device and does not use Bluetooth, you can remove this permission.
android.permission.ACCESS_NETWORK_STATE
It is install time permission and it is needed to call internal API using Wifi/data since we have to check internet connection status before network call.

Apps can choose to remove any of the permissions listed below that may not be used

ACCESS_NETWORK_STATE , BLUETOOTH, WIFI_STATE particularly if

For example, this removes the android.permission.ACCESS_NETWORK_STATE permission:

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" tools:node="remove"/>

See this post for more information on Android permissions.