API for validation in the sdc lib

[jingtang10]

Estimated effort: 3 days
Estimated date of completion: 18th June 2021

We want to be able to validate the questionnaire response without necessarily saving the questionnaire response. This can be exposed as a new API in the sdc lib.

this would help opensrp/fhircore#19 (comment): Validate details as entered by the user for data types and also mandatory/optional fields based on the questionnaire

[vincent-karuri]

A few workflows can be supported here:

1. Validate fields on form submission
2. Validate fields when they lose focus e.g. when a user is done inputting text into a field
3. Validate fields as the user is typing into a field e.g. onTextChanged
4. In a multiple-step form, we can do validation when the user attempts to navigate to the next step/page

For multi-step forms, I don't think 1 will be a good UX. 3 might result in multiple calls to validate but the user gets immediate feedback. 2 and 4 are kind of middle grounds with different granularity.

[joiskash]

The status is a property with the cardinality of 1..1 in the FHIR Spec. Since the SDC creates the Questionnaire Response, we will need to either

1. Explicitly let the developer know that we do not touch the "status" and it is the applications responsibility
2. Expose APIs to allow the application to change the "status" of the questionnaire response while the SDC is being used.

[jingtang10]

@vincent-karuri, I believe @kunjan8794's change #164 is doing a mixture of 2 and 3. And 2 and 3 are probably what we should continue to do no matter what. I can also imagine adding some kind of configuration for the questionnaire fragment for this behavior (turn it on or off).

About 1: upon submission, this depends on how submission is done. At the moment the developer can read the questionnaire any time from the fragment, and the submission button is outside of the questionnaire fragment (this might change i guess). So if we provide a validation API (fun validate(questionnaire: Questionnaire, questionnaireResponse: QuestionnaireResponse): ValidationResult) then the developer can decide if they want to allow submission or not (and optionally create a dialog).

About 4, I think this depends on the implementation of #186. The first question is do we want the paging to be handled within the questionnaire fragment or should it be outside (similar to how the submission button is outside the fragment for now). There might be a case for an API that validates the answers for all questions and display error message accordingly.

@joiskash I vote for 1 for now. I think a wider discussion needs to happen before we go for 2. And certainly would help to get opinions from people active on the questionnaire chat channel in fhir chat.

[vincent-karuri]

@jingtang10 I think pagination can be a core feature. It's implicitly optional because one can always simply define a single page if they don't desire pagination? Unless you were referring to what happens when a page has errors and the user tries to navigate to a different page. Then, yes, I agree that what happens in that case can be made configurable for the implementing app.

[Tarun-Bhardwaj]

Hi @vincent-karuri , are there any updates on this issue? Is there any ETA or the pending effort that you can provide?

[jingtang10]

@Tarun-Bhardwaj we need to find someone to work on this issue.

[Tarun-Bhardwaj]

@joiskash, would you like to pick up this high priority issue for Q2 release? I will create a separate thread between you, Jing and myself to discuss the details.

[joiskash]

Sure @Tarun-Bhardwaj i can pick this up as my next task

[Tarun-Bhardwaj]

@joiskash , updated the estimated completion date as 18th June as per our discussion.

[joiskash]

So is the expectation that the client application that is using the sdk will call a function like fragment.validateCurrentQuestionnaireResponse() ? or is this an API internal to the SDC library? @jingtang10

[Tarun-Bhardwaj]

@jingtang10 , do you have any update for Kashyap on his last comment above?

[joiskash]

Yes, jing did update me on this, just copying the response here for reference

1. So the simplest api we can build is probably just giving a questionnaire and questionnaire response and we check all the answers to see if they're valid answers
   so that's just entirely for the client
2. another thing we can do is to trigger a UI refresh to show any error messages
   so if you're a developer, you may want to check that all questions are answered correctly before letting the user submit the questionnaire

3. We also need to check if required answers have been completed

[jingtang10]

according to earlier discussions - there's another part of this which is to allow the UI to reflect the validation result on demand -- this requires a little bit of design. @joiskash can you maybe write down your thoughts here?

[joiskash]

So in the current state, ViewHolders with TextInputEditText uses the function applyValidationResult which uses the TextInputEditText.error property to display validation messages. This function is triggered on the change listener of the TextInputEditText.

We could probably extract an interface with an API displayValidationMessage and make all the ViewHolders with TextInputEditText to implement it. Only thing is I cant figure out is how we can expose a handle for the developer to use to trigger this.

[jingtang10]

let's handle this in a the new ticket.