Add Reference class to display string function

[omarismail94]

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Fixes #1735

Description
Add Reference type and obtain the field to display the string of on the UI.

Follow-up question: are there other class types we could be missing here other than Reference?

Alternative(s) considered
N/A

Type
Choose one: (Bug fix | Feature | Documentation | Testing | Code health | Builds | Releases | Other)

Screenshots (if applicable)

device-2022-11-30-223358.mp4

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
• I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
• I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
• I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
• I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[jingtang10]

thanks @omarismail94!

[jingtang10]

thanks @omarismail94!

[omarismail94]

@jingtang10 PTAL. I resolved your comment and also moved where the displayString function is called to MoreAnswerOptions to be in the same location where displayString value is called for QuestionnaireItemAnswerOptionComponent.

I wanted to come up with one function to combine both like this:

internal val Questionnaire.QuestionnaireItemAnswerOptionComponent.displayString: String
  get() = displayString(null, value)

internal fun QuestionnaireResponse.QuestionnaireResponseItemAnswerComponent.displayString(
  context: Context
) = displayString(context, value)


private fun displayString(context: Context?, value: Type?) : String =
  return when(value) {
   //logic
  }
    

however, the logic becomes divergent. An example: in QuestionnaireItemAnswerOptionComponent, if the value is DateType, we just return value.primitiveValue(); so if we pass 2022-01-01 it will return 2022-01-01.

For DateTypes in QuestionnaireResponseItemAnswerComponent, we return value.localDate?.localizedString; so if we pass 2022-01-01, it will return 01/01/22.

Do we want to make what is displayed consistent, or is there a reason there is a difference between how QuestionnaireItemAnswerOptionComponents and QuestionnaireResponseItemAnswerComponent`s are displayed?

[jingtang10]

@jingtang10 PTAL. I resolved your comment and also moved where the displayString function is called to MoreAnswerOptions to be in the same location where displayString value is called for QuestionnaireItemAnswerOptionComponent.

I wanted to come up with one function to combine both like this:

internal val Questionnaire.QuestionnaireItemAnswerOptionComponent.displayString: String
  get() = displayString(null, value)

internal fun QuestionnaireResponse.QuestionnaireResponseItemAnswerComponent.displayString(
  context: Context
) = displayString(context, value)


private fun displayString(context: Context?, value: Type?) : String =
  return when(value) {
   //logic
  }
    

however, the logic becomes divergent. An example: in QuestionnaireItemAnswerOptionComponent, if the value is DateType, we just return value.primitiveValue(); so if we pass 2022-01-01 it will return 2022-01-01.

For DateTypes in QuestionnaireResponseItemAnswerComponent, we return value.localDate?.localizedString; so if we pass 2022-01-01, it will return 01/01/22.

Do we want to make what is displayed consistent, or is there a reason there is a difference between how QuestionnaireItemAnswerOptionComponents and QuestionnaireResponseItemAnswerComponent`s are displayed?

I don't think they need to be different - please unify them.

[omarismail94]

@jingtang10 Unified the functions. With regards to existing tests that I needed to change, I only had to change MoreAnswerOptionsTest; I had to change the display format of the Date

[jingtang10]

discussed with @omarismail94 - will refactor and make context mandatory, and then maybe move the extension function to Type instead.

[omarismail94]

discussed with @omarismail94 - will refactor and make context mandatory, and then maybe move the extension function to Type instead.

implemented this

[jingtang10]

thanks omar!