Support generic representation of Resources in a list view

[vincent-karuri]

We want to have the ability to present a generic list of Resources e.g. patients, encounters etc.

A few considerations and challenges:

1. Different Resources may have different fields of interest to display i.e. some more, some less, some common, some unique etc.
2. Usually we would handle 1 with separate viewholders/layouts in Android. Is there room to use a single configurable viewholder? Does this mean defining a layout via a Resource?
3. Can we use a single view e.g. a fragment (through it's viewmodel) to handle state management for all Resource types in a scalable way?

[vincent-karuri]

@pld suggested looking into the List Resource. My initial thoughts are that it seems appropriate for the use case that is holding a list of filtered Resources e.g. from a search query.

It's however not immediately apparent to me that it would support our other needs as far as defining configurable displays for the list data. Any ideas are welcome.

[vincent-karuri]

@jingtang10 maybe this is something we can discuss in Thursday's call to get a few ideas going?

[vincent-karuri]

This seems to be the concept of server-driven UI.

Airbnb went to the extreme of defining it's on layout language https://proandroiddev.com/dynamic-screens-using-server-driven-ui-in-android-262f1e7875c1 and https://airbnb.design/building-a-visual-language/.

But most other articles I've found so far follow a variant of using JSON to define the views which can then be parsed out when creating the views e.g. https://proandroiddev.com/dynamic-screens-using-server-driven-ui-in-android-262f1e7875c1.

With this approach, I'm not sure we'd need to add a JSON indirection layer since we're targeting Android which already works natively with XML.

Also need to dig in more to see if other approaches are recommended and tested.

[jingtang10]

Definitely take a look at https://developer.android.com/jetpack/compose as well.

[pld]

Cool sounds like these are the options for how we handle UI configuration.

1. code defines configuration -- this is what we're doing now, means we cannot configure what shows in a list and for every resource type we want in a list we need to write new code.

2. pure FHIR defines configuration -- I guess "pure" is still vague, since we could write extensions or new unballoted resources, or unballoted variations on resources, or put configuration JSON (or XML) in a notes field that it was obviously not designed for. This would be configurable and we could use the existing sync architecture to manage moving the configuration around.

3. something other than FHIR defines configuration -- like JSON, XML, etc. We would get sync w/the existing FHIR sync architecture, but maybe we could abuse it for this, or deceive it for this (choose a resource to shove it into. This feels like a good option when we know we want to configure something later and we don't mind having it hard-coded for now, since we build the interface and can change the storage later (eg from XML to loading a FHIR resource after we figured out the appropriate one).

I do not think we need to choose only one option, for something like the login screen (1) is arguable the correct choice. We also don't want it to be difficult to change our mind in the future, if we want to make something configurable that wasn't before, or configurable using a method that it wasn't using before.

CC @rowo @mberg @f-odhiambo the architecture for configuration management is consequential enough to be worth tracking

[vincent-karuri]

Cool, I think a key theme I saw here is the need to modularize UI components that we think are common building blocks across the apps. And define what aspects of them we want to make configurable. Then define a "language/schema" that both the server and client speak/understand.

[pld]

Cool, I think a key theme I saw here is the need to modularize UI components that we think are common building blocks across the apps. And define what aspects of them we want to make configurable. Then define a "language/schema" that both the server and client speak/understand.

Correct, with a bias towards the schema being within FHIR

[jingtang10]

My 2c: we can probably use StructureDefinition to define the fields we're interested in displaying. And use GraphDefinition to define the related resources we're interetsted in displaying.

[pld]

Cool, looks like using those might get us the ability to load any resource into a list view without using the List resource at all, problem with List resource is that it reads like the items it contains are supposed to be predefined.

FYI Vinny's on leave this week

[vincent-karuri]

My 2c: we can probably use StructureDefinition to define the fields we're interested in displaying. And use GraphDefinition to define the related resources we're interetsted in displaying.

Thanks @jingtang10. For the GraphDefinition, I'm not sure I fully understand the use case. Is it for when a list is populated from multiple resources and we need to define what those resources are? In that case would we the query scheme need to understand Graph-like queries? Is that already supported?

[vincent-karuri]

This feature seems to have 2 portions:

1. Support querying of multiple related resources containing information to be displayed on the ListView
2. Support configurable ListView UIs

1 could be something taken up as an SDK deliverable since it seems generic enough.

2 seems to be something we need to figure out on the fhircore side with clear use cases related to how the UI should/can be configured.

Atm, 2 is blocked until we can get more information on the high-level cases to support around configurability.

[pld]

The use cases for 2 are listing patients and tasks. We should review the UI screens and see if there's anything else so far, but building against those 2 use cases sounds good

[vincent-karuri]

Cool, but what aspects of the lists do we want to be configurable? Is it response to touch, some portions of their UI (perhaps the feel), the entirety of their UI. And what actions cause the UI to be updated?

[pld]

We can look at the mock-ups, whatever is different btwn the patient and task lists must be configurable (other stuff not for now)

[pld]

When we get to implementation this most likely lives in the SDK