> For the complete documentation index, see [llms.txt](https://android-course.cornellappdev.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://android-course.cornellappdev.com/chapters/3.-intent-and-manifest/3.1-activities.md).

# 3.1 Activities

In the previous chapter, we mentioned how each activity consists of a layout file controlling the design and a class file to help with the logic behind all the different GUI elements. So far in our application we’ve only been working with one `Activity` class, but an application can have several!

Let’s see an example of this in action with Eatery. 

![MainActivity (1) and CampusMenuActivity (2)](/files/-Lv_AIpRDpcnysFYStJu)

The two different screens displayed here are each their own activities in the codebase. When the user clicks an Eatery card in `MainActivity`, we say we launch the second activity. In the `onCreate()` method of the second activity, we populate the `TextView` and wait times chart with the appropriate values. When the user clicks the back button in the second activity, then we say that the second activity has **finished**, and the display returns to `MainActivity` (which is the last unfinished activity).

## A Deeper Look

Returning to our project with the single `MainActivity` class, we can see that `MainActivity` extends `AppCompatActivity`, which is a built-in class that extends `android.app.activity`. 

This tells us that `MainActivity` is of type `Activity`, and so all of the `Activity` class methods become available for the programmer, including `setContentView()` and the overridden method `onCreate()`.