This section lists the fundamental requirements of any MIDP application.
Application testing consists of more than technical testing. It is important that all general nontechnical issues are in condition as well. For example, the Intellectual Property Rights (IPR) must not be violated, and the form and content of the application must be generally acceptable, that is, not considered offensive by any parties.
Check that:
Intellectual Property Rights (IPR) are in satisfactory condition.
The content of the application is acceptable.
If the application supports a technology that offers a chance for pirated content, it must also offer a technique for licensed content (for example, an MP3 player must support a DRM technique for MP3s).
When creating applications, keep in mind that the speed of the application must not compromise the use and purpose of the application. This issue must be considered in the very early phases of application design. Depending on the type of application, remember that end users may use other applications concurrently. Therefore, excessive consumption of the device’s running power and memory should be avoided.
Make sure that the application does not cause any harm to its user, the system’s applications, or the data stored in the system. Harmful applications may be created accidentally, for example, if an application unnecessarily consumes a lot of the device’s processing power or fills up the device’s flash memory. Purposeless network communication must be avoided as well because it may create unnecessary expenses. Therefore, optimize the application by finding and correcting possible bottlenecks in the code, save only necessary data to the device’s flash memory, and keep communication to outside the device reasonable.
Check that:
The application speed does not compromise the use and purpose of the application.
The application does not consume the device’s running power and memory excessively.
The application does not cause any harm to the user, other applications, or data.
There are no bottlenecks in the code.
Only necessary data is saved into the flash memory.
Communication to and from the device/application is kept within reasonable limits.
Occasional tasks, exceptional tasks (for example, for emergency conditions), and tasks that cope with errors (for example, caused by using the interruption of network connection during the application’s use) must be considered and treated appropriately.
A mobile device is carried everywhere by its owners. Because of this fact, there is always a risk that the device will be lost. Therefore, no sensitive data should be stored in a mobile device without encryption. For example, the application must not save the credit card number to the device’s memory. However, if the nature of the application requires saving sensitive data, the data must be encrypted and hidden behind a password. In addition, the user must be informed clearly that sensitive data is stored into the device’s memory.
The application must not echo the input of sensitive data, for example,
pins and passwords. However, the chosen character may appear briefly in order
to confirm which character has been entered; however, the character must then
be masked. This can be done, for example, by using the TextField class.
Set the value of the input constraints parameter to TextField.PASSWORD,
as shown in the following example:
TextField textField = new TextField("Password", "", 10, TextField.PASSWORD);
Possible communication must be secure if sensitive information is transmitted between two end points or if a user may be charged for the result or consequences of a transaction. In such situations, use secure HTTP (HTTPS) or a secure socket connection. Both are supported from S60 2nd Edition and Series 40 2nd Edition onwards.
Encryption is also needed if sensitive data is transmitted via Bluetooth, Short Message Service (SMS), or Multimedia Message Service (MMS). The used Bluetooth stack provides security mechanisms and the Bluetooth implementation enables and disables security mechanisms. Encryption of SMS and MMS messages must be implemented by the developer.
The change in the security model for Mobile Information Device Profile (MIDP) 2.0 requires that user notifications are handled as the system has meant them to operate. For this reason those prompts cannot be interrupted.
Check that:
Sensitive data is encrypted before it is stored into the device.
Accessing Sensitive data requires a password.
The user is informed when sensitive data is stored into the device’s memory.
HTTPS or secure socket is used for secure communication.
SMS and MMS messaging as well as the Bluetooth connection are protected if needed.
A MIDlet must not be able to simulate security prompts and notifications to the user generated by the system or virtual machine.
For more information about security in MIDP, see the Security section of the Java Developer's Library.
The following UI-related requirements are important to keep in mind when designing with the various user interface APIs:
The devices and applications should be useful to users who are not necessarily experts in using computers.
The devices and applications should be useful in situations where the user cannot pay full attention to the application. For example, many phone-type devices are typically operated with one hand.
The form factors and UI concepts differ between devices, more so than in desktop systems For example, the display sizes vary, and the input devices do not always include pointing devices.
The applications that run on mobile devices should have UIs that are compatible to the native applications so that the user finds them easy to use.
Some notes about designing commands:
Avoid using too many commands, as it can make an application inconvenient to use since the user may need to scroll through an entire list just to select a command.
In the design phase, break the application into views and
then design the interactions between each view. Screens and Commands are
used to realize the actual tasks in views.
Think carefully about the order of Commands
in the menu. The most commonly used functionality should come first in the
list. Exit is always the last item in the menu and should always quit the
application.
Limit the length of the Command labels;
describe the command as clearly and concisely as possible. Put the most important
text at the start of the Command string because devices
crop text that is too long. For example, if you use "Write greeting,” as a Command name,
users see "Write…". on the screen
In S60 and Series 40 devices there are certain behavioural
rules that will already be familiar to users. For example, normally, if there
are two softkeys in the device (left and right) the right softkey provides
Back or Exit functionality. To design easy-to-use applications for these devices,
developers should respect these usability issues. In the MIDP implementation,
this is handled by Command mapping:
negative, backward actions are always mapped to the right softkey and positive
actions to the left softkey. Using the correct type of Commands
is important so that the implementation maps the Commands
as intended.
Remember that you can insert both short and long labels in
the Command(String shortLabel, String longLabel, int commandType,
int priority) constructor.
For more detailed, specific style guides on designing user interfaces for S60 and Series 40 devices, see the following documents, available from the Forum Nokia Web site:
For more information on working with Commands,
see section Command
handling.
For a good user experience it is important that the application installation works smoothly and easily. Be sure that all mandatory attributes and their values in the Java Application Descriptor (JAD) file are typed correctly and that they are in the right format. The attributes and values of the Java Archive (JAR) package’s manifest file must be correct as well. The two common IDEs (Eclipse, NetBeans) for MIDlet development include JAD tools.
For information on JAR and JAD files, see section Packaging MIDlets.
Check that:
All mandatory attributes and their values in the JAD file and the JAR package are correct.
The application descriptor contains the attributes specified in the MIDP 1.0 and MIDP 2.0/2.1 specifications.
Data reported in the JAD file is consistent with the information reported within the application.
The maximum JAR file size does not exceed the limit for downloadable applications so that the application can be installed over-the-air, too.