[Multiple Choice Task] Fix UI bugs in multiple choice selectors

[shobhitagarwal1612]

Fixes #2893

Updates UX as per figma mocks

@gino-m PTAL?

[codecov]

Codecov Report

Attention: Patch coverage is 42.52874% with 50 lines in your changes missing coverage. Please review.

Project coverage is 61.90%. Comparing base (94c1ea7) to head (06ca789).

Files with missing lines	Patch %	Lines
...ion/tasks/multiplechoice/MultipleChoiceItemView.kt	35.21%	36 Missing and 10 partials ⚠️
...tasks/multiplechoice/MultipleChoiceTaskFragment.kt	66.66%	0 Missing and 3 partials ⚠️
...asks/multiplechoice/MultipleChoiceTaskViewModel.kt	83.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2899      +/-   ##
============================================
- Coverage     62.22%   61.90%   -0.33%     
+ Complexity     1205     1204       -1     
============================================
  Files           267      268       +1     
  Lines          6380     6441      +61     
  Branches        882      897      +15     
============================================
+ Hits           3970     3987      +17     
- Misses         1863     1898      +35     
- Partials        547      556       +9     

Files with missing lines	Coverage Δ
...lection/tasks/multiplechoice/MultipleChoiceItem.kt	100.00% <100.00%> (ø)
...asks/multiplechoice/MultipleChoiceTaskViewModel.kt	92.18% <83.33%> (-0.46%)	⬇️
...tasks/multiplechoice/MultipleChoiceTaskFragment.kt	69.23% <66.66%> (+4.52%)	⬆️
...ion/tasks/multiplechoice/MultipleChoiceItemView.kt	35.21% <35.21%> (ø)

[gino-m]

Please paste a screenshot into the PR desc when you can. Thanks!

[anandwana001]

How about taking this opportunity to migrate it to jetpack compose?

[shobhitagarwal1612]

Marking this as draft. Working towards migrating the task's UI to compose.

[shobhitagarwal1612]

@gino-m This is now ready for another pass! Migrated the UI to compose and updated styling & unit tests.

[anandwana001]

how about have state and events

something like

val _multiplaeChoiceState = MutableStateFlow<MultiplaeChoiceData>(MultiplaeChoiceData())

val _multiplaeChoiceEvent = MutableSharedFlow<MultiplaeChoiceEvents>()

[shobhitagarwal1612]

Are there any benefits to using sharedFlow in this case?

[anandwana001]

1. all events can be managed at a single place
2. can also prevent the double click
3. no multiple parameters to compose functions

[shobhitagarwal1612]

I tried that but the tests started failing after that. Can we handle that separately?

[anandwana001]

and then we can emit like

multiplaeChoiceEvent(MultiplaeChoiceEvent.ToggleClick(item))

[anandwana001]

we don't need object, right?
we can keep constants as is

[shobhitagarwal1612]

IMO, wrapping this under object makes it easier to use the constants

[anandwana001]

easier to use but object MultipleChoiceTestTags will create a extra memory, object creation

in terms of using, we can directly write MULTIPLE_CHOICE_LIST no object name reference required

[gino-m]

MultipleChoiceTestTags is a singleton, so the memory for the object reference is minimal, if not zero if optimized out by the compiler.

[gino-m]

According to Gemini, top-level declarations are preferred in Kotlin, but haven't validated this yet:

While you can technically use a Kotlin object as a namespace, it's generally not the recommended approach. Here's why:

Why not to use objects as namespaces:

• Top-level declarations are preferred: Kotlin encourages the use of top-level functions and properties, which naturally provide a way to organize code into logical units without creating unnecessary objects.
• Readability and maintainability: Using objects as namespaces can make your code harder to read and understand. Top-level declarations are more straightforward and easier to locate.
• File facade issues (JVM): On the JVM, Kotlin compiles top-level declarations into a file facade class. If you use objects as namespaces, you might encounter naming conflicts with these generated classes.

Recommended alternatives:

• Top-level functions and properties: The preferred way to group related code is to use top-level functions and properties within the same file.
• Packages: For larger projects, use packages to organize your code into meaningful modules.