Programs with multiple threads can have problems, like the threads of a story in which if proper synchronization does not occur, then things go wrong. What if our soldier went into battle before the battle or war even existed? Weird.

What if we have a variable, int x, that represents a key piece of data that three threads of our program use. What happens if one thread gets slightly ahead of itself and makes the data "wrong" for the other two? This problem is the problem of correctness caused by multiple threads racing to completion obliviously—because after all, they are just dumb code.

The problem of correctness can be solved by close oversight of the threads and locking, locking meaning temporarily preventing execution in one thread to be sure things are working in a synchronized manner. This is kind of like preventing a soldier from boarding a ship to war until the ship has actually docked and the gang plank has been lowered, avoiding an embarrassing splash.

The other problem with programs with multiple threads is the problem of deadlock, where one or more threads become locked waiting for the right moment to access int x, but that moment never comes, and eventually the entire program grinds to a halt.

You might have noticed that it was the solution to the first problem (correctness) that is the cause of the second problem (deadlock). Now, consider all we have just been discussing and mix it in with the Android activity lifecycle, and it's possible you start to feel a little nauseous with the complexity.

Fortunately, the problem has been solved for us. Just as we use the Activity class and override its methods to interact with the lifecycle, we can also use other classes to create and manage our threads. Just as with Activity, we only need to know how to use them not how they work.

"So, why tell me all this stuff about threads when I didn't need to know?" you rightly ask. Simply because we will be writing code that looks different and is structured in an unfamiliar manner, if we can:

Then, we will have no sweat writing our Java code to create and work within our threads. There are a few different Android classes that handle threads. Different thread classes work best in different situations.

All we need to remember is that we will be writing parts of our program that will run at almost the same time as each other.

Let's take a glimpse at what our thread code will look like:

We can declare an object of the type Thread like this:

Thread gameThread;

Initialize and start it like this:

gameThread = new Thread(this);
gameThread.start();

We can then use the Java @override keyword to change what happens when the operating system allows our gameThread object to run its code. Within the overridden run method, we call two methods that we will write in our Pong game. The first is update, which is where all our calculations, artificial intelligence, and collision detection will go, and then draw, where perhaps unsurprisingly, we will draw all our graphics:

@override
public void run() {
 
  // Update the game world based on
  // user input, physics,
  // collision detection and artificial intelligence
  update();
 
  // Draw all the game objects in their updated locations
  draw();
 
}

When necessary, we can also stop our thread like this:

gameThread.join();

Now, everything that is in the run method is executing in a separate thread, leaving the default or UI thread to listen for touches and system events. We will see how the two threads communicate with each other in the Pong project.

Note that exactly where all these parts of the code will go within our game has not been explained, but it is so much easier to actually show you in a real project.

When we build our retro game, we will see how simple it is to have two sets of code running apparently simultaneously.

So, how do we draw things?