Java Based Mobile Game

In order to begin developing any software for a mobile device it is important to consider all of the options in terms of the development environment. Currently the most common environments for mobile devices are native C++, .NET Compact Environment, J2ME (Java Micro Edition) and Python. Most devices have an operating system that uses C++ as the native language (Symbian and Windows Mobile for example) and therefore it is also possible to develop applications in the same language. Using such a language provides the most flexibility and power since access to the device’s native libraries is provided giving the developer much more control over the appearance of the application, allowing him to match it to that of the device’s own appearance. The downside to using this is that it is much more difficult to learn, especially with no prior experience with standard development in C++. The next best choice is to use the Java Micro Edition (J2ME), which is a watered down version of the standard edition Java, designed to work on devices with limited capabilities. Using J2ME provides the same benefits for mobile programming as J2SE provides for desktop applications. Porting applications between devices becomes easier since any device that supports applications written using J2ME provide the Java Virtual Machine for executing the byte code. With experience of the standard edition of Java, the transition to the micro edition is very easy and for this reason J2ME was chosen as the development environment for this project. 2.3.1 J2ME The Java Micro-Edition consists of a hierarchy of configurations, profiles and optional packages, each of which have progressed independently since the foundation of the language. There are two configurations that can be used by a device, CLDC (Connected Limited Device Configuration) and CDC (Connected Device Configuration). The CDC is aimed at devices with an external power supply that can therefore support more power consumption and therefore more processing, for example set-top television boxes use the CDC. The CLDC on the other hand is aimed at device with limited capabilities (such as smartphones). The CLDC defines the minimum set of libraries and Java technology components that are available to a device (CLDC Specification 2002). What this means is that the configuration defines the virtual machine that is used by the device (known as the kVM, kilobyte Virtual Machine). The CLDC provides some of the very basic classes that are available in the Java Standard Edition, such as java.lang.System and java.util.Vector. Sitting on top of the configuration is a profile that will vary from device to device to provide additional libraries such as for graphical user interfaces. The most common profile in use on smartphones is the Mobile Information Device Profile (MIDP), currently at version 2.0. Sun Microsystems provides a reference implementation of this profile, however it is up to each device manufacturer to provide its own version of the profile, with the only requirement that the API matches. This means that two devices may provide different implementations of the same class and therefore care must be taken to ensure that an application acts the same way on both devices even though it only uses the classes from the MIDP. Most importantly for this project, the MIDP 2.0 provides a collection of UI classes that can be used to create a user interface. These classes include highlevel UI components (such as Forms and Lists) which provide a fixed functionality so that the developer doesn’t have to implement complicated features such as painting and traversing items. Low-level components are also provided to give the developer the flexibility of creating more powerful user interfaces; however these are more complicated since the developer is now required to implement his own painting method and must also control the interaction at the level of individual button presses. All of these classes are provided in the javax.microedition.lcdui package. Besides the user interface capabilities the MIDP also provides a very useful package for storing and retrieving data from the phone’s persistent storage

without requiring access to the file system (which is particularly useful when it is not known if all target devices will provide access to the file system). The RecordStore class from the javax.microedition.rms allows the developer to save any information to a numbered record by simply converting the data to an array of bytes. The data can be easily read back out of the record in byte array form by addressing the desired ID. In order to create an application using J2ME the developer must create a MIDlet (the mobile equivalent of an applet, which runs in a web browser). Just like an applet, a MIDlet has a fixed lifecycle as shown in Figure 4. When a MIDlet is started it first enters the ‘Paused’ state, where the startApp() method is called automatically. Once the MIDlet is running it remains in the ‘Active’ state until a request is made to either pause the application or to destroy it. The request to pause the app may come from device itself, for example if there is an incoming phone call and the application must be interrupted. It is therefore possible to ensure that a certain block of code is always executed whenever the application is interrupted, which can be very important when developing a game. In order to end the application a request must be made to destroy the application, which again provides a mechanism for ensuring that specific code is executed before the application ends, such as closing connections. Obfuscation Given the limited resources of a mobile device one concern is for the size of the final JAR file for the application. Some older devices limit the JAR file to a maximum size of 64kB however most modern devices have no such limit. Whether or not the device imposes a limit on the size it is still advisable to minimise the final size since the most common way to distribute applications is over the internet and most end users will want to keep their internet connection costs to a minimum. Obfuscation in J2ME is the process of reducing the size of class files by renaming all variables in the code to a much shorter string. Another effect of obfuscation is that classes are removed from their packages and placed in one common package. The advantage of this is to reduce the size of the files, but it also has the added benefit in that it makes decompilation of class files much harder since the code will be almost unreadable, thus discouraging reverse engineering. Preverification In J2ME, as in the standard edition of Java, class files must be verified by the JVM before they can be executed. The standard JVM performs this at runtime by following a strict process involving various checks of the byte code and the code to be executed to confirm that the class file is valid. Due to the number of steps involved in verifying the files it is not a good idea to do this on a device with limited capabilities. Preverification in J2ME is the process of verifying the byte code at compile time (on a more powerful machine) and annotating the class file so that the verification of the files at runtime can skip certain steps of the process and complete the verification much quicker. Requirements In software development there are three common reasons for the failure of projects: building the system for the wrong reason, building the wrong system and building the system wrong (Gray 2007). Building the system for the wrong reason refers to failing to assess whether or not the system is actually needed and the solution would be to perform a feasibility study, which, for this project, came in the form of the project proposal. Building the system wrong refers to failing to

follow a set process in order to ensure that the system is built correctly and any failures are tracked to ensure they don’t happen again and there will be more on this in the design and implementation chapters later. Building the wrong system is the result of failing to assess the needs of the potential users, future users and any current systems whilst designing the new system. The key to ensuring that the correct system is built is performing a thorough analysis of the domain in which the system is to operate, which includes performing requirements capture. Requirements capture can come in many forms, from consulting with the potential users to find out what they expect from the system, to analysing current systems and procedures that may need to be incorporated into or work in conjunction with the new system. Bennett et al (2006) suggest that analysts use five main fact finding techniques to investigate the requirements of a new system: background reading, interviewing, observation, document sampling and questionnaires. Each of these techniques has advantages and disadvantages and in many cases the project itself will dictate which, if any, may be utilised. UI A large part of the challenge in developing an application for a mobile device is in creating a user interface that not only allows the user to achieve his goals, but that also fits onto the limited space available on the device. J2ME does not provide the same support for GUI development as its standard edition counterpart, such as layout managers or even windows. Instead the mobile edition provides very basic support through the ‘lcdui’ package of the MIDP. This support comes in two forms: high-level components and direct low-level access to the pixels on the screen. The high level components are sufficient for making very basic interfaces, such as lists and forms for data entry. However in order to make a more complicated interface, such as what was required for this project, it was necessary to look at the low-level support. This meant not only painting the entire screen contents using the standard Graphics package, but also creating custom interaction objects, such as buttons and menus (since the high level and low level components cannot be combined on one screen). The first step in designing the user interface was to develop a reusable pattern for creating a number of different types of interaction objects. It had to be possible to create a screen with multiple buttons that would each have its own position and appearance, but at the same time could be grouped together to achieve the desired traversal whenever the user uses the phone’s navigation keys. The resulting design is shown in Figure 8. First of all, sections of the Canvas (the low-level class that provides direct access to the screen’s pixels) are defined by a CanvasArea object. Each CanvasArea object can provide its own method for painting to the screen and thus customise its appearance. Special ‘paint’ methods are used to allow the implementation to specify how the component should be drawn (e.g. if it is currently in focus or highlighted).