Page 1 of 4
So you know how to create an Android app, but do you really know how it works? In this second part of our new 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.
Android Adventures With Android Studio
- Getting Started With Android Studio
- The Activity And The UI
- Building The UI and a Calculator App
- Lifecycle and State
- Basic Controls And Events
- UI Graphics A Deep Dive
- ListView And Adapters
- Introducing Fragments
- Fragments and XML
- Fragment And Activity Working Together
- Managing Fragments
- Custom dialogs using DialogFragment
- Dialog Classes In DialogFragment
- A NumberPicker DialogFragment Project
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 new 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 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. 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.
For the moment let's concentrate on the single screen UI Activity because it is the most common app building block you will encounter.
There is of course one activity that is nominated as the one to be launched when you app starts.
If you 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 src/main directory and it is called AndroidManifest.xml. It is an XML file that tells the Android system everything it needs to know about you 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 you will see:
This defines the Activity the system has created for you and the lines:
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.
Inside the Activity
The generated Activity has one method defined - 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
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 fro the view. 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.
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. 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.
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.