CODEX

The day after Hello World

So it begins…

Hi!

If you read this, there is a big probability that you are one of us now! And… Sorry, but I have to warn you… You may face all the DEV stereotypes too! Welcome! Don't worry, we are all in this together.

Photo by Denny Müller on Unsplash

This next part is totally necessary, and I'm about to tell you why.

As a developer, I faced many problems because I did the big steps first, and I know it sounds a little bit ridiculous, but when I say big, one example is that I started working on a project that I didn't even know how it was structured, or the basic steps, like the purpose of the config files and how everything connects when the build is successful. With that in mind, I think we should analyze what we have until here because of course, you don't want to repeat my mistakes.

Project Structure

If you chose Kotlin and if you chose the start with a Basic Activity by default, you have a project to call your own now.
So, it should look like this:

First Application with Basic Activity

But Bruna, look at this picture!! That's a lot to take in! Yeah, I know, but let's go slow… We will understand each file, one by one… or die trying. 💀

Manifest file

The first topic is AndroidManifest.xml.
This file contains many essential configurations of your app.

What you need to remember is that when you want to declare levels of permissions (e.g., location), all the Android Components of your app (we will talk about it right away), what hardware features your app requires (e.g., camera), package name, etc., you will have to change this setup file.

PS.: The Package Name is an important variable here. It is used to find the code entities in build time, but it will be replaced by the application variable declared in build.gradle file in packaging time. It is important to remember that both of them are relevant and they will determine the unique ID of your application in the Play Store.

Files under java package

OMG!
Bruna, you told me it would be Kotlin! Yes, it is possible to change this source directory name and it's also unnecessary for now.

Here we must start with the Android Components. Our project has a MainActivity, FirstFragment, and SecondFragment under the java folder and that's why we have to talk about Activities and Fragments.

Activities

This component is one of the main keys to Android Development.

It provides a single-window and user interface where you can interact based on your screen purpose. In other words, you can configure the behaviors of each screen in this class. In your project, you can do it in MainActivity.kt.

The activity can be responsible for many things. Set the screen layout and declare your UI components actions are some examples.
You have one Activity in your project, so you can find the link to its screen layout components configurations right there.

And I have to tell you… The Activity is a Big Girl… and she has its own lifecycle.

It means that if you want to develop a custom action according to your app journey execution or an Android System event, you can access and use these pieces of information following the Activity Lifecycle.

You will understand it better when you find yourself in a situation where you should act when your app pauses (when you receive a call for example) or any other situation, but for now, you can take a look at this:

The Activity is also the Component called when your application is launched, that's why in your AndroidManifest.xml file you can see:

<activity
    android:name=".MainActivity"
    android:label="@string/app_name"
    android:theme="@style/AppTheme.NoActionBar">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

This base concept must be solid because it will repeat in every application you will develop. This is also important for you to structure your screen in a way that it correctly does its job, without duplicating actions.

Fragments

Ok! We have the Main window, our MainActivity…But how can I make it decoupled? Yes, with Fragments.

This component came to facilitate the way we organize our code and to put things in the right place. Imagine an application with five different screen UI states, different contents in one screen, and more… Yes, it was not a very good code (and performance) before fragments.

Fragments are reusable, and this is its main (and better) characteristic.
A Fragment class is developed as a portion of code (and UI) that can be used in different places of your app, multiple times and with its logic totally decoupled from the other classes (e.g. Activity).

It brings the concept of modularity, and with Activities, they allow you to separate the global elements, such as navigation, to the part of the screen and code you will need in different places of your app.

Wow! What a moment! Why? Because this is the beginning of What I need to develop/How I can develop it. At this point, you can start thinking exactly like the image below.

And every time you start a different demand, you will imagine and picture your UI architecture automatically.

Res

This is the location of your resources.
They can be drawable, layouts, menu config files, navigation config files, or even values files.

Drawable

Drawable is a graphic that can be drawn. I know it seems quite superficial, but it's because there are some different topics under this umbrella.

For example, if you need images, you can configure them in different formats. Android Studio has a tool called Asset Studio that will help you if you want to transform a .svg file into a .xml file. This second format will be interpreted as a drawable resource.

It's also possible for you to create your own resource drawable following the different available types. It's very handy when you don't have the asset created by the designer or when it's as simple as a colored background with rounded corners because you know… in this case, you should do it for yourself.

