Creating an Android App for beginners — Part II

Felipe Lima
6 min readSep 23, 2015


This is the second part of a series of posts. You can find the part one here.

So this time we're gonna start to write the Android application code for our game. You'll need to download Android Studio in order to get started.

The Android Studio IDE is based on IntelliJ, which is a very good and well known Java IDE created by JetBrains. Google "forked" it to add more functionality specific to Android development, but the majority of the standard IntelliJ functionality also applies to Android Studio.

Build tools

The standard build tool is Gradle, which was built on the Groovy language. It lets you manage the project dependencies and build process by configuring project Modules. Each module has its own dependencies, tasks and outputs. An Android project contains a build.gradle which defines most of its configuration and dependencies. When you create a new project on Android Studio, it already creates a basic structure with a build.gradle file for you, so you don't have to write it from scratch.

Gradle uses Apache Maven under the hood for many of its project management functionalities, most notably to download the dependencies. They typically have to be downloaded from a central repository, for example Maven Central or Jcenter. There is a top level build script where you define where your dependency artifacts are downloaded from and it usually looks somewhat like this:

For your project build script, you'll have your Android specific configurations like minimum/target SDK version, applicationId, versionCode, etc. This is an example of how it may look like:

The dependencies section above is an important part of your build script and defines all the external/third party libraries that your application depends on in order to work. This is where you'll include, for example, your networking library, JSON parsing, dependency injection framework, testing library, etc.

Each dependency follows the Maven naming convention, where each one contains at least 3 pieces of information, in the following order: groupId, artifactId and version.

Each piece is separated by a colon into a single string, for example:

compile 'com.example:libraryName:1.0.0'

In the example above, groupId is com.example, artifactId is libraryName and version is 1.0.0.

You can also add dependencies on jar files, for example:

compile files('libs/auto-moshi-0.1-SNAPSHOT.jar')

This is just the basic and there is much more you can do with Gradle. Please refer to the documentation for more info.


Now we'll get back to our Elifut application mentioned in the first article. You can follow through the code on Github. We'll start by adding an initial Activity called MainActivity which will be our first screen. In this screen, the user will be able to type their name and select a country, using our API. But before jumping into the actual code, it's very important for any Android app to pick the right tools (libraries) to use. The list below consists of my personal preferences and should not by any means be considered final or absolute truth. Given the option, I tend to pick a Square library, just because they are, in general, very well know, widely used and simply are great libs overall. Here are some of my go-to, organized by category:

  • Support libraries: This is a no-brainer. If you want to support older Android versions with very little effort, always include the Android Support library in your project, which backport newer APIs so you can use them safely. There are several different support libs for different objectives, like the CardView, Palette, Design, RecyclerView, etc. Make sure you know and use them! These are all maintained by Google.
  • Networking - Retrofit: This is such an ubiquitous and great library, I just can't avoid using it. You just write a Java interface with annotated methods that define your API endpoints and Retrofit generates the implementation for you. It's super convenient and works great. Highly recommended. Another options is using Volley, which was written at Google.
  • Image Loading: Picasso: Another Square library, provides a very simple and intuitive API. Also take a look on Glide, if you want to evaluate other options.
  • Event Bus: Otto or EventBus: I don't have a strong preference here, you can pick either one, but using an event bus is a great way to prevent tight coupling between your app components.
  • JSON Parsing: There are just a lot of options here, most notably Gson and Jackson. These ones provide a higher level API with annotations support and automatic data binding to your Java classes. You could also use the plain org.json classes included in the Android SDK if you don't need anything fancy. Lastly, Square recently released Moshi, which has an API similar to Gson's. Also take a look on LoganSquare if you have time.
  • View binding: After a couple days working with Android, most people realize how tedious and cumbersome it is to do findViewById all the time. That's why you'll want to take a look on ButterKnife which simplifies that (and a lot of other view-related code). Also, Android has a new Data Binding library (still in beta) that will allow you to "embed code" in your XML views like JSP or ERB, for example.
  • Miscellaneous: I also really like using Icepick for simple Activity/Fragment state saving/restoration and Google's AutoValue. Lastly, you'll probably also want something to handle Parcelable implementation for you. For that, my favorites are AutoValue and auto-value-parcel (still under development).

There's a lot more stuff to look into, this is just scratching the surface. I'll leave it up to you to dig into other useful libraries to make your Android development more pleasing :)

First Activity

Now we're start writing our first Activity. In the Android world, activities are simply screens of your app. They can contain multiple Views and Fragments. As the official documentation says, Views are the basic building blocks for user interface components. We'll look into Fragments later. This activity will be called MainActivity and will be the entry point of our app.

When this Activity is created (when the app is launched), the onCreate() method is called and all we're doing there is to set the contents of this activity to the activity_main.xml file contents. Also note that we're extending AppCompatActivity instead of Activity, which uses the AppCompat Support library version of Activity and allows us to target older Android versions and still use newer features of the SDK. It backports newer features so we can start using them today.

Android uses XML files to define layouts and that is usually where you'll define your views. Here is how our activity_main.xml layout wil look like:

We're using a few of the Design Support library widgets, as you can see from the prefixes in the tag names. We're also adding a Toolbar from the AppCompat Suport library. The Toolbar works like an application bar at the top of the screen and is pretty much ubiquitous in the Android world as a very strong design pattern. It replaces the old ActionBar widget as a more flexible and modern one. That is where we'll usually put the app name, the title of the screen, action buttons and overflow menu, for example. This is a very important piece of the android design ecosystem.

Next, going back to our MainActivity class, we'll have to bind our Views that we defined in the XML, so they can be accessed from there. This is where ButterKnife comes into play:

@Bind( Toolbar toolbar;
@Bind( CollapsingToolbarLayout ctLayout;
@Override protected void onCreate(Bundle savedInstanceState) {
toolbar.setTitle("Hello World");

When you call ButterKnife.bind(this), it goes throught the Activity layout and the @Bind annotations you defined above and assigns the views to the annotated fields. It's pretty magic and saves you from having to write a lot of boilerplate.


In this article we went through the steps needed to create a new Android application, how the build system works, creating an Activity, a layout for it and using its Views in the Java code. Next up we'll dig deeper into the application code. Stay tuned!

Thanks to Gabriel Peal for reviewing this article!



Felipe Lima

Brazilian, Gaúcho and Software Engineer