Your First Kotlin Android App: An App From Scratch

One of the biggest pitfalls when you’re first learning app development is understanding what to do if something goes wrong - and believe me, things will go wrong at some point. These problems or mistakes are commonly known as bugs. And that’s not a bad thing if you know how to solve the problems.

I’ll show you how you can solve common mistakes that sometimes stump beginners.

To get started, continue with the current project you’ve been working on or open up the starter project for this episode.

One of the most common bugs is a typo bug and they are common during development. So if i delete the a from the alertIsVisible state object inside the hit me button’s onClick lambda, you can see it turns red. And if you hover over the error, you’ll see some message pops up saying “Unresolved reference.” This simply means that Android Studio couldn’t find anywhere in the file where a variable with that spelling was defined. So trying to reference it here is causing a problem.

We can also access all problems in our project via the problems tab in the tool window bar below. Go ahead and open it up. In here, you’ll see a list of all the problems and their corresponding line number in the file. Double clicking on them takes you to the point of the error. I’ll go ahead and add that a back to the alertIsVisible state.

Next, the Kotlin programming language is case sensitive. This means that an uppercase letter is different from a lowercase one.

So for instance changing the letter C in Column to a lowercase c will produce an error. This is because Kotlin sees them as two different indentifiers. You get the same “Unresolved reference” error message. I’ll go ahead and change that back.

Another thing that could cause a handful of unexpected problems is missing parenthesis. Errors that occur from missing parenthesis can be tricky to trace.

I’ll go ahead and remove the closing parenthesis of the parent Column. And if you look at the problems panel below, we have a plethora of errors.

The simple trick to solve these type of errors is to always start from the top. I’ll double click on the first error and it takes us to the code around the Column. By just looking at that section, you can see that it needs a closing parenthesis. The error shows that the Column composable function cant be called with the arguments supplied. And this is caused because Kotlin cant find a closing parenthesis so it continues looking down the file for the expected argument that the function call needs. I’ll add back the closing parenthesis.

The same also applies for curly braces which signify the start of a code block like the declaration of a function’s body.

To avoid this type of error, the rule of thumb is to always close a curly brace or parenthesis immediately after you open one. Android Studio helps you with this though. Whenever you open a parenthesis or a curly brace, the IDE’s intellisense automatically closes them for you. But these errors can still occur when you copy and paste code.

Finally, the location where you declare your variables matter. Let’s move the declaration of the alertIsVisible variable inside the inner Column. If you scroll down to where it is used inside the if conditional statement, you can see we have unresolved reference error. And this is because the alertIsVisible is now local to that Column call. Meaning that the rest of the code outside that inner Column wont have access to it and the if condition is currently outside it.

This is known as variable scope. And the alertIsVisible variable is now a local variable of the Column composable function call. You’ll learn more about scope as you explore the Kotlin programming language. I’ll move that line of code back up now.

Android studio will always try its best to give you a reasonable message and suggestion. But whenever something shows red, start at the topmost error, go to the code on that line, and trace downwards.

So far in this episode, we’ve been dealing with errors - which are in red,

but sometimes, Android Stuido will give you warnings, which are in yellow.

Now, what’s the difference? Well, errors are fatal. If you get one, you cannot run the app until the error is fixed.

On the other hand, warnings are informative. We’ve come across several warnings in earlier episodes. Like when you add an import statement but dont use it in your code.

Android Studio just says, “You probably didn’t mean to do this, but go ahead anyway.”

Personally, I’ll suggest you treat most warnings as errors and try fix them before moving on.

Now this doesn’t guaranty that your app won’t have any bugs, but at least they wont be silly ones.

I’ll go back and remove those unused import statements. Leave the alertIsVisible warning as this logic is needed in our code.