Must-Have Things to Start New Android Project (Part 2) UI Instruments

In Part 1, I wrote about choosing a language and network library for your new Android Project. The next topic I want to write about is UI. UI is essential for every Android Application. Excellent looking App could engage more users. The good thing about Android Development is that now we have more options to build UI and interact with views as before. So let me share with you some of those options.

XML

Create Android UI using XML layout files is a default approach used from the beginning of Android Development history. XML was chosen not only for Android UI creation. It is also used for most Android resources. The reason to select XML was that it’s a readable mark-up language, which also can be easily parsed. But how it works?

First of all, we are creating a layout file in the layout directory. Usually, it looks something like this:

And then Android System parses or “inflates” this XML. This process creates all view and viewgroup in memory using defined attributes in the layout XML file. After inflation, you basically can initialize your views in Java/Kotlin code. Initialization is a significant thing. When views are initialized, you can change them, listen to events, and ask for user input.

For views initialization, there are some options to choose from. Depending on the language you use, views can be initialized like this:

This is an old-fashioned way to initialize views. Now to replace the findViewById function, Google introduced the ViewBinding instrument.

ViewBinding works straightforward. Your layout XML file generates a new binding class containing all views you have in the layout file.

I’ve coded this using Java because for Kotlin, it looks almost the same

Please note that now there is one more way to initialize views in Kotlin — kotlin extensions. But it will be deprecated soon. Please don’t use it. Also, Google can not recommend this approach because of the following reasons:

• It can be used only in Kotlin.
• Exposing of the global namespace of ids that are unrelated to the layout that’s inflated with no checks against invalid lookups
• They are not exposing to nullability when views are only present in some configuration.

All these reasons could lead to API issues and crashes.

To summarise, building XML layouts is still a proper way to create user interface for your Android Application. Android Studio developers are always improving XML editor, which is good. Graphical interface builder also becomes better, but in general, I still prefer to write code instead of using it.

Adding views in Runtime

The alternative of XML could be adding your Views exactly in Java/Kotlin code. Here is an example of how the code could look like

Important to mention that for setting some of the view arguments, you need to use LayoutParams class.

From my perspective, this approach doesn’t look suitable for the following reasons:

• Code readability: it’s challenging to understand view hierarchy, especially for complex layouts
• No preview: To see changes, you need to rebuild the project.
• It’s challenging to work with some view arguments: Sometimes, I had an issue that it’s not possible to set some arguments programmatically

One advantage that you can find is that maybe there will be some performance boost because you don’t need to parse the XML file. Some Google developers already said that this is not an issue, so their main suggestion is to use XML and inflate your layouts.

Jetpack Compose

In the year 2017, Google announced Jetpack — a collection of various libraries which could help Android developers to write better code. Currently, there are around 80 different libraries as part of Jetpack. In the context of this article, the most exciting library is Compose. Now, this library is in development preview. So what is Jetpack Compose?

The main idea of Jetpack Compose is to give an option to build a declarative UI. This concept comes from React Native and Flutter and means actually that you develop your views without depending on view changes. And to change the state of the view, you need to re-run the UI code. It brings more architectural options for developers.

Important to know that Jetpack Compose is an entirely new UI toolkit written from scratch. It means that we don’t bring all legacy code from old android View and its children.

So it sounds incredible, and from the first point of view, this could be an obvious choice. But as mentioned before, this library is currently in development preview. This means that to build UI with Jetpack Compose, you need to install Android Studio from the Canary channel. To be fair, I need to say that the setup and all existing tools are already looking lovely.

The pain point could be that there not a lot of information and official guides about Jetpack Compose. On developer.android.com, you can only find basic descriptions with a simple example. This is easy to explain — the library is still in the active development stage. Also, there are many non-official articles/examples, but some of them are already outdated.

Just to give some information about Jetpack Compose, I’ve built a simple UI

UI initialization looks almost the same as for XML, except that we use a new function setContent to initialize it. This functions composes give Composable which is passed through lambda function.

Here Content is our composable View:

Every element, such as Column, TexField, or Button, are specific Composable functions(even if it’s written upper-case). As you can see, our Content() is also a Composable function. Every Composable function is like a building block for our UI.

One other important thing is a preview. It’s always nice to have it to make UI development faster. In the case of Jetpack Compose, you need to declare it like this:

and here is the preview:

Looks not bad. Isn’t it? Currently it’s not that fast as Flutter hot reload, but for development preview it looks perfect.

Summary

As you can see, there are some exciting options to build Android UI. I would not consider the second option from those three options: creating UI in Runtime, as it doesn’t bring any benefits. And I would suggest to us classical XML approach (of course, if you start a new Android project today) to move to Jetpack Compose in the future.

Thank you, and Have a nice coding!