Some Radio Buttons seems to deselect automatically after selection.

[dubdabasoduba]

Describe the bug

• Some radio buttons deselect automatically when selected.
• Attached are the questions with such behaviors.
  new_pregnancy_registration.json.zip
• This happens with the latest SDK code on main

Component
SDC library

To Reproduce
Steps to reproduce the behavior:
Load the attached form to the SDK then test using the steps shown on the attached video
https://user-images.githubusercontent.com/4817531/212714001-5b944d84-d6ed-4a6a-9927-f892ac73a9f8.mov

Expected behavior

• The selections on a radio button should only change if the radio button is clicked on and not automatically.

Smartphone (please complete the following information):

• Device: Xiaomi 10T pro
• Android version: Android 11

[santosh-pingle]

I also see below issues

• When single choice question get enabled and user try to provide input by clicking one of the answer option, it does not accept the input.
• nested question with type string of enabled question does not accept the input, keyboard get closed when user start typing the input

Screen.Recording.2023-01-17.at.3.39.18.PM.mov

Screen.Recording.2023-01-17.at.3.43.52.PM.mov

[santosh-pingle]

Basically, these issues are observed on nested question items of the question when it get enabled.

[omarismail94]

I ran git bisect, and found this issue first started appearing with the introduction of repeated groups:

c888d5c75e7c996406d4af0f1d10893692388fc6 is the first bad commit
commit c888d5c75e7c996406d4af0f1d10893692388fc6
Author: Kevin Most <kevinmost@users.noreply.github.com>
Date:   Thu Nov 10 09:19:56 2022 -0500

    Repeated groups (#1559)
    
    Support repeated groups

 .../main/assets/repeated_group_questionnaire.json  |  92 +++++
 .../android/fhir/catalog/ComponentListViewModel.kt |   5 +
 catalog/src/main/res/menu/component_menu.xml       |   8 +-
 catalog/src/main/res/values/strings.xml            |   3 +-
 .../datacapture/MoreQuestionnaireItemComponents.kt |   2 +-
 .../fhir/datacapture/QuestionnaireViewModel.kt     | 131 +++++--
 .../QuestionnaireItemGroupViewHolderFactory.kt     |  15 +
 .../questionnaire_item_group_header_view.xml       |  36 +-
 datacapture/src/main/res/values/strings.xml        |   1 +
 .../fhir/datacapture/QuestionnaireViewModelTest.kt | 406 ++++++++++++---------
 .../QuestionnaireItemGroupViewHolderFactoryTest.kt |  30 ++
 11 files changed, 498 insertions(+), 231 deletions(-)
 create mode 100644 catalog/src/main/assets/repeated_group_questionnaire.json

looking further into the change that caused this

[omarismail94]

Leaving my debugging notes here:

We don’t seem to save the answers right now to the questionnaireResponse object. Culprit function seems to be createQuestionnaireResponseItem (pasted below). Looking at the logic, it seems to be that if the Type is GROUP only, do we go through the nested answers and add them to questionnaireResponse.

When I set the type key to group as opposed to choice in any outer item key in the JSON attached to this file , the radio buttons that are enabled do get selected. Will continue debugging tomorrow

fun Questionnaire.QuestionnaireItemComponent.createQuestionnaireResponseItem():
  QuestionnaireResponse.QuestionnaireResponseItemComponent {
  return QuestionnaireResponse.QuestionnaireResponseItemComponent().apply {
    linkId = this@createQuestionnaireResponseItem.linkId
    answer = createQuestionnaireResponseItemAnswers()
    if (hasNestedItemsWithinAnswers && answer.isNotEmpty()) {
      this.addNestedItemsToAnswer(this@createQuestionnaireResponseItem)
    } else if (this@createQuestionnaireResponseItem.type ==
        Questionnaire.QuestionnaireItemType.GROUP
    ) {
      this@createQuestionnaireResponseItem.item.forEach {
        this.addItem(it.createQuestionnaireResponseItem())
      }
    }
  }
}

[omarismail94]

I found a simple solution, which is changing the statement:

    } else if (this@createQuestionnaireResponseItem.type ==
        Questionnaire.QuestionnaireItemType.GROUP
    ) {

to just an else:

    } else  {
      this@createQuestionnaireResponseItem.item.forEach {
        this.addItem(it.createQuestionnaireResponseItem())
      }

however, I am not sure if this diverts us from the FHIR standard (I am still a novice when it comes to the standard). If a Questionnaire Item type is "choice" or "text", can it have child items? The link below states that the type "group" should have at least one child item, but is unclear whether other types can:
https://www.hl7.org/fhir/valueset-item-type.html

[omarismail94]

Answer to my own question:

Anything but display items can have child items. https://www.hl7.org/fhir/questionnaire-definitions.html#Questionnaire.item.item

[omarismail94]

@dubdabasoduba is there a reason for the questionnaire attached to have nested items? While we find a fix to support nested items, is it possible to flatten out the items?

[dubdabasoduba]

@omarismail94 yes, the nested items make it easier to write the enableWhen expressions. Instead of replicating the same enableWhen expression you just write it for the parent.

[dubdabasoduba]

The flattened forms work well FYI. I tested them on our imlementation

[omarismail94]

Thanks, good to know the flattened forms work! I know it isn't as nice as nested, but at least it unblocks you while we work on this issue. I had an initial solution working, but it created new problems when validating the questionnaire :(

[omarismail94]

Final finding for today, it seems like this is a known issue in our codebase. Looking at the test files, I see a unit test that has the same setup as this issue, but is ignored. Seems like Kashyap wrote this test, so will chat with him if he shows up to the developer call tomorrow

[santosh-pingle]

@joiskash

[jingtang10]

Updated the questionnaire to remove noise:

new_pregnancy_registration_min.json.txt

@dubdabasoduba please try to include minimum examples while creating issuse in the future (removing unnecessary information in your example and just the bare minimum required to reproduce the problem) - that makes it much easier to debug and to get to the bottom of the issue more quickly.

[dubdabasoduba]

Updated the questionnaire to remove noise:

new_pregnancy_registration_min.json.txt

@dubdabasoduba please try to include minimum examples while creating issuse in the future (removing unnecessary information in your example and just the bare minimum required to reproduce the problem) - that makes it much easier to debug and to get to the bottom of the issue more quickly.

Makes sense.

[jingtang10]

@dubdabasoduba will you please test if PR #1881 fixes your issue?

[dubdabasoduba]

@dubdabasoduba will you please test if PR #1881 fixes your issue?

I will test and raise a ticket for bugs if any

[dubdabasoduba]

This works well. @jingtang10 Thanks