Whether you are developing an enterprise-wide application or a simple cell phone game, the cycle of debugging and testing proceeds similarly — through successive rounds. Wireless consumers tend to be less technically oriented than desktop computer users and will be less tolerant when programs fail to work properly. Thorough debugging and testing of wireless applications is extremely important.
You should also note that there might be some special issues with devices from or before a certain platform series. For this reason, please read the possible Known Issues or other similar documents carefully, and test the special issues correspondingly.
Testing on an emulator
Each platform SDK includes a device emulator that enables you to test MIDlets on a PC and see it run as it would on a device. Generally, MIDlets behave in a similar manner on all devices based on the same platform edition and feature pack. Ultimately, of course, your applications should be tested on the actual devices it is aimed to run on.
From S60 5th Edition onwards, many devices feature touch screens. This is reflected in the emulator by considering the mouse clicks on the emulator screen as stylus taps.
Alternative ways for testing on devices
Since maintaining an up-to-date collection of current devices would be prohibitively expensive, Forum Nokia provides a number of services to help you access the latest devices for testing purposes.
By joining the Forum Nokia Launchpad developer program, you receive access to the Discounted Devices Program to purchase Nokia devices for development and testing purposes.
You can also use the Remote Device Access (RDA) and Forum Nokia Virtual Developer Lab services to test your application on a range of devices over the Internet. RDA is a free service that provides access to Nokia devices based on the Symbian platform. Forum Nokia Virtual Developer Lab is a subscription-based service that provides access to a range of Series 40 and Symbian devices.
Three broad categories of errors can occur in your code: compile errors, runtime errors, and logic errors.
Compile errors appear at the time your source code is compiled. Syntax errors commonly appear at compile time.
A runtime error causes the program to fail or terminate prematurely. Runtime errors result from problems that will not occur until the code is being executed. For example, trying to open a file that does not exist, or attempting to divide by zero, are errors that cannot be caught at compile time.
In a typical development environment, when your program throws an exception, a debugger will print a stack trace in the Console output view, input view, and error view. You then double-click a line of the stack trace to go directly to the line of source code listed in the trace. As execution proceeds, you monitor the program's behavior step by step, until the error is produced or the program fails. At that point, you fix the bugs, recompile the program, and resume testing.
A logic error is a non-fatal problem with the design or implementation of your application. Although the program statements may not throw exceptions, they do not produce the results you intended when you wrote the code. For example, logic errors can occur when variables contain incorrect values, when graphic images don't look right, or when output is simply incorrect. Memory leaks and attempting to insert more elements into an array than were allocated to the array can also result from logic errors.
A debugger can help locate logic errors by allowing you to monitor the values of program variables and data objects as the program executes. Modifying data values during a debugging session is a good way to test hypothetical bug fixes.
Note: Enabling optional compiler warnings in your IDE allows you to make full use of its debugging features. However, this can considerably slow down the process.
This section lists the most typical errors that developers tend to encounter in Java ME software development.
Pay particular attention to these issues and make sure that they have been resolved in your application.
The application does not pause during interrupting operations, for example, an incoming phone call. (This is not necessary for all kinds of applications.)
The application cannot be downloaded over the air/installation does not work.
The softkey labels are not in line with Nokia UI style.
The Instructions section is not complete; it does not include the purpose of the application, use of keys, or how to use the application and its functions.
Proceeding from the startup or other screen takes more than five seconds and the user receives no guidance about what to do next.
The application includes grammatical and spelling mistakes.
Settings are not saved when the application is closed.
Error messages are incomplete or do not provide sufficient information to the user.
Application errors due to lack of memory or exceptions are not correctly handled.
The application's dialogs, interaction, controls, softkey labels, UI layout, and so on, are inconsistent.
The application’s name and version number are inconsistent or faulty.
Rapid pushing of certain buttons creates difficulties in the application leading to crashes or jams.
For more information about testing on Series 40 and Symbian devices, see the following sections: