Bootstrapping Simple Server Driven UI from a Design System

Talk given at Droidcon New York on September 15th, 2023, about how to leverage a design system to build server driven UI.

Transcript

1. Bootstrapping Simple Server Driven UI from a Design System Abdulahi Osoble Ahmed El-Helw
2. Problems • Iteration speed is critical for business success • Mobile releases take time for adoption • Consistency on iOS and Android
3. Today Mobile fetch data from APIs and bind them to UIs on the client side.
4. What If Our features come from an endpoint?
5. Server Driven UI Mobile fetches UI representation from APIs
7. Building SDUI
8. Building from Scratch • Need some UI components • Need a serializable data representation
9. { "type": "label", "text": "Hello, World!" }
10. data class LabelData(val text: String) @Composable fun Label(data: LabelData) { Text(data.text) }
11. data class LabelData(val text: String) @Composable fun Label(data: LabelData) { Text(data.text) }
12. Let's add Max Lines
13. { "type": "label", "text": "Hello, World! This is not very long ... ", "maxLines": 2 }
14. data class LabelData(val text: String, val maxLines: Int) @Composable fun Label(data: LabelData) { Text(text = data.text, maxLines = data.maxLines) }
15. Let's Add Typography?
16. This is a lot of Work • We’d have to expose: • Text size • Colors • Typefaces • Font weights • This also starts to tie us to the underlying platform
17. Can we make the problem smaller?
18. Design System Already Solves this for Us
19. Design System • Opinionated • Limits the landscape of what is possible • Lets us use larger building blocks • Allows us to save time
20. Android • Views • Compose iOS • UIKit • SwiftUI
21. Design System • Components • Foundations (types and tokens)
22. Components • May not be easy to serialize / deserialize directly • Need a data representation
23. Types and Tokens • Styles, Color Tokens, etc • Easy to serialize / deserialize
24. Demo
25. Server Driven UI • Same payload should render on iOS and Android
26. Build a Serialization Layer
27. Step 1 - Decide data representation of our widgets Step 2 - Render that data representation
28. data class LabelData(val text: String, val maxLines: Int) @Composable fun Label(data: LabelData) { Text(text = data.text, maxLines = data.maxLines) }
30. interface Component data class LabelData( val text: String, val maxLines: Int ): Component
31. interface Component data class LabelData( val text: String, val maxLines: Int ): Component
32. How do we Render? @Composable fun render(component: Component) { when (component) { is LabelData - > Label(component) is ButtonData -> Button(component) // .. . } }
33. How do we Render? @Composable fun render(component: Component) { when (component) { is LabelData -> Label(component) is ButtonData -> Button(component) // ... } }
34. Can we Simplify? interface Component { @Composable fun Content(modifier: Modifier) }
35. class LabelData( private val text: String, private val maxLines: Int ) : Component { @Composable override fun Content(modifier: Modifier) { Label(text = text, maxLines = maxLines) } }
36. class LabelData( private val text: String, private val maxLines: Int ) : Component { @Composable override fun Content(modifier: Modifier) { Label(text = text, maxLines = maxLines) } }
37. @Composable fun Sample(component: Component, modifier: Modifier) { component.Content(modifier) }
38. Tradeoffs
39. Share with iOS or Not?
40. iOS 16 class WidgetData: ObservableObject { @Published var count = 0 } struct Widget: View { @ObservedObject var data: WidgetData var body: some View { /* ... */ } }
41. iOS 17 - Observation Framework @Observable class WidgetData { var count = 0 } struct Widget: View { var data: WidgetData var body: some View { /* ... */ } }
42. Other Options • Share models with KMP with a Swift wrapper • codegen Kotlin and Swift models
43. import SwiftUI struct {{ widget.name }} { {% for key, value in widget.fields %} let {{ key }} : {{ value }} {% endfor %} }
44. data class {{ widget.name }} ( {% for key, value in widget.fields %} val {{ key }} : {{ value }} , {% endfor %} )
45. Other Options • Share models with KMP with a Swift wrapper • codegen Kotlin and Swift models • Expect/action chicanery
46. expect interface Renderer
47. actual interface Renderer { @Composable fun Content(modifier: Modifier) }
48. actual interface Renderer
49. interface Component { fun renderer(): Renderer }
50. Public API
51. interface Component { @Composable fun Content(modifier: Modifier) }
52. data class ServerDrivenUiResponse( val root: Component )
53. @Composable fun ServerDrivenUi( response: ServerDrivenUiResponse, modifier: Modifier ) { response.root.Content(modifier) }
54. { "root": { "type": "list", "contents": [ ] } } Example of List
55. class ListComponent( private val contents: List<Component> ) : Component { @Composable override fun Content(modifier: Modifier) { LazyColumn(modifier = modifier) { contents.forEach { item { it.Content(modifier) } } } } }
56. class ListComponent( private val contents: List<Component> ) : Component { @Composable override fun Content(modifier: Modifier) { LazyColumn(modifier = modifier) { contents.forEach { item { it.Content(modifier) } } } } }
57. How Do We Use This?
58. @Composable public fun Sample( response: ServerDrivenUiResponse, modifier: Modifier = Modifier ) { SampleTheme { Surface(modifier = modifier) { ServerDrivenUi( response, Modifier.padding(all = 8.dp) ) } } }
59. What about events?
60. Actions
61. • Based on user interaction • Broken down in sections • Must have common super-type
62. interface Action sealed class OnClick: Action { class Deeplink(val link: String): OnClick() }
63. interface Action sealed class OnClick: Action { class Deeplink(val link: String): OnClick() }
64. { "actions": [ { "type": "onClick_deeplink", "link": “careem: // link“ } ] }
65. { "actions": [ { "type": "onClick_deeplink", "link": “careem: // link“ } ] }
66. How do we handle Actions?
67. // Public API interface ActionHandler { suspend fun onClick(action: OnClick) {} } val LocalServerDrivenUiActionHandler = staticCompositionLocalOf<ActionHandler> { error("nothing provided") }
68. class LabelData( private val text: String, private val maxLines: Int, private val actions: List<Action> = emptyList() ) : Component { @Composable override fun Content(modifier: Modifier) { Label( text = text, maxLines = maxLines, modifier = modifier.handleAction(actions) ) }
69. // Internal API internal fun Modifier.handleActions(actions: List<Action>): Modifier = composed { val handler = LocalServerDrivenUiActionHandler.current val scope = rememberCoroutineScope() var localModifier = this actions.forEach { action -> localModifier = when (action) { is OnClick -> localModifier.clickable { scope.launch { handler.onClick(action) } } }
70. // Internal API internal fun Modifier.handleActions(actions: List<Action>): Modifier = composed { val handler = LocalServerDrivenUiActionHandler.current val scope = rememberCoroutineScope() var localModifier = this actions.forEach { action -> localModifier = when (action) { is OnClick -> localModifier.clickable { scope.launch { handler.onClick(action) } } }
71. // Internal API internal fun Modifier.handleActions(actions: List<Action>): Modifier = composed { val handler = LocalServerDrivenUiActionHandler.current val scope = rememberCoroutineScope() var localModifier = this actions.forEach { action -> localModifier = when (action) { is OnClick -> localModifier.clickable { scope.launch { handler.onClick(action) } } }
72. // Public API val actionHandler = object : ActionHandler { override suspend fun onClick(action: OnClick) { when (action) { is OnClick.Deeplink -> { // .... } } } }
73. // Public API val actionHandler = object : ActionHandler { override suspend fun onClick(action: OnClick) { when (action) { is OnClick.Deeplink -> { // .... } } } }
74. // Public API CompositionLocalProvider( LocalServerDrivenUiActionHandler provides actionHandler ) { . .. }
75. Recap • Design system simplifies our scope and empowers SDUI • Actions are powerful and optional on all components • Components are serialized from payload and self render
76. How about custom components?
78. Extensibility
79. Open Deserialization
80. private val componentModule = SerializersModule { polymorphic(Component :: class) { subclass(ListComponent :: class) subclass(ListItemComponent :: class) subclass(LabelComponent :: class) // ... } } private val json = Json { serializersModule = componentModule }
81. Open Deserialization • Pros: • Easy to add new components • Use SDUI without depending on design system
82. Open Deserialization • Cons: • Easy to bypass design system • Duplication of widgets over time • Lose the ability to change without releasing a new version of the App
83. Open up Primitives
84. Open up Primitives • Rows • Columns • Modifiers
85. { "type": "row", "contents": [ { "type": "column", "contents": [], "modifiers": [] }, { "type": "progressStatus", "amount": 3, "total": 10 } ], "modifiers": []
86. { "type": "row", "contents": [ { "type": "column", "contents": [], "modifiers": [] }, { "type": "progressStatus", "amount": 3, "total": 10 } ], "modifiers": []
87. { "type": "row", "contents": [ { "type": "column", "contents": [], "modifiers": [] }, { "type": "progressStatus", "amount": 3, "total": 10 } ], "modifiers": []
88. Open up Primitives • Pros: • Can only build on top of existing components • Can share these on the backend • Can update these without a new app update
89. Open up Primitives • Cons: • More difficult to add components • May need to add more low level components
90. Demo
91. Tooling
92. Other Ideas • Web is useful for previewing SDUI from a CMS • Drag and drop tool or other generator • ChatGPT
93. To help shipping speeds really fly, We started using server driven ui, building it against our system of design, colors, fonts, and the width of each line. We agreed on data representations, approved by Android and iOS nations. We followed it with a component interface, allowing us to deserialize a polymorphic base. We realized we'd have to glean, info on the type to draw on the screen. We need to be sure iOS and Android are in sync, as time goes on, we continue to think, do we generate code from a common source, or misuse expect actual with a bit of remorse, or do we just share models in KMP, this is yet another point in our decision tree. In order to support actions like click, without code that makes us sick, we have each action containing its data, handled by a composition local sometime later. How do we allow people to add new components? Multiple solutions, each with their proponents. Allow folks to define a component type, or implement row, column, and the low level hype. Since our design system is written in Compose, run it on multiple platforms we do propose, web and desktop make a lot of sense, open up nice doors while costing a mere pence. We hope you'll check out our GitHub repo, and make server driven ui your Home Depot.
94. github.com/ahmedre/sdui