It has been a long time since I last posted to my journal. I’ve had a few hectic weeks as I’ve been working to finish the Android games course, I’ve started working with GH Hovagymian on his seesaw project, and had to prepare to share my second semester project from ITP at the Sony Wonderlab.

Today I am going to provide additional information regarding the structure of Android applications. A few weeks ago I wrote a post about the Java View class, which provides the basic building blocks for creating user interfaces. Today I will focus on providing an overview of the Java Activity and Thread classes.

Activities
An activity is a focused thing that an application can do. Almost all activities enable some type of interaction with the user. It is important to note that an activity is not an application. Applications are referred to a as a task in Android. Tasks usually contains multiple activities and often other components such as views, services, etc.

All activities live inside a window on the screen. Activities can be presented to the user as full-screen windows, as floating windows or embedded inside of another activity. There are two main methods that almost all  Activity subclasses will implement. These methods play crucial roles in the processes of setting up and leaving activities:

• onCreate(Bundle) is where you initialize your activity. Most importantly, here you will usually call setContentView(int) with a layout resource defining your UI, and using findViewById(int) to retrieve the widgets in that UI that you need to interact with programmatically.
• onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data).

Activities are managed via an activity stack. The most recent activity is always added to the top of the stack. The previous activities remain on the stack and can be reactivated simply by removing the new activity from the stack.

The startActivity(Intent) method starts new activities by placing them at the top of the activity stack. It takes a single argument, an Intent, which describes the activity to be executed.

Activities ultimately have three main different states: foreground activity, visible activity, background activity. Foreground activities live on top of the activity stack. Users are only able to interact directly with activities that are in this state.

Visible activities can be viewed by the user but they are not at the top of the stack. The user usually cannot interact directly with these activities until those that are located higher in the stack are removed from the stack.

Background activities are lower down in the stack and are not visible to the user. These are the first types of activities to be killed when an Android device needs additional space.

To switch between these various states seven activity methods can be implemented in an Activity subclass (two of which I already discussed above). Here is the full list:

• protected void onCreate(Bundle savedInstanceState);
• protected void onStart();
• protected void onRestart();
• protected void onResume();
• protected void onPause();
• protected void onStop();
• protected void onDestroy();

Here is a graphical representation of the Android Activity lifecyle, from the Android Developer website.

Activities can be killed by the OS at any time if they are not in the foreground state. The following methods can be called when an activities location in the stack is changed: onPause(), onStop(), and onDestroy() – however, only the onPause() is guaranteed to be called before a process is killed. Therefore, it is recommended that you should use onPause() to store any data when you are removing an activity from the foreground.

Threads
Threads enable android applications to run more than one activity at a time. Threads can be created in two ways: by extending the thread class and overriding its run() method; or creating a class the implements the runnable interface. In both cases, the start() method is called within an activity to actually execute the new Thread.

For my game I leveraged the code example provided by Matt. He created an extension of the Thread class called GameThread that includes the required methods (run, start, and stop). It also features a few functions that are meant to be overwritten by the main activity when it creates the thread during runtime. I will post the current code and screenshots of my game by early next week.

Here is an update regarding my android, currently titled The Maze. Last week I spent a lot of time porting my code from processing to java for android. I’m happy to report that I was able to make it work, for the most part at least (I still need to fix my buggy collision tracking).

To get my application to work I repurposed a lot of code from Matt’s android application example that he shared in class [add link here]. For the most part I had to copy the structure of Matt’s application. I leveraged his GameView, GameThread, GameElement, and Coods classes.

I was easily able to port over my data model classes (Shapes, Rectangles, Circles, and Maze) and activity class (Game). The updates included switching out calls to any Processing specific classes and methods, such as PVector and all draw methods, and changing the main application to be an extension of activity rather than the pApplet class.

I also used Matt’s code as the basis of my investigation into how android applications are structured. I was specifically interested in understanding the following concepts: activities, views, threads, handlers, listeners, and interfaces. I’ll start today with a brief overview regarding some of these concepts.

Over the next week I will write a series of posts that cover all of these topics. I will use the Android Developers Guide as my main source of information.

Tasks, Activities, Threads & Views

What users experience as an application android calls a task. Tasks include various components. Simple Android applications (or tasks) are usually composed of Views and Activities. There are other Android application components such as services, broadcast receivers, and content providers play important roles in more complex apps.

Android devices can run multiple tasks at once. Some application components are designed to run in the foreground, such as activities, while others run in the background, services, broadcast listeners and content providers.

Views define the visual interface of Android applications, while the activities usually define the processes that govern how foreground applications run, under the hood. An application can feature multiple different views, and many different activities. Within an application multiple activities can run simultaneously in separate processes called threads.

Our first major assignment for the Games with Android class was to create a simple game in Processing using only simple shapes such as circles and rectangles. Since Android applications are built using Java, we were tasked with creating our games in Eclipse. Here is a brief overview of the initial concept I selected, followed by a description of how I have structured my solution (along with the initial prototype), and the problems and improvements that I have planned for the next iteration.

The Maze Game
After considering racing games, obstacle games, and space invader-type games I choose to create a maze-based adventure. My initial idea, which has been implemented in a rough a prototype, is described below.

The player is trapped in a maze and must navigate his way to safety. He/she is represented by a circle that is always located in the middle of the screen. The movement of the player through the maze is governed by a set of limited dynamics.

Once the player starts moving he/she will move continuously. The direction of movement can only be changed by bumping the game piece into a column or wall. When the game piece hits a rectangular object it reverses direction. When the game piece hits a circular object it changes direction by 90-degrees.

The player can steer his game piece in a limited manner. The steering enables the game piece to stray slightly from its current trajectory slightly. It is controlled by using the arrow keys or mouse.

As you will notice if you attempt to play the game, it still needs a lot of work. The collision tracking is not working well, and the game mechanics also need to be worked on. More on the planned improvements below.

Developing the Game
I spent a good number of hours working on this project last week. I wanted to lay a solid foundation so that it would make it easier to port the game to Android, which is the next step in this assignment. With this in mind, I decided to design a basic class structure before beginning to write code.

The main consideration guiding my design was a desire to write object-oriented code that would facilitate debugging, porting, and future improvements to the game mechanics. The initial architecture evolved during the implementation process into the structure depicted in the diagram below.

In order to support multiple levels, I have created a function in the maze class that can read a text file made up of 0s, 1s, 2s, and 3s. It converts these text files into a maze made up of space, walls, round columns, and exits.

Planned Improvements
After playing the initial prototype I realized that I still have to do a lot of work. I also became even more excited about the possibilities of creating a good maze game. Here is a list of the planned improvements:

• Change controls: simplify the game controls and improve the visual feedback. I plan to change the game controls in one of the following ways: make it Pac Man-like, where the controls change the direction in which the game piece is moving; or keep it similar to the current design but make the game piece move up or down one full row when the controls are pressed.
• Change objective: rather than use small mazes with clear end points and time limits I am considering more open-ended possibilities. One idea that is loosely inspired by the 1980’s movie Tron, is to create a never ending maze that contains various different objects. When the player collides with one of these objects they would either gain benefits such as bonus points, special powers, or suffer punishment, such as death.
• Design updates: Overall I need to think about how to make this game more compelling form a visual perspective. For now I plan to stay within the bounds of the assignment (limiting my shapes to rectangles and circles). That said, I want to explore how I can use color palettes and other design attributes to make the game look more appealing.