Tips for Getting Your MIDP Application JavaVerified

Passing JavaVerified testing is not difficult, but the testing process is thorough. This article lists some tips I picked up while sending several builds through the JavaVerified process.

JavaVerified is not for everyone. It will not make your mobile application run on every handset out there, and it can be tedious and very expensive if you have many builds to certify, or if your builds are updated frequently. See my earlier post on JavaVerified to determine if testing is right for your application, and to see the steps in the testing process.

Test Categories

• Application Stability
• Application Launch
• User Interface
• Localization
• Functionality
• Connectivity
• Personal Information Management
• Security

General Recommendation: Leverage the Unified Testing Criteria

All you really need to know to pass testing is in this document. Read the tests thoroughly, and do your own in-house testing using this document as a guide. Don’t submit your application until you pass each test in the document.

“Unified Testing Criteria (UTC) 2.0 for Java™ Technology-based Applications for Mobile Devices”

Application Stability

If this one isn’t obvious, you might have been a liberal arts major. Make sure your application doesn’t lock up or crash at any time during operation.

Application Launch

• Your application must installable via OTA provisioning.
• Once installed, the application icon should ideally be displayed, but any means to start the application is acceptable.
• After launching the application, the main menu should be displayed within 15 seconds, and a splash screen should be displayed until the menu is ready.

User Interface

• Make sure you have a “Help,” “About,” and “Exit” option from your application’s main menu.
• The information in the About section must match the information in the JAD. List the developer name, the application name, and the exact application version.
• Make sure that the Help section includes a description of each screen (or add a help option to each screen), and list all available key presses. I failed testing on one build because I used number shortcuts in menus (e.g. “4” opens the fourth menu item) without explicitly stating their availability in the help section. If a key does anything, make sure it’s listed.
• Use the full canvas available on the phone.
• Make sure that all menu items are consistently placed. For example, if the back button is assigned to the right soft key in one screen, it should be assigned to the right soft key in all screens. Forget usability. Even if assigning a different command to the right soft key would make immensely more sense, and save the user 20 key presses, don’t do it. The test houses are not permitted to be subjective in their interpretation of the test criteria.
• All language should be simple and clear, including error messages.
• Watch out for minor UI inconsistencies, like overlapping text, colors too similar to each other, etc.

Localization

Make sure your translations are accurate, and there are no misspellings throughout your application.

Functionality

• These are also rather easy to address. If your application does something, make sure it’s mentioned in the help section, or easily inferred from the application screens. For example, especially if those actions result in data transfer.
• Make sure you implement pauseApp() in your MIDlet. Pause and resume should be available in applications where interaction is required (e.g. games).
• Your application should pause and restore before/after interruptions like incoming phone calls, Bluetooth connections, text messages. The easiest way to do this is to implement hideNotify() and showNotify().
• Keep your application responsive. Anything taking more than a few seconds should be placed in a separate thread and gauges should appear within one second.
• Don’t delete any data without first prompting the user. Or, offer an undo of delete operations.

Connectivity

• Catch all errors and use descriptive error messages. If an IOException is caught, respond accordingly. If no exception is thrown, but you don’t get an HttpConnection.HTTP_OK response code, respond accordingly. I’ve had success using this strategy:

• Catch ConnectionNotFoundException. Respond with “network not found” error. Ask user to check network settings.
• Catch IOException. Respond with “network error” message, and prompt for a reconnection attempt.
• Catch Exceptions. Respond with “generic error” message, and prompt for a reconnection attempt.
• If response code is not HttpConnection.HTTP_OK, respond with application-specific error message and prompt for another attempt.

• Don’t let the application attempt to connect forever. I’ve had success passing Verified by starting a Timer when I make connection requests. After 30 seconds, I close the network thread, reset the timer, and return an alert to the user.
• Offer to attempt a reconnection in the event of a network failure.
• Close all connections in a finally clause. Check for open connections when exiting the application.

Personal Information Management

Warn before deleting any information, or offer an undo function.

Security

• If you request any sensitive data from the user, encrypt it when sending or receiving.
• Protect passwords entered on the device. For example, they should never be available in clear text, or selectable from a recent words list.

Conclusion

The most important thing to remember is that the test houses try to be as objective as possible, and they do this by adhering to the letter of the Unified Testing Criteria, so know them well, and you should have no problems certifying your application.