The Records SDK provides a streamlined and flexible way to manage digital records within your Android application. It acts as a unified entry point for storing, retrieving, updating, and deleting record data, allowing developers to easily integrate document workflows, tagging, filtering, and metadata management.
Built with modern Android architecture principles, the SDK is fully coroutine-compatible, supports reactive data flows with Flow
, and ensures efficient local storage with robust database handling. Whether you’re building a document management tool, a compliance platform, or a file organization feature, the Records SDK handles the heavy lifting so you can focus on building great user experiences.
For complete API reference, please refer to the source code documentation in the GitHub repository: https://github.com/eka-care/eka-health-records-android
Before using the Eka Health Records SDK, ensure your development environment meets the following requirements:
Add the repository to your project-level build.gradle
or settings.gradle
file:
Include the dependency in your app-level build.gradle.kts
file:
Initialise the SDK by creating an implementation of the IOkHttpSetup
interface to provide authentication tokens:
Pass the IOkHttpSetup
implementation to DocumentConfiguration
and call the init
A data transfer object representing document records, used for API communication.
Constants used to specify document categories:
Type ID | Description |
---|---|
lr | Lab Report |
ps | Prescription |
ds | Discharge Summary |
vc | Vaccine Certificate |
in | Insurance |
iv | Invoice |
sc | Scan |
ot | Other |
null | All types (default) |
Enum used for specifying document sort criteria:
Records
InstanceTo begin using the SDK, you must first obtain an instance of RecordsManager
. This instance serves as the single entry point to the SDK and provides access to all available functionality.
Use the following code to initialize and retrieve the instance:
Note: Always pass the application context to ensure proper lifecycle management and avoid memory leaks.
Once you have initialised the recordsManager
instance, you can use it to create a new record entry using the addNewRecord
function. This function is a suspend
function and must be called from a coroutine.
Here’s an example using viewModelScope
and Dispatchers.IO
:
List<File>
— (Required). The files you want to associate with the record.String
— (Required). Identifier for the owner of the record.String?
— (Optional). Used to apply a predefined filter or processing rule.String
— (Optional). Specifies the type of document. Default is "ot"
.Long?
— (Optional). UNIX timestamp representing the date of the document.List<String>
— (Optional). Tags for classifying or grouping records.Important: Ensure this function is called from a coroutine scope such as viewModelScope, and ideally off the main thread using Dispatchers.IO to avoid blocking UI operations.
The getRecords
function allows you to retrieve a list of records for a specific owner. The function returns a Flow
of List<RecordModel>
, enabling asynchronous and reactive collection of record data.
String
— (Required) The unique identifier for the owner whose records are to be fetched.List<String>?
— (Optional) A list of filter IDs to apply during retrieval. If null
, no filters are applied.Boolean
— (Optional, default: false) Whether to include records that have been marked as deleted.String?
— (Optional) Filters records by the specified document type.SortOrder
— (Required) Defines the sorting order of the results (e.g., ascending, descending). This must be provided.Returns a Flow<List<RecordModel>>
that emits updates to the list of records matching the criteria.
Note: Since this function returns a Flow, it must be collected from a coroutine scope to receive updates.
The getRecordsCountGroupByType
function returns the total number of records for a specific owner, grouped by document type. This is useful for analytics, reporting, or building UI elements like dashboards or filters.
String
— (Required) The unique identifier for the owner whose records are being counted.List<String>?
— (Optional) A list of filter IDs to narrow down the results. If null
, all records for the owner are considered.Returns a Flow<List<DocumentTypeCount>>
, where each DocumentTypeCount
represents a document type and the associated count of records.
Note: This function is reactive and returns a Flow, which should be collected within a coroutine.
The updateRecord
function allows you to update the metadata of an existing record, such as the document date or document type. This is a suspend
function and must be called from within a coroutine.
String
— (Required) The unique identifier of the record to be updated.Long?
— (Optional) The new document date, represented as a UNIX timestamp. Pass null
to leave unchanged.String?
— (Optional) The new type of the document. Pass null
to keep the existing type.Returns a String?
— the ID of the updated record if the operation is successful, or null
if the update fails.
Note: Call this function from a coroutine (e.g., viewModelScope) to avoid blocking the main thread.
The getRecordDetailsById
function retrieves the full details of a specific record using its unique identifier. This is a suspend
function and must be called from a coroutine.
String
— (Required) The unique identifier of the record whose details are to be retrieved.Returns a RecordModel?
— the complete record object if found, or null
if the record does not exist.
Note: Always check for null as the record might not exist or could have been deleted.
The deleteRecords
function allows you to delete one or more records by their unique identifiers. This operation is performed asynchronously and must be called from a coroutine.
List<String>
— (Required) A list of unique record IDs to be deleted.The clearAllData
function permanently deletes all local data stored by the SDK. This includes all records, metadata, and cached information managed by the SDK’s local database.
⚠️ Caution: Use this method only when a full data reset is required, such as during user logout or when resetting the app state. Ensure the user is properly informed before performing this action.
The syncRecords
function triggers the synchronisation of records for a specific owner. This ensures that the local records are kept in sync with a remote server or cloud service (if applicable). The sync process is initiated asynchronously.
String
— (Required) The unique identifier for the owner whose records need to be synchronised.Note: The synchronisation process is handled asynchronously, and the app may need to listen for completion or errors. Ensure proper handling of network conditions and sync progress.
The refreshRecords
function triggers a background sync process to refresh records for a specific owner, optionally applying filters. It uses WorkManager to ensure the sync task runs reliably in the background, even when the app is closed or the device is restarted. This operation ensures the records are up-to-date based on the latest data from the server or cloud service.
Context
— (Required) The application context used to initialise and enqueue the background task.String?
— (Required) The unique identifier for the owner whose records should be refreshed. Can be null
in case there is no specific owner.List<String>?
— (Optional) A list of filter IDs to apply during the record refresh process. If null
, no filters will be applied.RecordsSync
worker, which processes the record refresh asynchronously.Note: This function will enqueue a background task that will run once the device meets the necessary network requirements.
The setLogInterceptor
function allows you to set a custom log interceptor for capturing and processing log events. This is useful for integrating with external logging systems, monitoring tools, or simply capturing logs in a custom format.
LogInterceptor
— (Required) A custom listener that implements the LogInterceptor
interface. This listener will be notified of all log events that occur in the SDK.Note: This function allows developers to implement custom logging behavior that suits their needs, such as sending logs to a server or filtering events based on severity.
LogInterceptor
InterfaceThe LogInterceptor
interface defines a method for logging events. Implement this interface to capture and process log data from the SDK.
Note: The logEvent method is called every time an event occurs in the SDK. You can implement custom logic within this method to handle logs as needed.
EventLog
Data ClassThe EventLog
data class encapsulates the log event data, including any parameters and an optional message. It is used to store the event information that will be passed to the LogInterceptor
.
JSONObject
— (Optional) A JSONObject
containing key-value pairs of parameters associated with the event. This can be used to include additional metadata with the log event.String?
— (Optional) A message describing the event. This is the main content of the log.RecordStatus
EnumThe RecordStatus
enum represents the various stages of a record’s synchronization lifecycle. It is used internally and externally to track and represent the current state of a record as it moves through the upload and sync pipeline.
NONE (0)
Default or initial state.
WAITING_TO_UPLOAD (1)
The record is queued and waiting to begin the upload process.
WAITING_FOR_NETWORK (2)
The record is ready to upload but a required network connection is not yet available.
SYNCING (3)
The record is currently in the process of being synchronised with the server.
SYNC_FAILED (4)
The record sync attempt has failed. Retry logic may apply based on implementation.
SYNC_SUCCESS (5)
The record has been successfully synchronised with the server.
Note: These statuses are especially useful for building UI indicators (e.g., progress spinners, error states) or managing sync retries in your application.
The PhotoPickerHost
interface provides an abstraction layer for handling various media input actions such as taking a photo, picking an image, selecting a PDF, or scanning documents. Implementing this interface allows you to delegate these operations to your app’s UI layer using activity or fragment launchers.
PhotoPickerHost
InterfacetakePhoto(cameraIntent: Intent, uri: Uri)
Launches the camera to take a photo and saves it to the specified Uri
.
pickPhoto(request: PickVisualMediaRequest)
Opens a system picker for selecting an image from the device.
pickPdf()
Launches a file picker to select one or more PDF documents.
scanDocuments(request: IntentSenderRequest)
Starts a document scanning activity (e.g., using a third-party scanner or system service).
Before initiating any media actions, you must set a host implementation using MediaPickerManager.setHost(...)
. This connects the SDK’s internal media operations to your app’s UI.
Note: All launchers (cameraLauncher, mediaPickerLauncher, etc.) should be properly registered using the Activity Result API (registerForActivityResult(…)) in your Activity or Fragment.
The Records SDK provides a streamlined and flexible way to manage digital records within your Android application. It acts as a unified entry point for storing, retrieving, updating, and deleting record data, allowing developers to easily integrate document workflows, tagging, filtering, and metadata management.
Built with modern Android architecture principles, the SDK is fully coroutine-compatible, supports reactive data flows with Flow
, and ensures efficient local storage with robust database handling. Whether you’re building a document management tool, a compliance platform, or a file organization feature, the Records SDK handles the heavy lifting so you can focus on building great user experiences.
For complete API reference, please refer to the source code documentation in the GitHub repository: https://github.com/eka-care/eka-health-records-android
Before using the Eka Health Records SDK, ensure your development environment meets the following requirements:
Add the repository to your project-level build.gradle
or settings.gradle
file:
Include the dependency in your app-level build.gradle.kts
file:
Initialise the SDK by creating an implementation of the IOkHttpSetup
interface to provide authentication tokens:
Pass the IOkHttpSetup
implementation to DocumentConfiguration
and call the init
A data transfer object representing document records, used for API communication.
Constants used to specify document categories:
Type ID | Description |
---|---|
lr | Lab Report |
ps | Prescription |
ds | Discharge Summary |
vc | Vaccine Certificate |
in | Insurance |
iv | Invoice |
sc | Scan |
ot | Other |
null | All types (default) |
Enum used for specifying document sort criteria:
Records
InstanceTo begin using the SDK, you must first obtain an instance of RecordsManager
. This instance serves as the single entry point to the SDK and provides access to all available functionality.
Use the following code to initialize and retrieve the instance:
Note: Always pass the application context to ensure proper lifecycle management and avoid memory leaks.
Once you have initialised the recordsManager
instance, you can use it to create a new record entry using the addNewRecord
function. This function is a suspend
function and must be called from a coroutine.
Here’s an example using viewModelScope
and Dispatchers.IO
:
List<File>
— (Required). The files you want to associate with the record.String
— (Required). Identifier for the owner of the record.String?
— (Optional). Used to apply a predefined filter or processing rule.String
— (Optional). Specifies the type of document. Default is "ot"
.Long?
— (Optional). UNIX timestamp representing the date of the document.List<String>
— (Optional). Tags for classifying or grouping records.Important: Ensure this function is called from a coroutine scope such as viewModelScope, and ideally off the main thread using Dispatchers.IO to avoid blocking UI operations.
The getRecords
function allows you to retrieve a list of records for a specific owner. The function returns a Flow
of List<RecordModel>
, enabling asynchronous and reactive collection of record data.
String
— (Required) The unique identifier for the owner whose records are to be fetched.List<String>?
— (Optional) A list of filter IDs to apply during retrieval. If null
, no filters are applied.Boolean
— (Optional, default: false) Whether to include records that have been marked as deleted.String?
— (Optional) Filters records by the specified document type.SortOrder
— (Required) Defines the sorting order of the results (e.g., ascending, descending). This must be provided.Returns a Flow<List<RecordModel>>
that emits updates to the list of records matching the criteria.
Note: Since this function returns a Flow, it must be collected from a coroutine scope to receive updates.
The getRecordsCountGroupByType
function returns the total number of records for a specific owner, grouped by document type. This is useful for analytics, reporting, or building UI elements like dashboards or filters.
String
— (Required) The unique identifier for the owner whose records are being counted.List<String>?
— (Optional) A list of filter IDs to narrow down the results. If null
, all records for the owner are considered.Returns a Flow<List<DocumentTypeCount>>
, where each DocumentTypeCount
represents a document type and the associated count of records.
Note: This function is reactive and returns a Flow, which should be collected within a coroutine.
The updateRecord
function allows you to update the metadata of an existing record, such as the document date or document type. This is a suspend
function and must be called from within a coroutine.
String
— (Required) The unique identifier of the record to be updated.Long?
— (Optional) The new document date, represented as a UNIX timestamp. Pass null
to leave unchanged.String?
— (Optional) The new type of the document. Pass null
to keep the existing type.Returns a String?
— the ID of the updated record if the operation is successful, or null
if the update fails.
Note: Call this function from a coroutine (e.g., viewModelScope) to avoid blocking the main thread.
The getRecordDetailsById
function retrieves the full details of a specific record using its unique identifier. This is a suspend
function and must be called from a coroutine.
String
— (Required) The unique identifier of the record whose details are to be retrieved.Returns a RecordModel?
— the complete record object if found, or null
if the record does not exist.
Note: Always check for null as the record might not exist or could have been deleted.
The deleteRecords
function allows you to delete one or more records by their unique identifiers. This operation is performed asynchronously and must be called from a coroutine.
List<String>
— (Required) A list of unique record IDs to be deleted.The clearAllData
function permanently deletes all local data stored by the SDK. This includes all records, metadata, and cached information managed by the SDK’s local database.
⚠️ Caution: Use this method only when a full data reset is required, such as during user logout or when resetting the app state. Ensure the user is properly informed before performing this action.
The syncRecords
function triggers the synchronisation of records for a specific owner. This ensures that the local records are kept in sync with a remote server or cloud service (if applicable). The sync process is initiated asynchronously.
String
— (Required) The unique identifier for the owner whose records need to be synchronised.Note: The synchronisation process is handled asynchronously, and the app may need to listen for completion or errors. Ensure proper handling of network conditions and sync progress.
The refreshRecords
function triggers a background sync process to refresh records for a specific owner, optionally applying filters. It uses WorkManager to ensure the sync task runs reliably in the background, even when the app is closed or the device is restarted. This operation ensures the records are up-to-date based on the latest data from the server or cloud service.
Context
— (Required) The application context used to initialise and enqueue the background task.String?
— (Required) The unique identifier for the owner whose records should be refreshed. Can be null
in case there is no specific owner.List<String>?
— (Optional) A list of filter IDs to apply during the record refresh process. If null
, no filters will be applied.RecordsSync
worker, which processes the record refresh asynchronously.Note: This function will enqueue a background task that will run once the device meets the necessary network requirements.
The setLogInterceptor
function allows you to set a custom log interceptor for capturing and processing log events. This is useful for integrating with external logging systems, monitoring tools, or simply capturing logs in a custom format.
LogInterceptor
— (Required) A custom listener that implements the LogInterceptor
interface. This listener will be notified of all log events that occur in the SDK.Note: This function allows developers to implement custom logging behavior that suits their needs, such as sending logs to a server or filtering events based on severity.
LogInterceptor
InterfaceThe LogInterceptor
interface defines a method for logging events. Implement this interface to capture and process log data from the SDK.
Note: The logEvent method is called every time an event occurs in the SDK. You can implement custom logic within this method to handle logs as needed.
EventLog
Data ClassThe EventLog
data class encapsulates the log event data, including any parameters and an optional message. It is used to store the event information that will be passed to the LogInterceptor
.
JSONObject
— (Optional) A JSONObject
containing key-value pairs of parameters associated with the event. This can be used to include additional metadata with the log event.String?
— (Optional) A message describing the event. This is the main content of the log.RecordStatus
EnumThe RecordStatus
enum represents the various stages of a record’s synchronization lifecycle. It is used internally and externally to track and represent the current state of a record as it moves through the upload and sync pipeline.
NONE (0)
Default or initial state.
WAITING_TO_UPLOAD (1)
The record is queued and waiting to begin the upload process.
WAITING_FOR_NETWORK (2)
The record is ready to upload but a required network connection is not yet available.
SYNCING (3)
The record is currently in the process of being synchronised with the server.
SYNC_FAILED (4)
The record sync attempt has failed. Retry logic may apply based on implementation.
SYNC_SUCCESS (5)
The record has been successfully synchronised with the server.
Note: These statuses are especially useful for building UI indicators (e.g., progress spinners, error states) or managing sync retries in your application.
The PhotoPickerHost
interface provides an abstraction layer for handling various media input actions such as taking a photo, picking an image, selecting a PDF, or scanning documents. Implementing this interface allows you to delegate these operations to your app’s UI layer using activity or fragment launchers.
PhotoPickerHost
InterfacetakePhoto(cameraIntent: Intent, uri: Uri)
Launches the camera to take a photo and saves it to the specified Uri
.
pickPhoto(request: PickVisualMediaRequest)
Opens a system picker for selecting an image from the device.
pickPdf()
Launches a file picker to select one or more PDF documents.
scanDocuments(request: IntentSenderRequest)
Starts a document scanning activity (e.g., using a third-party scanner or system service).
Before initiating any media actions, you must set a host implementation using MediaPickerManager.setHost(...)
. This connects the SDK’s internal media operations to your app’s UI.
Note: All launchers (cameraLauncher, mediaPickerLauncher, etc.) should be properly registered using the Activity Result API (registerForActivityResult(…)) in your Activity or Fragment.