Java For Android
Java for Android is subtly different to vanilla Java. Learn about the differences and what they mean for your code in this Java for Android article. By Darryl Bayliss.
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Sign up/Sign in
With a free Kodeco account you can download source code, track your progress, bookmark, personalise your learner profile and more!
Create accountAlready a member of Kodeco? Sign in
Contents
Walking Through Java on Android
Android makes extensive use of Java’s adoption of the Object Oriented Programming paradigm, and it’s designed to work around the concepts of encapsulation, inheritance and polymorphism. You utilize all of these when you build apps.
All objects in Android inherit from the Object
class in some form, building upon its functions to provide specialized behaviour and features. Take a look at some of the objects available through the Android API; you can see the hierarchy that each object inherits, and all of them eventually inherit Object
.
Not-So-Paranormal Activity
The Activity
class is an object dedicated to a specific screen of an app. Think of it as something that handles and displays all the associated work that drives the functionality for that screen.
Since your app will have at least have one or two functions, it would make sense to spread them across a few screens so your interface isn’t cluttery. To create a screen, you create a new Java class and have it extend Activity
like so:
public class MainMenuActivity extends Activity {
}
Just like that, you stub out an area of your app for a specific purpose. Your Activity
doesn’t yet know its purpose because you haven’t told it what to do or how to appear.
You can create your activity’s appearance, aka Layout, one of two ways:
- Declare it in an XML file
- Programatically create it in a Java class
The more common approach is creating the layout in an XML file. You’d take the programmatic approach if you need to tailor some aspect of your layout.
This article won’t take you take through either process for creating layouts, but understanding how to do it is helpful if you intend to write apps for Android, because it’s a regular task. Learn more about layouts from Android’s documentation.
The following code snippet demonstrates how you would specify that an activity should determine its appearance using the XML layout in res/layout/activity_main_menu.xml.
public class MainMenuActivity extends Activity {
// 1
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState); // 2
setContentView(R.layout.activity_main_menu); // 3
}
}
Take a look at it bit-by-bit:
- First, you override
onCreate()
, one of the methods available to you in anActivity
. It runs when yourActivity
is created, giving you ample time to set up anything you need. This is often the first method you create for anActivity
. - You then call the superclass implementation of
onCreate()
to ensure any set up required for theActivity
is performed. This is a required step. If you don’t do it, your app will crash with an exception warning. - Finally, you tell your
Activity
to show a screen by usingsetContentView()
, passing in a layout that’s referenced fromR
.
Note: R
is a special class generated by Android for your app’s various assets. These could be a screen layout like you see above, or it could be something like a localized string, image or animation. Android generates R
while building, so you shouldn’t modify it at all. More information about it is available from developer.android.com.
Note: R
is a special class generated by Android for your app’s various assets. These could be a screen layout like you see above, or it could be something like a localized string, image or animation. Android generates R
while building, so you shouldn’t modify it at all. More information about it is available from developer.android.com.
The XML layout will most likely include elements which make up the UI. You access these elements though R
in an Activity
, like this:
public class MainMenuActivity extends Activity {
TextView mTextView;
Button mButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main_menu);
mTextView = (TextView) findViewById(R.id.textview_main_menu);
mButton = (Button) findViewById(R.id.button_main_menu);
}
}
The key aspect is findViewById()
, which searches the XML layout for view objects specified by their ID, allowing you to manipulate them from Java. Note that you have to typecast each call into an appropriate View
subclass, since findViewById()
only returns a View
object—the root object from which all UI components inherit.
Once you have access to the individual view elements within the Java code, you would be able to interact with them and make them perform actions as you see fit. The following code segment demonstrates adding an action for when the user clicks a button:
public class MainMenuActivity extends Activity {
TextView mTextView;
Button mButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main_menu);
mTextView = (TextView) findViewById(R.id.textview_main_menu);
mButton = (Button) findViewById(R.id.button_main_menu);
mButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
mTextView.setText("Hello World");
}
});
}
}
The code above runs onClick()
every time your button is clicked. In onClick()
, you tell your TextView
, initially empty, to show the text “Hello World”.
Using this simple approach to link views to your class and provide actions to perform on a certain event, you can build highly complex activities. Remember these basic steps, and you’ll be on your way to grasping how Java and Android come together.
Lets Go Modeling
Models are integral to writing an Android app. Not to be confused with the kind of model that struts down the catwalk, they allow you to create objects that consist of data structures and functionality that you can utilize to great effect.
Models exist in separate classes from your UI classes. This separation not only helps keep your app organized, but it conforms to the idea of encapsulation in Object Oriented Programming.
A typical model looks something like this:
public class ReminderList {
private ArrayList mReminderArrayList;
public ReminderList() {
mReminderArrayList = new ArrayList<>();
}
public void setReminderArrayList(ArrayList reminderArrayList) {
this.mReminderArrayList = reminderArrayList;
}
public ArrayList getReminderArrayList() {
return mReminderArrayList;
}
public void removeLastItemFromList() {
if (!mReminderArrayList.isEmpty()) {
mReminderArrayList.remove(mReminderArrayList.size() - 1);
}
}
}
No mentions of a view or activity in sight! Just data structures, raw data types and various functions. In fact this is just a Plain Old Java Object (POJO) — no secret sauce at all. This model is perfectly encapsulated, meaning you could drop it into any Android app and start using it straight away.
When creating objects in other OOP based languages, it’s conventional to create instance variables that are defined globally within the context of the object. In Android, it’s also conventional to prefix these instance variables with an m so it’s easy to tell what is a non-public, non-static instance variable and what isn’t. It feels a bit odd at first but is a good habit to get into, especially since Android source code specifies this convention and you’d need to do it to contribute to Android source code directly.
Getters and setters for member variables are also a staple of Android development. These short methods provide the rest of your app with a way to change a member variable if needed, and they allow you to provide extra behavior when getting and setting member variables.