Introduction to Jetpack compose - devrath/ComposeAlchemy GitHub Wiki

1_m1_mgbHto-Mlo6NqzGc9OQ

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
Relationship between recomposition, declarative paradigm, and dynamic content

Trends in recent times on application development

  • 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, and 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 interactions.

Declarative and Reactive approaches in building the UI

  • Following the trends in 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.

How the Jetpack-Compose fits in Android architecture

  • Jetpack Compose is a new way of designing Android applications using the kotlin language.
  • Earlier we used to have XMLs to design the UI and 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

What Jetpack Compose provides

  • 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.

Key features of J-Compose

  • It is Declarative
    • The 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 findViewById and then setting the visibility using set visibility param.
    • In the declarative approach, You describe the UI on how it looks, and when you want to change the visibility of the 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.

Why should we use the Jetpack compose

  • 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.

Why is it called compose

  • 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 created feature (i:e - child)

Relationship between recomposition, declarative paradigm, and dynamic content

Declarative paradigm shift
  • Imperative approach
    • The existing Android UI uses the imperative approach: Say there is an activity, It has getter and setter methods in it, It calls the UI which here in the case is the XML and the XML updates it.
  • Declarative approach
    • Here in the jetpack compose, It uses more of what we call a declarative approach.
      • Say if you are populating the data, The data arrives from the parent which is the root of the screen -> Then to its child -> so on -> finally to the leaf node of the composable it needs to populate.
      • Similarly, Say you trigger an event at the left node of a hierarchy of a view tree, The click event is propagated up the chain to the parent and so on until it reaches the top composable. Now by reaching the topmost composable the parent can decide how the entire screen needs to be drawn or a part of the UI needs to be drawn.
Dynamic Content
  • Term dynamic content refers to the scenario, Consider a composable hierarchy and you pass input to the parent. It generates a type of UI.
  • Now to the same code, you pass a different input to the composable, it generates a new different type of UI.
  • Meaning to say that the output of composable is dynamic depending on the type of the input.
Recomposition
  • In the imperative approach, We had methods in the activity that were used to notify the UI that the change had to be done
  • In the declarative approach we have Recomposition helps in rebuilding the entire UI and the state to be changed.
    • Drawing the entire UI is not a feasible approach, So the compose internally has some mechanism to decide, which elements to draw and which elements not to draw.
    • Basically recomposition means changing the state of the UI.
⚠️ **GitHub.com Fallback** ⚠️