Goal
Provide a truly native Android chat experience (Jetpack Compose/native Views) as an alternative rendering backend for @chativa/rn-webview, for apps where the WebView-based widget doesn't meet the UX bar.
Background
@chativa/rn-webview (#6) currently ships a react-native-webview-based implementation: it embeds the existing web widget (@chativa/ui + @chativa/genui, loaded via the packages' existing CDN/global builds) inside a WebView and bridges events/config over postMessage. This reuses the web UI as-is and required no native re-implementation. Android's WebView is generally more consistent than iOS's, but the same class of issues (keyboard resize/adjustResize quirks, scroll/momentum feel, animation smoothness, back-button handling) can still fall short of a truly native screen, especially on lower-end devices.
This issue tracks the conditional fallback: only pursue this if the WebView approach proves insufficient in a real app.
Scope (to be refined when/if this is picked up)
Acceptance
- Not scheduled — this issue exists to hold the decision and scope once/if the WebView approach is found insufficient. No acceptance criteria until scoped.
Out of scope (for now)
Goal
Provide a truly native Android chat experience (Jetpack Compose/native Views) as an alternative rendering backend for
@chativa/rn-webview, for apps where the WebView-based widget doesn't meet the UX bar.Background
@chativa/rn-webview(#6) currently ships areact-native-webview-based implementation: it embeds the existing web widget (@chativa/ui+@chativa/genui, loaded via the packages' existing CDN/global builds) inside a WebView and bridges events/config overpostMessage. This reuses the web UI as-is and required no native re-implementation. Android's WebView is generally more consistent than iOS's, but the same class of issues (keyboard resize/adjustResizequirks, scroll/momentum feel, animation smoothness, back-button handling) can still fall short of a truly native screen, especially on lower-end devices.This issue tracks the conditional fallback: only pursue this if the WebView approach proves insufficient in a real app.
Scope (to be refined when/if this is picked up)
adjustResize/adjustPan), scroll performance, animation smoothness, accessibility (TalkBack), back-button/predictive-back handling — and document concrete shortfalls before scoping native work.@chativa/rn-webview, vs. a fully separate native Android SDK usable outside RN entirely.@chativa/core's wire protocol / connector behavior conceptually (sameChativaSettingsshape, same message/event model) even though the UI layer would be genuinely native Kotlin, not shared JS.Acceptance
Out of scope (for now)