[Part 1] Jetpack Compose — Introduction
There are 4 parts in this article series for migration process to compose.
Part 1: Jetpack Compose — Introduction
Part 2: Jetpack Compose — Preparing to Migrate Existing Layout to Compose
Part 3 : Jetpack Compose — Migration of Component View (Input Text) on Existing Layout
Part 4 : Jetpack Compose — Implementing a Compose View in a ViewGroup
Since android the first time introduced in 2013 till now, the only one UI development method on android application is XML format. Even though in 2018 Anko layout was popular in android developer community, however it hasn’t been able to revolutionize the long-familiar method of developing layouts. But when Google introduced Jetpack Compose, many developers try explore it, and this year Jetpack Compose reached the stable version. This is easily implemented because Jetpack Compose has the ability to coexist with XML (interoperability). There are several things that can be used as consideration to start implementing Jetpack Compose in building a UI for android applications.
Less code, developing an application layout with Jetpack Compose no longer requires UI components that are built in xml files and called on the activity class by initializing the component id using the View class. As we know the previous way to build a layout is depend on the View class, so that developers often call it “God of Class”. For any need for UI components, they all involve the View class.
Intuitive, when discussing Jetpack Compose it is closely related to the Declarative concept, different from the old method (xml) which still uses imperative concepts. To ease the idea of the difference between imperative and declarative concepts. Just imagine that we are ordering fried rice at a restaurant, so what we will tell the waiter there are two options imperatif and declarative.
Imperative : I order white rice that is already cooked, then put it in the pan mixed with sweet soy sauce, soy sauce, vegetables, salt, eggs stirred until cooked and served on a plate. Meanwhile, if using the approach
Declarative then: I ordered non-spicy fried rice.
The difference between using the imperative concept, is that all instructions are mentioned in detail until a goal is reached, that’s a fried rice. Meanwhile, when using the declarative concept, the details of the instructions don’tt need to be mentioned, just focus on the desired goal, that’s fried rice. Orders to produce fried rice are executed without waiting for orders from the customer, so the process is faster. This also applies to Layouts that are built with a declarative concept, of course, will have a relatively faster build time, and developers don’t need to specify the components needed in detail.
Accelerates Development, if you have an existing app that already has legacy code using xml to migrate to compose is not something difficult to do. Compose has interoperability with Views. So that compose can be used together in one project. It could even be in one page consisting of xml and compose. There are two ways to migrate layout from xml to jetpack compose.
The previous fragment class still initializes a xml component via the view class with viewBinding as shown below.
Whereas after migrating by utilizing ComposeView as follows.
It can be seen that the onCreateView function previously returned to FragmentBinding currently returns to ComposeView. So that you can customize content on composeView which will later be executed as part of compose.
Furthermore, when the migration has been carried out, one of the views that you want to be used as a compose widget can be replaced with ComposeView, and you can customize the widget class according to your wishes. And this is not limited to a component because this widget is developed in a function so that it can freely customize.
Apart from that, Android Studio has fully supported Jetpack Compose with various features provided.
- Interactive Mode, this feature allows developers to display previews to make them interactive. That way, you can see how the effect is if a button is pressed, what animations appear, as well as state changes that occur. Of course this is very helpful if developers develop Android applications using low specification devices, so developers don’t need to make emulators or bother debugging with devices.
- Live Edit, this feature allows developers to update data in real-time for constant values that appear in previews and devices. Supported types are Int, String, Color, Dp, and Boolean. Apart from that, the preview feature can do multiple previews to create two preview variants, light mode and dark mode.
- Animation Preview, in this feature, if there is an animation created with a composable function, the developer can use the animation preview to check each value when the animation changes. Developers can run, stop, speed up, and slow down animations using this feature at certain keyframes.
- Preview Parameters, this feature makes it possible to create multiple inputs to find designs with different character lengths with parameter previews. All you need to prepare is to create a data class and use the PreviewParameterProvider to create a preview of the mocking data for the parameters you want to display.
Powerful, when using jetpack compose we can have direct access to the Android Platform API, which has built-in animation, dark theme, material design. Besides that, the system also works on functions, this makes us have the freedom to customize the components we use. Then don’t worry if friends use other Jetpack libraries such as paging, navigation, etc. These can be integrated properly.
Lastly, all the features of jetpack compose will not be executed if you don’t use @Composable. This is an annotation that has the ability to declare a function, lambda to data type. The use of annotations here is more like keywords. A similar analogy is the suspend keyword. So @ here is not an annotation processor. Because compose runs on kotlin plugin.
Various information regarding the jetpack compose that I know I have shared. See you in the next article. :)
