JetPack Compose Impressions

With Google moving in the direction of doing views declaratively in code instead of XML for Android development there is a lot of interest in a library they are developing. Enter in JetPack Compose which allows views in a Android app to be developed in Kotlin code instead of XML. Although the ideas in behind the library are good the implementation isn’t (leaves a lot to be desired).

Ideas

Where Google get a lot of things right is with ideas. With many software developers moving towards declaratively building/managing views in code, and dropping markup Google’s timing couldn’t be better. Android developers have long suffered with being forced to use XML for doing views, which doesn’t fit in well with tooling, is difficult to read, inflexible with loose coupling, performs badly, and heads down the Implicit Development (developing software the ”magical” way) route that makes troubleshooting difficult (also hurts readability).

Mandating the use of Kotlin to build/manage views is the right path forward for Android development. Most languages (eg Java) don’t provide the necessary features to develop ”real” DSLs.

Implementation

Google are claiming that JetPack Compose is Kotlinic however it isn’t, particularly when it comes to the APIs not being ”real” DSLs. Also the use of constructors doesn’t make a API declarative since one has to manually specify ”how” to create a thing (object). Proper Kotlin DSLs use functions to compose things (includes doing things declaratively), and have classes/objects manage state/behaviour. This brings through the best of both programming paradigms (Functional and OOP) in a way that is balanced.

Since JetPack Compose isn’t declarative it does things in a imperative manner mainly through OOP, which is lop sided (not balanced). At this stage some major changes are required to make the library Kotlinic.

Explicit Development

Using annotations (eg Composable) is a odd choice which is at odds with Explicit Development. Is it really necessary to use annotations to enable code to be live previewed? On the Kotlin side there is a much better way to do live previews which are annotation free. A great inspiration for the Android team to look at is TornadoFX which does live preview through a IDE plugin.

Note how TornadoFX is able to achieve live previews that don’t involve a lot of magic/meta programming. Kotliners are very used to doing software development explicitly, and become agitated/annoyed if they are forced to do a lot of Implicit Development (JPA comes to mind).

Expectations

Kotliners who are involved in Android development expect the following from the JetPack Compose library:

1. Can build/manage views explicitly through Explicit Development using Kotlin code instead of XML
2. The library is Kotlinic and does things that are closely aligned with Kotlin culture
3. Existing Android views and widgets (controls) are compatible with the library
4. Quicker build times compared to XML
5. Significantly less CPU/memory used compared to XML
6. Can easily extend DSLs through extension functions
7. Visual previews of views which are automatically updated when the view code changes

Luckily JetPack Compose is in the early stages where significant changes can still be made. Below is a example of what the APIs should look like:

JetPack Compose API Example 1 ($1858367) · Snippets

Note how no constructors are used (apart from the hypothetical ComposableActivity class) and each ”what” is done per line. Also note how loose coupling is used to keep nesting to a minimum, which is especially important when dealing with large views. Much of this example is explicit so you have a much clear idea of what is going on in the code (more readable, has clear context), and it is easier to troubleshoot.

Below is the same example done in a compact form (increases tight coupling):

JetPack Compose API Example 2 ($1858369) · Snippets

Finally here is a more comprehensive example that uses multiple widgets:

Sign in

Conclusion

Google have much work to do to ensure JetPack Compose is up to the task of providing proper DSLs to build/manage views, which are Kotlinic and deeply follow Kotlin culture (in particular the point on doing explicit development as much as possible).