A Java Review
Android applications are written primarily in the Java Language. This appendix contains a review of some Java fundamentals needed when developing for Android, presented as a set of practice exercises.
The code for these exercises can be found at https://github.com/info448-s17/lab-java-review.
A.1 Building Apps with Gradle
Consider the included Dog
class found in the src/main/java/edu/info448/review/
folder. This is a very basic class representing a Dog. You can instantiate and call methods on this class by building and running the Tester
class found in the same folder. - You can just use any text editor, like VS Code, Atom, or Sublime Text to view and edit these files.
You’ve probably run Java programs using an IDE, but let’s consider what is involved in building this app “by hand”, or just using the JDK tools. There are two main steps to running a Java program:
Compiling This converts the Java source code (in
.java
files) into JVM bytecode that can be understood by the virtual machine (in.class
) files.Running This actually loads the bytecode into the virtual machine and executes the
main()
method.
Compiling is done with the javac
(“java compile”) command. For example, from inside the code repo’s directory, you can compile both the .java
files with:
# Compile all .java files
javac src/main/java/edu/info448/review/*.java
Running is then done with the java
command: you specify the full package name of the class you wish to run, as well as the classpath so that Java knows where to go find classes it depends on:
# Runs the Tester#main() method with the `src/main/java` folder as the classpath
java -classpath ./src/main/java edu.info448.review.Tester
Practice: Compile and run this application now.
Practice: Modify the Dog
class so that it’s .bark()
method barks twice ("Bark Bark!"
). What do you have to do to test that your change worked?
You may notice that this development cycle can get pretty tedious: there are two commands we need to execute to run our code, and both are complex enough that they are a pain to retype.
Enter Gradle. Gradle is a build automation system: a “script” that you can run that will automatically perform the multiple steps required to build and run an application. This script is defined by the build.gradle
configuration file. Practice: open that file and look through its contents. The task run()
is where the “run” task is defined: do you see how it defines the same arguments we otherwise passed to the java
command?
You can run the version of Gradle included in the repo with the gradlew <task>
command, specifying what task you want to the build system to perform. For example:
# on Mac/Linux
./gradlew tasks
# on Windows
gradlew tasks
Will give you a list of available tasks. Use gradlew classes
to compile the code, and gradlew run
to compile and run the code.
- Helpful hint: you can specify the “quite” flag with
gradlew -q <task>
to not have Gradle output its build status (handy for therun
task)
Practice: Use gradle to build and run your Dog program. See how much easier that is?
We will be using Gradle to build our Android applications (which are much more complex than this simple Java demo)!
A.2 Class Basics
Now consider the Dog
class in more detail. Like all classes, it has two parts:
Attributes (a.k.a., instance variables, fields, or member variables). For example,
String name
.- Notice that all of these attributes are
private
, meaning they are not accessible to members of another class! This is important for encapsulation: it means we can change how theDog
class is implemented without changing any other class that depends on it (for example, if we want to storebreed
as a number instead of aString
).
- Notice that all of these attributes are
Methods (a.k.a., functions). For example
bark()
Note the method declaration
public void wagTail(int)
. This combination of access modifier (public
), return type (void
), method name (wagTail
) and parameters (int
) is called the method signature: it is the “autograph” of that particular method. When we call a method (e.g.,myDog.wagTail(3)
), Java will look for a method definition that matches that signature.Method signatures are very important! They tell us what the inputs and outputs of a method will be. We should be able to understand how the method works just from its signature.
Notice that one of the methods, .createPuppies()
is a static
method. This means that the method belongs to the class, not to individual object instances of the class! Practice: try running the following code (by placing it in the main()
method of the Tester
class):
Dog[] pups = Dog.createPuppies(3);
System.out.println(Arrays.toString(pups));
Notice that to call the createPuppies()
method you didn’t need to have a Dog
object (you didn’t need to use the new
keyword): instead you went to the “template” for a Dog
and told that template to do some work. Non-static methods (ones without the static
keyword, also called “instance methods”) need to be called on an object.
Practice: Try to run the code Dog.bark()
. What happens? This is because you can’t tell the “template” for a Dog
to bark, only an actual Dog
object!
In general, in 98% of cases, your methods should not be static
, because you want to call them on a specific object rather than on a general “template” for objects. Variables should never be static, unless they are also final
constants (like the BEST_BREED
variable).
- In Android,
static
variables cause significant memory leaks, as well as just being generally poor design.
A.3 Inheritance
Practice: Create a new file Husky.java
that declares a new Husky
class:
package edu.info448.review; //package declaration (needed)
public class Husky extends Dog {
/* class body goes here */
}
The extends
keyword means that Husky
is a subclass of Dog
, inheriting all of its methods and attributes. It also means that that a Husky
instance is a Dog
instance.
Practice: In the Tester, instantiate a new Husky
and call bark()
on it. What happens?
Because we’ve inherited from
Dog
, theHusky
class gets all of the methods defined inDog
for free!Try adding a constructor that takes in a single parameter (
name
) and calls the appropriatesuper()
constructor so that the breed is"Husky"
, which makes this a little more sensible.
We can also add more methods to the subclass that the parent class doesn’t have. Practice: add a method called .pullSled()
to the Husky
class.
- Try calling
.pullSled()
on yourHusky
object. What happens? Then try calling.pullSled()
on aDog
object. What happens?
Finally, we can override methods from the parent class. Practice: add a bark()
method to Husky
(with the same signature), but that has the Husky
“woof” instead of “bark”. Test out your code by calling the method in the Tester
.
A.4 Interfaces
Practice: Create a new file Huggable.java
with the following code:
package edu.info448.review;
public interface Huggable {
public void hug();
}
This is an example of an interface. An interface is a list of methods that a class promises to provide. By implementing the interface (with the interface
keyword in the class declaration), the class promises to include any methods listed in the interface.
This is a lot like hanging a sign outside your business that says “Accepts Visa”. It means that if someone comes to you and tries to pay with a Visa card, you’ll be able to do that!
Implementing an interface makes no promise about what those methods do, just that the class will include methods with those signatures. Practice: change the
Husky
class declaration:
java public class Husky extends Dog implements Huggable {...}
Now the the Husky
class needs to have a public void hug()
method, but what that method does is up to you!
A class can still have a
.hug()
method even without implementing theHuggable
interface (seeTeddyBear
), but we gain more benefits by announcing that we support that method.- Just like how hanging an “Accepts Visa” sign will bring in more people who would be willing to pay with a credit card, rather than just having that option available if someone asks about it.
Why not just make Huggable
a superclass, and have the Husky
extend that?
Because
Husky
extendsDog
, and you can only have one parent in Java!And because not all dogs are
Huggable
, and not allHuggable
things areDogs
, there isn’t a clear hierarchy for where to include the interface.In addition, we can implement multiple interfaces (
Husky implements Huggable, Pettable
), but we can’t inherit from multiple classesThis is great for when we have other classes of different types but similar behavior: e.g., a
TeddyBear
can beHuggable
but can’tbark()
like aDog
!Practice: Make the class
TeddyBear
implementHuggable
. Do you need to add any new methods?
What’s the difference between inheritance and interfaces? The main rule of thumb: use inheritance (extends
) when you want classes to share code (implementation). Use interfaces (implements
) when you want classes to share behaviors (method signatures). In the end, interfaces are more important for doing good Object-Oriented design. Favor interfaces over inheritance!
A.5 Polymorphism
Implementing an interface also establishes an is a relationship: so a Husky
object is a Huggable
object. This allows the greatest benefit of interfaces and inheritance: polymorphism, or the ability to treat one object as the type of another!
Consider the standard variable declaration:
Dog myDog; //= new Dog();
The variable type of myDog
is Dog
, which means that variable can refer to any value (object) that is a Dog
.
Practice: Try the following declarations (note that some will not compile!)
Dog v1 = new Husky();
Husky v2 = new Dog();
Huggable v2 = new Husky();
Huggable v3 = new TeddyBear();
Husky v4 = new TeddyBear();
If the value (the thing on the right side) is an instance of the variable type (the type on the left side), then you have a valid declaration.
Even if you declare a variable Dog v1 = new Husky()
, the value in that object is a Husky
. If you call .bark()
on it, you’ll get the Husky
version of the method (Practice: try overriding the method to print out "barks like a Husky"
to see).
You can cast between types if you need to convert from one to another. As long as the value is a instance of the type you’re casting to, the operation will work fine.
Dog v1 = new Husky();
Husky v2 = (Husky)v1; //legal casting
The biggest benefit from polymorphism is abstraction. Consider:
ArrayList<Huggable> hugList = new ArrayList<Huggable>(); //a list of huggable things
hugList.add(new Husky()); //a Husky is Huggable
hugList.add(new TeddyBear()); //so are Teddybears!
//enhanced for loop ("foreach" loop)
//read: "for each Huggable in the hugList"
for(Huggable thing : hugList) {
thing.hug();
}
Practice: What happens if you run the above code? Because Huskies and Teddy Bears share the same behavior (interface
), we can treat them as a single “type”, and so put them both in a list. And because everything in the list supports the Huggable
interface, we can call .hug()
on each item in the list and we know they’ll have that method—they promised by implementing
the interface after all!
A.6 Abstract Methods and Classes
Take another look at the Huggable
interface you created. It contains a single method declaration… followed by a semicolon instead of a method body. This is an abstract method: in fact, you can add the abstract
keyword to this method declaration without changing anything (all methods are interfaces are implicitly abstract
, so it isn’t required):
public abstract void hug();
An abstract method is one that does not (yet) have a method body: it’s just the signature, but no actual implementation. It is “unfinished.” In order to instantiate a class (using the new
keyword), that class needs to be “finished” and provide implementations for all abstract methods—e.g., all the ones you’ve inherited from an interface. This is exactly how you’ve used interfaces
so far: it’s just another way of thinking about why you need to provide those methods.
If the abstract
keyword is implied for interfaces, what’s the point? Consider the Animal
class (which is a parent class for Dog
). The .speak()
method is “empty”; in order for it to do anything, the subclass needs to override it. And currently there is nothing to stop someone who is subclassing Animal
from forgetting to implement that method!
We can force the subclass to override this method by making the method abstract
: effectively, leaving it unfinished so that if the subclass (e.g., Dog
) wants to do anything, it must finish up the method. Practice: Make the Animal#speak()
method abstract
. What happens when you try and build the code?
If the Animal
class contains an unfinished (abstract
) method… then that class itself is unfinished, and Java requires us to mark it as such. We do this by declaring the class as abstract
in the class declaration :
public abstract class MyAbstractClass {...}
Practice: Make the Animal
class abstract
. You will need to provide an implementation of the .speak()
method in the Dog
class: try just having it call the .bark()
method (method composition for-the-win!).
Only abstract classes and interfaces
can contain abstract
methods. In addition, an abstract
class is unfinished, meaning it can’t be instantiated. Practice: Try to instantiate a new Animal()
. What happens? Abstract classes are great for containing “most” of a class, but making sure that it isn’t used without all the details provided. And if you think about it, we’d never want to ever instantiate a generic Animal
anyway—we’d instead make a Dog
or a Cat
or a Turtle
or something. All that the Animal
class is doing is acting as an abstraction for these other classes to allow them to share implementations (e.g., of a walk()
method).
- Abstract classes are a bit like “templates” for classes… which are themselves “templates” for objects.
A.7 Generics
Speaking of templates: think back to the ArrayList
class you’ve used in the past, and how you specified the “type” inside that List by using angle brackets (e.g., ArrayList<Dog>
). Those angle brackets indicate that ArrayList
is a generic class: a template for a class where a data type for that class is itself a variable.
Consider the GiftBox
class, representing a box containing a TeddyBear
. What changes would you need to make to this class so that it contains a Husky
instead of a TeddyBear
? What about if it contained a String
instead?
You should notice that the only difference between TeddyGiftBox
and HuskyGiftBox
and StringGiftBox
would be the variable type of the contents. So rather than needing to duplicate work and write the same code for every different type of gift we might want to give… we can use generics.
Generics let us specify a data type (e.g., what is currently TeddyBear
or String
) as a variable, which is set when we instantiate the class using the angle brackets (e.g., new GiftBox<TeddyBear>()
would create an object of the class with that type variable set to be TeddyBear
).
We specify generics by declaring the data type variable in the class declaration:
public class GiftBox<T> {...}
(T
is a common variable name, short for “Type”. Other options include E
for Elements in lists, K
for Keys and V
for Values in maps).
And then everywhere you would have put a datatype (e.g., TeddyBear
), you can just put the T
variable instead. This will be replace by an actual type at compile time.
- Warning: always use single-letter variable names for generic types! If you try to name it something like
String
(e.g.,public class GiftBox<String>
), then Java will interpret the wordString
to be that variable type, rather than refering to thejava.lang.String
class. This a lot like declaring a variableint Dog = 448
, and then callingDog.createPuppies()
.
Practice: Try to make the GiftBox
class generic and instantiate a new GiftBox<Husky>
A.8 Nested Classes
One last piece: we’ve been putting attributes and methods into classes… but we can also define additional classes inside a class! These are called nested or inner classes.
We’ll often nest “helper classes” inside a bigger class: for example, you may have put a Node
class inside a LinkedList
class:
public class LinkedList {
//nested class
public class Node {
private int data;
public Node(int data) {
this.data = data;
}
}
private Node start;
public LinkedList() {
this.start = new Node(448);
}
}
Or maybe we want to define a Smell
class inside the Dog
class to represent different smells, allowing us to talk about different Dog.Smell
objects. (And of course, the Dog.Smell
class would implement the Sniffable
interface…)
Nested classes we define are usually static
: meaning they belong to the class not to object instances of that class. This means that there is only one copy of that nested blueprint class in memory; it’s the equivalent to putting the class in a separate file, but nesting lets us keep them in the same place and provides a “namespacing” function (e.g., Dog.Smell
rather than just Smell
).
Non-static nested classes (or inner classes) on the other hand are defined for each object. This is important only if the behavior of that class is going to depend on the object in which it lives. This is a subtle point that we’ll see as we provide inner classes required by the Android framework.