Introduction to Jetpack compose - devrath/urban-octo-jetpack-compose GitHub Wiki

Banner

`Contents`
`Trends` in recent times on application development
`Declarative` and `Reactive` approaches in building the UI
How the `Jetpack-Compose` fits in android architecture
What `Jetpack Compose` provides
Key features of `J-Compose`
`Why` should we use the Jetpack compose
`Why` is it called `compose`

Recent trends in development involve building declarative and reactive approaches in building the UI
Earlier approaches like MVC, MVP are being replaced by reactive style approaches like MVVM
In approaches like MVVM data is changed in view-model, the UI reacts to it.
This declarative and reactive approach is less error-prone and easier to test since we are working with values of data rather than the interactions.

Following the trends on developing the business logic this approach is now being followed in the development of the presentation layer also
We understand react and flutter have gained popularity with this and Jetpack-compose is google's response to this in native implementation.

Jetpack Compose is a new way of designing android applications using the kotlin language.
Earlier we used to have XML's to design the UI and the kotlin to write the business logic
With the introduction of J-Compose, all the parts of the application are written in the kotlin language
Android is moving towards a pure kotlin framework. We gave kotlin-DSL instead of groovy in using Gradle dependencies, now jetpack compose as * an alternative to building the UI of the application instead of XML

It simplifies the UI development.
It decreases the time involved in the process of building the UI so you can build applications faster.
It helps in minimizing the code we need to write in building the UI.
J-Compose is built to be interoperable with the existing UI.
It is developed with other jetpack library elements kept in mind.
Implementing the material theming is easier using the J-Compose.
Building the lists and using animation is easier using J-Compose.

It is Declarative
- Traditional way of handling the view does not involve mutation and relies on imperative programming concepts.
- If you consider hiding the view, it involves finding the view using the findViewByIdand then setting the visibility using setVisibility param.
- In the declarative approach, You describe the UI on how it looks, and when you want to change the visibility of UI, You redraw the UI describing how the UI looks.
- So you can observe that you are not grabbing the reference of the created view instead, you are calling the method that created the view just with different parameters.
- In the J-Compose the entire view is not recreated but a part of it is redrawn.
It is Independent
- Compose library is not coupled to the operating system which is an advantage for the developers.
- Say if google wants to update the constraint layout with something new, it has to release a new version of the operating system
- Instead just the compose library is updated and some people may not update which is fine in turn it won't break the existing implementations.
It is Composable
- Because of this we don't need to build the view on activity and fragment level and instead as small chunks so it can be reused.

There will be just one language for all the project, which we call kotlin.
- Earlier till now we used to use a composition of languages namely Java + XML + Groovy.
- Then we transitioned by introducing the kotlin so it became kotlin + XML + Groovy.
- Further groovy got substituted as kotlin + XML + kotlin-dsl.
- Final part to remove is to substitute xml with kotlin.
Jetpack compose proposes a declarative approach
- Till now we used to have an imperative approach -> Meaning, A XML is tied to the activity, The activity tells the XML what to do and XML does it.
- In compose, We don't have the imperative approach anymore. We have the activity and the compose functions
- Compose functions are contained within the activity
- Each activity has a state
- Whenever the state changes, the part of the complete compose functions are rebuilt.
- This is a better way of representing the xml. We know we have an input and the compose function reacts to it providing the output
- compose function just knows how to build the UI based on the input, This is a declarative way of representing is very popular languages like flutter and react.

It's called compose because it's based on the composition pattern.
Old android UI mechanism is based on inheritance
- Being based on Interface meaning parent and child is is-a relationship.
- Whatever the properties that a parent has will be inherited by the child and the child will have additional properties.
The jetpack-compose on the other hand will be based on composition
- Parent and child composed of is-a relationship.
- There is a parent composable and it is nested with n-number of child composables.
- Meaning to say that jetpack-compose is based on composition.
- Now when you want to add new functionality, you just nest with one more composable.
- Parent composable holds a reference to children composable, In such way it can take the logic of children composables
- When you need to add a new feature, you just create a composable and add it to the existing parent composable and get the reference of the added child composable and thus you have reference to the logic of the newly cread feature (i:e - child)