cooltey opened https://github.com/wikimedia/apps-android-wikipedia/pull/4617

The Spike is completed, and here are my findings:

1. Requires a lot of Compose libraries which will increase the app size.
2. Somehow cannot use the latest version of BOM, which will cause a checkstyle failure when running the build.
3. Compatibility is acceptable, however, when combining an XML view with an alternative ComposeView, it will increase the difficulty of readability.
   • In this example, I replaced the "Send feedback" button in the About screen, with a ComposeView view in XML, and introduced a @Composable function with some custom styles for the button and the text, which meant it requires more code to achieve the same effect as we have in the XML.
   • The current styles in styles.xml will not be used in Compose and we will need to spend a lot of time on re-defining the style in @Composable functions.
4. Creating a screen with Compose only will be much easier and cleaner.
   • In this example, I converted the LicenseActivity with only @Composable functions in the class, and removed the activity_license.xml from the app.
   • The @Preview annotation allows us to view the design, like what we currently do in the XML, but somehow it also requires a new "Preview" function to see the preview.
   • @Preview is slow and requires to rebuild. Sometimes it fails with no specific error logs.
   • For showing HTML content, the built-in Text component does not support the HTML content. We can use AndroidView and bring the non-Compose view class to Compose.
   • Applying styles is the same as the one in 3.
5. More advanced views/actions, such as RecyclerView or DialogFragment with ViewModel, will require more research time, since our current knowledge on using the non-Compose view cannot be carried over to the Compose.
6. Compare Compose and View metrics shows that if we combine Compose with View, the overall building time and app size will increase.