Android Adventures - Activity And UI
Written by Mike James   
Tuesday, 10 February 2015
Article Index
Android Adventures - Activity And UI
Creating a UI
Connecting the Activity to the UI

So you know how to create an Android app, but do you really know how it works? In this second part of our ebook on getting started with Android using Android Studio we look at how to create a UI and how to hook it up to the code in the Activity.  
Updated for Android Studio 1.


Android Adventures With Android Studio


  1. Getting Started With Android Studio
  2. The Activity And The UI
  3. Building The UI and a Calculator App
  4. Basic Controls And Events
  5. Layout Containers
  6. Lifecycle and State
  7. Spinners
  8. Pickers
  9. UI Graphics A Deep Dive
  10. ListView And Adapters

  11. Introducing Fragments
  12. Fragments and XML
  13. Fragment And Activity Working Together
  14. Managing Fragments
  15. Custom dialogs using DialogFragment
  16. Dialog Classes In DialogFragment
  17. A NumberPicker DialogFragment Project
  18. ViewPager

If you are interested in creating custom template also see:

Custom Projects In Android Studio




We discovered in Chapter 1 how to use Android Studio  Google's Android IDE, to build the simplest possible app.

On the way we discovered that an Android app consists of two parts - an Activity and a View.

The Activity is the Java code that does something and the View provides the user interface (UI).

You can think of this duality as being similar to the HTML page and the JavaScript that runs to make it do something, or as a XAML form and the code behind.

The key idea is that an Activity is the code that works with a UI screen defined by the View. This isn't quite accurate in that an Activity can change its view so that one chunk of Java code can support a number of different views. However, there are advantages to using one Activity per view because, for example, this how the Android back button navigates your app - from Activity to Activity.

A complex app nearly always consists of multiple Activities that the user can move between like web pages but a simple app can manage quite well with just one Activity. 

There is no hard and fast rule as to how many Activities your app has to have - but it has to have least one.

If you are wondering if an Activity can exist without a View the answer is that it can, but it doesn't make much sense as this would leave the user with no way to interact with your app. Activities are active when their View is presented to the user. 

It really is a great simplification to think in terms of an Activity corresponding to a single screen with a user interface. 

If you want something to run without a UI then what you want is a service or a content provider - more of which much later. 

It is also worth making clear at this early stage that an Activity has only one thread - the UI thread - and you need to be careful not to perform any long running task because this would block the UI and make your app seem to freeze. That is an Activity can only do one thing at a time an this includes interacting with the user. 

Also notice that creating additional Activities doesn't create new threads. Only one Activity is active at any given time - more of this later when we consider the Activity lifecycle in detail.

In other words, Activities are not a substitute for knowing about threading but if you are just getting started you can ignore these issues for a while. 

For the moment let's concentrate on the single screen UI Activity because it is the most common app building block you will encounter and it is even where most complex apps start from.

The MainActivity

There is of course one activity that is nominated as the one to be launched when you app starts.

If you use Android Studio to create a new Blank Activity app called SimpleButton and accept all the defaults then the startup Activity is called MainActivity by default.

You can change which Activity starts the app by chaining a line in the app's manifest. The Manifest is a project file we haven't discussed before because if you are using Android Studio you can mostly ignore it but it is better if you know it exists and what it does. 

The Manifest is stored in the app/manifests directory and it is called AndroidManifest.xml. It is an XML file that tells the Android system everything it needs to know about your app. In particular it lists all of the activities and which one is the one to use to start the applications. 

If you open the generated Manifest, just double click on it, you will see a little way down the file:

   android:label="SimpleButton" >

This defines the Activity the system has created for you and the lines just below this:

  <action android:name=
          "android.intent.action.MAIN" />
  <category android:name=
          "android.intent.category.LAUNCHER" />

Define it as the startup Activity. Notice which Activity starts the app has nothing to do with what you call it i.e. calling it MainActivity isn't enough. 

For the moment you can rely on Android Studio to look after the Manifest for you. In most cases you will only need to edit it directly when you need to correct an error or add something advanced.

Inside the Activity

The generated Activity has one class MainActivity which holds all of the methods and properties of your activity. It also have three generated methods - onCreate, onCreateOptionsMenu and onOptionsItemSelected. The last two are obviously connected to the working of the OptionsMenu and this is an important topic but one that can be ignored for the moment. Not all Activities need to have an OptionsMenu and you could even delete them. 

The most important method defined is onCreate.

This is an event handler and it is called when you app is first created. This is the place we do all the initializations and setting up for the entire app. It is also generally the place we show the app's main UI screen. 

Let's take another look at the generated code for onCreate:

protected void onCreate(
                    Bundle savedInstanceState) {


The onCreate event handler is passed a Bundle object called savedInstanceState. This is intended to preserve state information between invocations of you app and we will see how this is used later. In this case no data has been saved and so savedInstanceState is null - but you still have to pass it on to the inherited onCreate method. 

The final instruction calls setContentView which is a method that has a number of different overloaded forms.

In this case we pass an integer that indicates which XML file describes the layout to be used for the view. The setContentView method uses this to create all of the components of you UI as defined in the XML file.

It is worth looking a little closer at the way that the layout file is specified because this is a general way that Android lets you access resources. 

The R object is constructed by the system to reflect the resources you have placed in the resource directories. In this case R.layout.activity_main returns an integer value that allows the setContentView method to find the activity_main XML layout file.

In general all resources are found via the R object, think of it as a library object of resources. 

View and ViewGroup

Ok so far so good but it is important to realize that what happens next it that the XML file is rendered as a set of View objects. That is Java objects that are all sub-classes of the View object. 

The entire UI and graphics system is implemented as a hierarchy of components derived from the View class. If you have used almost any GUI framework - AWT, Swing, XAML etc - then this idea will not be new to you. 

For example, a button is a class derived from view and to create a button all you have to do is create an instance of the button class.  You can, of course create as many buttons as you like simply by creating more instances. 

This leaves open the question of where the button appears in the layout?

The answer to this is that there are ViewGroup objects which act as containers for other view objects. You can set the position of the child view objects or just allow them to be controlled by various layout rules - more of which later. 

You can opt to create the entire UI in code by creating and working with instances of view objects and this is something demonstrated in a later chapter UI Graphics A Deep Dive.

Alternatively you can use XML to define view objects and how they nest one within another and rely on the system to create the view object hierarchy for you.

The simplest way however is to use the designer to create the XML file and then allow the system to create the objects for you from the generated XML file. 

Being able to work with the UI in an interactive editor is one of the great advantages of using Android Studio and even if you know how to edit the XML layout file directly it isn't a feature you should give up lightly. It is nearly always a good idea to use the layout editor at first and apply any tweaks, if necessary to the XML file later. 

Last Updated ( Tuesday, 10 February 2015 )

Copyright © 2015 All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.