oppia
[enhancement]: Migrate codebase to jetpack compose
Is your feature request related to a problem? Please describe.
Migrate codebase to jetpack compose. Jetpack Compose is the modern toolkit for building native Android UIs. By adopting Compose, Kiwix can simplify UI development, improve maintainability, and ensure the app aligns with the latest Android development practices.
Describe the solution you'd like
Migration can be carried out in 2 phrases, In the first migration, we can migrate screens, and then use them with views In the second migration, we can remove Fragments and Navigation components
To get a full idea of how the migration will take place please view official docs on Migration strategy
Describe alternatives you've considered
No response
Additional context
Benefits of Jetpack Compose
-
Simplified UI Development: Compose allows developers to write less code, reducing boilerplate and making the UI code more intuitive and easier to maintain.
-
Improved Performance: Compose is designed to be more efficient, which can result in better app performance and responsiveness.
-
Better Integration with Kotlin: Compose is fully Kotlin-based, providing a seamless development experience with Kotlin features like coroutines and flows.
-
Future-Proof: Google is actively developing and promoting Compose as the future of Android development, ensuring long-term support and innovation.
@BenHenning Hey, what do you think about migrating codebase to jetpack compose ? since everyone is adopting it.
Thanks for filing this @itsPronay! This has been on our list for many years, but we never actually filed an issue, so this is a great one to use as the main feature request.
At a high-level, we definitely want to move to Jetpack Compose in the long-term. Besides the benefits you listed, Jetpack Compose has very specific benefits that I think we're interested in:
- It's a more stable replacement for Android databinding.
- It consolidates code to a single language for most of the app (Kotlin).
- It has a much smaller coding footprint over the much-more-verbose XML.
However, there are some cascading challenges that I see with migrating to Compose:
- We've noticed some compatibility issues with newer Compose libraries and the old version of AGP that we use. For reasons a bit too detailed to go into here, migrating to a newer version of AGP is very likely not an option. This means we'll likely need to finish resolving #59 before we can dedicate an effort to moving to Jetpack Compose.
- Since this migration would be touching the entire app UI, we would want to ensure that we can effectively verify the changes. Since it's so visually heavy, we'd very much likely want screenshot testing in place (#1815).
- Screenshot testing itself will likely require some heavier test infrastructure changes to get Espresso consistently working in the Bazel world, including parts of #2047 and probably some more Bazel-specific elements.
To summarize, both the migration and prepping for it will be a large undertaking. :) However, we are interested in doing this. In fact, we're prototyping our first UI using Compose in #5344 but we'll probably not go past that new UI for now without more of the above addressed.
In terms of timeline, I can't really say when we'll be able to start on these efforts as it greatly depends on contributor availability and willingness. At the moment, we're planning on finishing the Bazel migration in completion this year, but there aren't yet plans for screenshot testing or test uniformity fixing.
Just to add, aside from AGP compatibility issues, I ran into Glide compatibility issues as well. Since we heavily rely on Glide for image loading, I checked the Glide Compose Dependency, and it requires Kotlin 1.7.0, and it is not yet stable.
I think at this point we definitely want to continue migrating the codebase to Jetpack Compose, but I don't think we're ready to actually commit to starting a migration quite yet. Beginning a migration without getting the proper arrangements in place is likely going to slow down development and complicate testing in the long run. To try and minimize the impact this migration has on the broader team, I think we should freeze Compose support at its current place (the home screen experience) and work toward preparing for a broader migration before any other code is updated.
To that end, I think the following needs to be done before we can actually begin to migrate the codebase:
- Gradle needs to be removed (#2747 and #59). We're very unlikely to comfortably migrate to Compose with such an old version of Gradle, AGP, and Android Studio.
- A migration plan needs to be drafted, reviewed, and approved that covers all of the following:
- A code guide detailing how to migrate each of the low-level components (e.g. recycler views, text views, layouts, etc.) from XML to Compose.
- A plan breaking down all of the affected screens and files that will need to be migrated, and an order in which they should be migrated.
- A plan for how to safely stage this migration work behind a feature flag so that the changes can be tested.
- A plan for how to manage the complexity of features being implemented in both XML and Compose during the testing phase.
- A plan for launching the new functionality, including identifying a list of metrics to monitor during production to ensure no major user experience degradation occurs when the feature is being enabled for users.
- A plan for cleaning up the old XML code once we've shipped and finalized the work, and removing all databinding artifacts and configurations.
- A list of risks and mitigations, including long-term considerations moving to Compose and any changes that we may need to do for testing.
- Any infrastructural changes needed (such as when interacting with data providers).
- A designated pair (lead and co-lead) of contributors who can start organizing an effort around this migration, including filing detailed issues for each of the constituent pieces and reviewing PRs as they come in.
- All accompanying wiki documentation for writing new features and migrating existing code should be written and checked in.
Unlike most projects, this one is likely to have a schedule around it once we are finished with planning and begin actual coding work. A migration like this can have significant impacts on the day-to-day development experience, and we can't pause bug fixes or feature work while this is happening. Thus, it's especially important to have a clear plan in place, and a planned schedule around completing it so that the project doesn't operate in perpetuity.
While the actual timeline will be highly dependent on the final plan, I expect that the project will take at minimum 1 full calendar year from start to finish for code completion, and 1-2 more quarters to actually test, finalize, and ship the code. Another 1-2 quarters should be considered for unanticipated complexities, and for cleaning up code post-migration.
Hey @BenHenning I'm interested in migrating more code to jetpack compose, be it screen wise or component wise. Do we have any draft/schedule in place so that we can have at least arrangements ready? Is anyone interested to collaborate for the same?
Hi @pratistha-05, as per previous comments, we are still working on getting started on this. Meanwhile, you can get started with some of our starter issues here: https://github.com/oppia/oppia-android/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22.