Inside this folder, you can put different types of drawables based on screen sizes, densities, and other properties, too. This topic is important because we have an automatic tool that provides all resources according to the device properties and all you need to do is supply the categorized assets.
It's very possible to custom your application to give a better experience to different screens.

Layouts

This folder is where your UI Architecture is configured.
You will see that the .xml files can be built as an Android UI Component.
That said, when you need to set up a new interface component, a custom view, or everything connected to your layout and screens, you will find where to design it in these layouts files.

Now… Open the file activity_main.xml and see the UI Components of your main screen there. You can see how your screen looks like just by looking at the Layout Editor Viewer.

A Basic Activity created automatically by Android Studio will possibly have a toolbar (top bar), and include a tag with the fragment (a portion of the screen, remember?), and a FAB (Floating Action Button). All these components can be accessed by the classes that call its layouts respectively.

Menu

You might want to configure menu files if your app needs more options in the toolbar or more robust solutions.

Mipmap

The mipmap folder is the location of your App Launcher Icon, that one that appears on your device's home screen and menu. They have a config to make your icon looks better in different densities.

Navigation

This is the file where you will be able to configure the App Navigation Flow. When you create a project, the Navigation Component dependency is included automatically.

It will make your app destinations (anywhere in your app to which users can navigate) easier to be described and it will be all in one place.

There will be a navigation graph that will help you to see it clearly.
For example:

In this image, you can see the connections between the two fragments of your app. Both of them have declared actions to call each other.

Values

The values of your resources can be put there.
If you need a text, different size values, params to be used in different parts of your app, you will need to declare their values in XML files under this folder.
If you open the strings.xml, you will see the name of your application and other values that are used in layouts and classes of your project.

The styles are stored there too, so if you want to configure params that will be used to custom your app, you can put them there and it will be interpreted to all app components based on your config.

I think that the best way to understand this part is to take a brief looking at these files and see how a value is used in other places.

PS.: When I open a project, this is one of the first parts I seek to understand how much the project is organized. If it has insufficient params, the application probably has many fixed values and this is not a good practice.

Gradle

This is the last topic. I am very proud. You've come so far. All right, let’s get to it.

Gradle is a toolkit to automate and manage the build process. Simple, right?
But also robust. So…Bruna, I need to configure a setting to my build, like the dependencies of my project. Where can I put it?
I am glad you asked

There are different grade files in your project and you will be able to set up things like your libraries, your build settings (e.g. when you want different built apps based on different properties, like free or premium, QA or Production, white labels, etc…), signing configs needed to the apk to the Play Store, and much more.

The main responsibilities of each file are:

gradle.properties — setup of the gradle mechanism (e.g. memory usage) and the properties that will be used by the Java process to execute the build. You can see two levels of this file, the global one (specified as Global Properties), which is located in your gradle path (~/.gradle/gradle.properties), and the Project Properties one. Any setting configured through the Android Studio will override the other settings. But you don't need to change anything for now.

settings.gradle — It is used to define all included submodules and to declare the root of a tree of modules.

gradle-wrapper.properties — Store your gradle distribution settings, like the version you are using and the source. Specific versions for tests and your build are configured in this file.

proguard-rules.pro — Proguard is a tool that helps to make the app as small as possible, obfuscated (it hides important info) to be more secure and optimize the app. The rules you can apply to the classes are stored in this file. Proguard is important to difficult the reverse engineering process.

build.gradle— (The beginning of a relationship)
You start with two levels of this file (at least): the one placed under app level and project root level.
The main differences are:
app-level — This file is used to declare the settings of your module app-only

top-level — It defines the configs that can be accessed by all modules of your project. Your project has one module only, so all the configs needed by the app are available for it.

That's all folks! I know it was a lot! But please, be comprehensive… I needed you to know about Android Components, Interface, Drawables, Values, Gradle, Lifecycles, Navigation, and the other things we just talked about. You are ready to get your hands dirty!!!

In the next post, we will create our first screen.

It will be a list, using a custom layout with image, text, button, and other UI components. That's exactly the type of screen an Android developer does a thousand times. With that, we will be able to use RecyclerView, Adapter (and talk about some Design Patterns), ViewHolder, create a Custom View, perform actions, and much more…

I know you may not understand anything I said above… But take my hand and let's do it together!

See you!