Once you've started your first project in Android Studio and tested it on a device, a lot of doors start to open up for you. Things should hopefully begin to click into place and I imagine you could create a few different things based off of that starting point.

But guess work will only get you so far and what’s much better is that you actually understand what everything does and why Android development is handled the say it is. This will help a great deal going forward and result in better app design.

We’ve briefly touched on what those import lines do, but we’ve only gone into very basic detail regarding that onCreate line. And what exactly does super.onCreate(savedInstanceState) do? What is an appCompatActivity when it’s at home?

A lot of this has to do with our app lifecycle…

Lifecycle of an app

Android apps go through a number of stages from the point when they’re first loaded, to the point when they get closed down. More specifically, each activity will go through a set number of stages.

These are handled as ‘events’ inside your code. So when the user changes your app’s state in some way: by launching it, pausing it, closing it, etc. Events run as methods (sequences of instructions inside curly brackets) and this means that we can then hijack those methods and decide what we want to happen at each stage. This is where the line ‘@Override’ comes from. It means that we’re making a method that isn’t an original method, but rather one that would always have executed and we're just hopping on.

Other events include:

  • onCreate
  • onStart
  • onResume
  • onPause
  • onStop
  • onDestroy

So onCreate is called when the activity is first brought to life. It is then paused (onPause) when the user opens up a different app and sends ours to the background, or when they rotate their device and we have our app set to reorient itself. Once the app has finished rotating or it is brought back to the foreground, onResume() or onCreate() handles the resurrection of our app. onStop() is called if the app is completely closed or removed from memory while operating in the background.

The line super.onSaveInstanceState(); tells Android to save the ‘state’ of all of our views so that if the app is kept in the background for a while and then opened again, all the text fields will still contain the same text and any elements that have moved around the page will still be where our user last left them. If you override onCreate() and don’t include that line, then some strange things can happen.

The following graphic from Google can help:

Note that when your app is in the background, it will be paused or stopped until the user navigates back to it or until the system needs more memory. If that happens, then the app process can be killed and then it will need to start again from ‘onCreate()’ when it is next launched. How often this happens depends on how aggressively Android customizations are handling memory management, as well as how much memory the device has.

Notice how we are also overriding the onClick method that belongs to the Button. That’s because the button is handled by a separate class (hence our need to import it) and we’re once again hijacking that code to define what happens when the button gets clicked ourselves!

Inheritance and AppCompatActivity

The next line that we’re going to put under the microscope is the one that says:

public class MainActivity extends AppCompatActivity {

This line essentially defines our code as a class. A class is a ‘module’ of code that can be used elsewhere and that has specific properties that we'll discuss later. Because the class is described as ‘public’ that means that we could theoretically access its methods from elsewhere. Again, roll with it - future posts will explain this further.

The next part of the line, extends AppCompatActivity, means that we’re inheriting properties from another class. This gives us access to additional methods that define the behavior of our activity. Methods such as onCreate and findViewByID. This line is what takes our Java code and turns it into an Android activity! We 'inherit' the methods that make the code behave as such and in doing so, we can access them in our code using @Override. It's all starting to make sense! Maybe. Probably not.

Technically, our activity class is really a ‘subclass’ of AppCompatActivity. And this is the way that we actually want to handle most of our classes that we intend to use as activities, as it will allow them to behave the way that activities are supposed to behave and it will give us access to functionality expected of an app. There are exceptions however, such as when you might choose to extend Activity instead of AppCompatActivity when you don’t need the action bar features. This still builds an activity, just a slightly different kind.

So most activities you create are going to feature these statements and will override the same methods. Each new screen you create will automatically be populated with this code and this is what we refer to as 'boilerplate code' - code that you repeat over and over to gain just basic functionality.


This explains how your activities will run and why certain elements in your code need to be there. Hopefully you have a bit more understanding of how things are operating behind the scenes.

To get a fuller grasp of this though, I highly recommend that you read the upcoming post on creating and launching new activities. There, we’ll see how to set up a new activity with inheritance and demonstrate how an app would handle multiple activities and lifecycles.