Structuring modules, features and widgets into the Single APK Approach

[f-odhiambo]

In an effort to move towards a single APK approach we made/still are making incremental changes to our FHIR Core codebase

• Single code base for all our apps
• Refactor/Reuse any generic code

The New structure currently is outlined below

/anc - anything ANC specific will build CHW app for LMH and mADX
/eir - anything EIR specific will build Covax app
/quest _- anything quest specific now having the G6PD POC
/engine
|--- /register
|--- /report
|--- /task
|--- /search

In a bid to be able to cut a an APK release for a given usecase/ client deliverable or health vertical we have the following options:

1. Build configs done at compiled time
2. Server side synced configs compiled at runtime
3. Jetpack compose for customized custom views
4. Add support for configurable views

A couple of open questions/thoughts here

1. Where will form widgets live ? i.e BMI Widget , Location mapping widget, Custom P2P sync logic
2. In the case for mADX, where will BMI widget, Collection to Observations collection views, Viewing patient profile with observations reside? How do we 'turn it on/off' from ANC module ? how do we add a config that only supports reproduces this workflow?
3. In the case for Quest/G6PD how do we sync only g6ps resources and custom logic to show/ hide labels/ forms ? (Partly answered worked on )
4. How do we configure part of the apps such as Login, Patient List, Registers, and Patient profiles ?
5. How do we create build config and where do we store them on app?
6. How do we create sync config and how do we initiate them on app ? How do we edit them on server side ? Roll out an update to app ?
7. How do we go about the limitation of a Binary resource i.e. Issue with binary resource is not searchable and can bot be tagged as well so we had to define/hard-code ids of config to be loaded, we need to check with back-end team to find a proper way to load relevant configs, and without authentication ?

[pld]

On the list of options, I think (3) and (4) are implementation strategies for either (1) or (2).

Another thought here, and I'd say arguable the ideal of the single APK approach, if we can create the ANC and EIR app functionality, by loading configs into the Quest app, we can remove the ANC and EIR.

To do the above, the more everything exists as a widget or module, that we configure the loading of, the better, since then we can use server-side configs to control that loading on a dynamic basis.

With that as context, my thought on the open questions are

1. These do not belong in an app. Maybe they all belong somewhere under engine, maybe we need a widget folder under engine these are in?
2. With the above, I think the ideal would be in engine/widget (or similar) but not in ANC so that if we want to write a config that loads the BMI widget into Quest we can. Having a build config loading it into ANC for now seems reasonable, but longer term we'd want to remove ANC and have this loaded into the Single APK version based whether a config specifies it.
3. I think Defining configurable apps when and when not linked to users #594 addresses most of this. We could use a Register widget, that a dynamic config defines to be for whatever list of resources

(4) through (6) are explciitly handled by #594

7. I think we can manage this by having another resource, which does support useContext and connections to another arbitrary resource handle the app definition. For example a Library resource can point to the binary data in an Attachment resource, but we should look at other options first. We want to exhaust more structured alternatives to a Binary resource and Binary content before we use it.