workflow-kotlin
workflow-kotlin copied to clipboard
Tutorial uses LayoutRunner instead of ScreenViewFactory
It seems that ScreenViewFactory is preferred over LayoutRunner these days. It would also be nice if the tutorial mentioned AndroidScreen as an alternative. This would align the tutorials with info here https://square.github.io/workflow/userguide/ui-in-code/#building-views-from-screens.
The tutorials are indeed out of date, but ScreenViewFactory and LayoutRunner aren't analogs.
Before Screen and Overlay were introduced:
- A
ViewFactorywould create aViewto be driven by aLayoutRunnerfunction to show renderings of a particular type. - These
ViewFactorybindings had to be gathered at runtime inViewRegistrycollections. AndroidViewRenderingwas introduced to allow a rendering to provide itsViewFactorydirectly, avoiding theViewRegistryboilerplate and runtime errors.
This year, the Screen and Overlay marker types were created, along with replacements for most of the above. This was done mainly to simplify Android Dialog management. Today:
- A
ScreenViewFactorycreates aViewto be driven by aScreenViewRunnerfunction to show a particular type ofScreen. - An
OverlayDialogFactorycreates aDialogto show a particular type ofOverlay. There is noDialoganalog toScreenViewRunner. AndroidScreenreplacesAndroidViewRendering, and an analagousAndroidOverlayhas been introduced.
Both before and after, ViewRegistry is still available to allow runtime bindings between rendering types and the view system where needed. These runtime bindings can also be used to override those implemented via AndroidScreen and the like.
There are still shortcomings with the updated Workflow UI -- redundancy and assymetry between View and Dialog support, and some inefficieny in Compose support (#546). In 2023, I'm hoping to roll out VisualFactory as a simpler, more flexible replacement for most of the above (#874).
tl;dr: we should indeed update the tutorials to use non-deprecated interfaces, and also to encourage the use of AndroidScreen.