Your First Kotlin Android App: An App From Scratch

Firstly, a string in programming is generally used to refer to text. Now back to the the warning: the reason Android Studio points this issue out has to do with localization.

All your titles are currently in English. But that doesn’t mean that your app will always support just English.

If one of your goals is to make your app more accessible, you might want to translate the user interface to other languages.

With this, your app can be used by a wider audience.

Of course, you can say that you don’t care about localization at this point and that you’ll worry about it later. But Android Studio makes you think about these things from the outset.

It’s easier to create the app in a way that makes it easy to add localization for different languages in the future from the outset.

This is a better approach than to translate it after the project is completed. Because this would involve changing hard-coded text in many places.

This is where Android String resources come in.

In Android, you can set up resources for values which are used often - like specific colors, or values which need to be dynamically changed at runtime - like text titles.

You might remember the resources folder from the project structure from an earlier episode.

These translations are stored in a file called strings.xml.

This file stores all the strings used in the app so that all the strings used in the app are gathered together in one central place.

This means that if the same string is used in multiple places - for example, common buttons such as OK and Cancel - then there is only one copy of the string for all those instances.

A title change requires only one change in the strings.xml file.

To provide actual translations, all you need to do is to copy strings.xml and translate everything in the copy to the second language to be sure that all the text used in the app has been translated to support the new language.

Now, the big question is: “How can you use strings.xml in your layout?”

Well, Android Studio takes all the resources from the res folder and adds them to what is known as the R file.

It adds it there as a list of constants, meaning, their values can’t be changed later on. Don’t worry too much about the R file yet - you will see it in action soon enough.

But basically, every resource used in your app has a unique constant identifier that you can use to refer to it.

And the R file provides you with the necessary medium to access these constants.

So, for example, the constant to access the text for the app’s name would be app_name and you’d access this value in your code via the R file using a reference such as R.string.app_name.

You can add your own strings to the strings.xml file by simply editing the file to add more values to it. OR, You can do it via the fix action.

If you look at the warning panel, you can see a button that says “Fix” which would extract the text to a string resource. Go ahead and click it. This opens up a dialog box.

In here, we have the resource name which is the identifier for this text. Android Studio automatically provides us with a default which is generated from the string. But I’ll go ahead and give it a more decriptive name. In this case, name it: “instruction_text”

Next is the resource value which is the actual text that would be displayed. I’ll leave as it is since this is the text we want to see in the textview.

After that, we have the source set, we’ll leave it to the default value. We also have the file we want to store this value in. It is currently set to strings.xml We have other types of resources we can extract but since we’re working with strings, leave it as stirng.xml

Then click “OK”

To check it out, open up the project panel. Then navigate to res > values > strings.xml

You can see we have the string we extracted stored in this file. And we can access it by its name, in this case “instruction_text.”

This file also contains the app_name string that is displayed in the action bar. This is added for you whenever you create an Android project.

So you see, this is the recommended way to store text in an android app. At the top, you can also see how to add translations for different langauges referred to as locales. But that’s beyond the scope of this course.

Now, I’ll show you how this string value is used in your layout. Open up activity_main.xml once again. Then select the instruction text. Over in the attributes panel, we can see that the text is obtained from the string resource name instruction text.

I’ll go ahead and pause the recording and repeat the same for other views.

<string name="min_value_text">1</string>
<string name="max_value_text">100</string>
<string name="target_value_text">67</string>

This is the updated strings.xml file containing all the text for the views in our layout.

And if we look at activity_main.xml in code view we can see that all the textviews now uses string resources and we dont have those warnings again.

Finally, we need to give our views descriptive names. Names that reflect their purpose in the application. This is done by settting the id attribute of the views.

Currently, we have ids generated by Android Studio automatically when we add the views to the layout. We have ids like textView1, textView2 and seekBar. These are not very descriptive. You’ll change that up.

Open up the design view. Select the target textview. In the attributes panel, change the id to targetTextView then press the return key. This opens up a “Rename” dialog. Just click on the “Refactor” button to accept changes. This updates anywhere that the previous id was used in our project files to the new name.

We could have updated it manually in the xml file but remember, other views in the layout uses the id to add constraints. This means we would also have to update the id in multiple places and failure to do this would cause multiple errors.

The main reason we want to personalize an id is because you will reference these views in your code in the future. For instance, we want to be able to generate a new target value after the player guesses the value from the slider. So the target textview needs a descriptive name. The other view that requires an id is the seekbar. This is because we want to retrieve the value the player selects later on.

Go ahead and give it a better id. Select it. As you can see, seekBar is a good id and since there is only going to be one seek bar in the app we can leave it as it is.

You can go ahead and change the id for other views but I will leave mine as they are since i wont be needing to reference these views in my code. And if I change my mind later, then I can always come back and give them a descriptive id using the refactor feature of Android Studio.

Restart the activity to try it out.

And if you notice, it fails this time around because the views were renamed and Android Studio sees them as new views. In this case, restarting the activity will fail.

Go ahead and run the app this time around. This will reinstall the app on the emulator.

And everything works fine as expected.