"They killed an innocent," says a song. That's what is happening to XML in Android, Google and the community are slowly killing XML.
Since the announcement of Android Compose back in 2021 at the Google IO developers conference, developers have been testing and working with this new Declarative pattern for Android, and slowly Compose has been winning space in the Android community.
Big steps for a baby
As with all, new things generate a lot of uncertainty, and usually, when you are adopting a new tech you have to be very careful with it, at the beginning we don't use to count on enough documentation or a community that supports it, so we strongly suggest considering this points before adopting new tech in general:
Learning curve: We should evaluate the learning curve of the new technology and determine if it is feasible to allocate enough time and resources to learn and become proficient in it.
Technical requirements: Analyze the technical requirements and determine if it is compatible with the existing infrastructure and software, and the company vision.
Availability of resources: Assess the availability of resources, such as documentation, tutorials, and support forums, to aid in the learning and development process.
Company goals: Determine if the new technology aligns with the company goals and if it can help achieve them more efficiently or effectively than the current technology.
Cost: Consider the cost of adopting the new technology, including licensing, training, and impact on productivity during the transition.
Risks and challenges: Identify risks and challenges associated with the new technology, such as security, adaptability, compatibility issues, or a lack of community support and updates.
User experience: Consider how the new technology will impact the user experience and whether it will improve or hinder it.
The transition
But the idea of doing the transition to Compose was always over the table, so we started to learn it, testing, documenting, fighting poor online documentation and tutorials compared with more mature Techs, fighting with bugs and undocumented issues (🥲), new design approaches, and studying new architectures.
So trust me when I say this transition can take a while, when you have a big team, aligning all the team members in the same direction is a big challenge, so my advice is don't try to jump into a bottomless pool and start a project with a new tech, or the consequence could be catastrophic.
Right now we can say that Compose is mature enough to start taking it seriously and start the transition to it, so here it's the big question:
Is XML so bad that we need to move to Compose?
No really, in general, over other advantages, XML offers a structured, efficient, and maintainable way to define UI elements, promoting a good development workflow and a consistent user experience. But Compose provide several advantages over XML:
- Declarative UI: is cleaner, more readable, and more performant than Imperative UI.
- XML depends too much on the application's lifecycle.
- Compose allows you to do more with less code compared to XML, redefining all the views and simplifying their use, no more recycler views yea!!!.
- Compose is more intuitive: as declarative UI you just need to tell the UI what to show changing the data state and not setting up the UI like in XML.
- Memory: all the compositions are painted "on demand" so the user just sees what needs to see and doesn't have hidden views or unused views in the background, improving the app performance.
- Design: the design system is more robust and intuitive.
- Data flow and State management: offer a unidirectional data flow, where data flows in one direction from the source of truth (usually a ViewModel or some other state container) to the UI components. This makes it easier to understand and reason about data changes, as well as debug issues related to UI behavior. on the other hand, it aligns with modern software development principles, making Compose more maintainable, testable, and robust.
Why now?
Compose is in a stage where we can use it to create complex solutions, saving time and effort for the team. The Android Development community is adopting compose very fast, and XML will be obsolete in the future, the same thing that happens with Java for Android when we move to Kotlin.
On the other hand with Compose, you can create UI components more intuitively and concisely, using Kotlin code instead of XML. This makes it easier to understand and modify your UI code and reduces the amount of boilerplate code you need to write, improving the readability and the maintenance cost. It also provides a faster way to develop your app's user interface. You can use Compose to quickly prototype your UI design and see the results in real-time, without having to compile and run your app. This can save you a lot of time and effort, especially during the early stages of UI development.
And finally Compose provides a more flexible and customizable way to create UI components. You can easily create custom UI components and modify existing ones to fit your needs. With Compose, you can also easily reuse UI components across different parts of your app, saving you time and effort in the long run. Compose is designed to perform better than XML-based UI development. Uses a more efficient rendering engine that can reduce the amount of CPU and memory usage, resulting in a smoother and more responsive user interface.
Conclusion
The transition to a new tech could be a challenge depending on the context. As individuals, you may take a risk, but as a team, we have to consider a lot of things.
As a team, this is the moment to start developing products with Compose, very soon we will bring you a base project with an initial setup for an Android project with Compose including Theming, Navigation, Testing, DI, and more. We encourage you to start learning Compose to be more productive and bring to the end user a better experience.
Keep calm and code clean. 😜
