开发者应该在假定他们使用的所有类都是标准的之前，认识到目标设备的能力。应该保守地编写代码，来确保当一个API不可用时MIDlet仍然可以运行，且Mzblet可以采取合适的动作而不是异常地关闭应用程序。对开发者而言，更好的做法是，认识到设备上的库并在此新设备上发布应用程序前对应用程序的功能做出主动的决定。
然而，这使得开发者进退两难。他们仅仅使用目标设备以及适合其需求的操作吗？还是试图编写突破限制的代码来达到相同的结果？例如，是否可以改变屏幕的布局或菜单次序来适应一个较小的屏幕尺寸？
设备之间的不同之处的另一个方面是它们对多媒体的支持能力。例如，MIDP 2.0中的Media API（在第3章中讨论过）以最小的子集为多媒体提供了有限的能力。如果设备有很好的本地多媒体功能，例如，内置的摄像头和麦克风，那么，开发者应该适当地使用它们来操作多媒体数据。然而，目前，仅有一部分功能更强的手机（如Nokia 3650和Nokia 6600）完整地实现了Mobile Media API（JSR 135），它能绘画和记录媒体数据（如音频和视频重放）以及捕获照片。这个API使第5章讨论的Picture Puzzle MIDlet之类的应用程序能从内置的摄像头捕获一个图像，然后操作并存储以便将来使用。然而，这样的应用程序的实现显然被限制在这些支持MMAPI和拥有图像捕获功能（JSR 135的可选功能）的设备上。
