Code Review on Android Projects - Part II

Continuing the previous post ...

String Resources

First of all, it is a good practice to put the text inside of a strings.xml file. We also need to be careful about how to use this powerful resource to keep easy maintenance. For example, if you need to create a new string resource to the text ``GET STARTED''. You can define the following:

It works, but imagine if you have in another place of your app to use the same string, using it in camelcase mode, something like ``Get Started''. You would need to create another item in your string file. For this reason, I like to create strings like ``Get Started'' in camelcase, because it is more useful. Using this way, you can build a text transformation using a custom style to simulate the uppercase mode.

How can we name the keys?

I think we need to consider two cases, the first one is short texts, you can use the same value to the key:

In the second case, when the text is long, you can put a name to identify the description. Most of these cases are when we need to show alert messages, successful messages, and so on.

Annotations

Each resource in the Android World has a unique id. The id type is a ``Int'' value for default. But if you need to build a custom view component that works with the id, how do you do? For example, the following code.

In a code review process, we can recommend using an annotation to identify what kind of resource this method returns. What kind of ``Int'' this method returns. If we solve this issue, the code will be:

AndroidX package provides other kinds of annotations. You can check it here.

In the next article, we will check more points to improve your code review in an Android project ;)