Q: How do I retrieve the phone number from my midlet?
You would have to use the JSR 253 - Mobile Telephony API which allows you to have a fairly good set of call-related funcionality, so it's possible that this API will also provide a way to let you know what's your phones's number. No Nokia devices currently support JSR 253.
There are some possible workarounds:
- When the user first downloads the application, have a server-side app such as a Java servlet or PHP script that retrieves the phone number from the HTTP header, and set it as a property in a dynamically-generated JAD file. This way, when your midlet is running, it can check the phone number using getAppProperty() method from MIDlet class. This approach will only work if the device is accessing the server-side application using a WAP access point, however. This happens because in this type of access point, an HTTP header containing the MSISDN (phone number) is added to the HTTP request that will be forwarded to your application, so you can retrieve it.
- If the target handset supports the Wireless Messaging API, you can have your application register an SMS connection, using PushRegistry, with a non-standard port. When the user first starts the application, generate some random data and send it to the phone number the user will input on a text field. If the phone number is correct, than you’ll receive the message in a few seconds on the connection you've registered. You can then check the data to see if it matches the data you generated earlier, and if it does, get the sender phone number using
method and save it to RMS. Note that the default security setting for Wireless Messaging API is "Ask Always", so this will cause security prompts if the midlet is not signed and/or the application security settings are not configured correctly.
- If you are using an S60 device, you can write a Symbian C++ application that retrieves the phone number and opens a server socket on 127.0.0.1. The midlet then connects to this localhost socket and retrieves that information. There are some drawbacks to this approach: Your C++ application has to be started on boot, the method used to retrieve the phone number is not portable (if you’re getting only the IMEI code, not the phone number, then it's portable); third, it depends on a C++ application, which greatly increases complexity by itself. There's a project called [URL ="http://www.midpjni.com/"]MIDP JNI[/URL] that uses this "bridge" approach to bring native functionality to midlets, so you can retrieve information that otherwise would be only available to C++ applications, such as network and device properties.
Q: How do I get the IMEI of a phone from my midlet?
From the MIDP: System Properties (with Example) v1.2 document:
You can use the "com.nokia.mid.imei" system property. This works in Series 40 3rd Edition devices only, excluding Nokia 6270 and 6111. The MIDlet must be signed, otherwise this value is NULL. For all other Series 40 models, there's no way to access the IMEI number.
Some S60 devices such as E61 also support this system property. In most S60 devices, however, you have to use the same bridge approach mentioned above.
Q: Will my Java ME application run unmodified across all platforms?
Nokia adopts a platform approach on its products. It means that if you write an application for a given platform, it is supposed to run mostly unmodified on all other devices from the same platform. Currently there are three platforms: Series 40, S60 and Series 80.
There are several degrees of portability, however:
- If you use only MIDP 1.0 features and LCDUI components (excluding Canvas), your application will run unmodified on all Nokia devices which support Java.
- If you use only MIDP 2.0 features and LCDUI components (excluding Canvas), your application will run unmodified on all Nokia devices which support MIDP 2.0 profile.
- If you use some of the optional APIs, you'll have to adapt your application according to one of the cases below:
- Source code-level differences: Those are found when you are using a certain API package (such as FileConnection or Bluetooth) that is supported in a device or platform, but not in other devices. For example, Bluetooth API (JSR 82) is supported on Nokia 6230i, but not on Nokia 6101. To overcome these differences, you'll have to produce different versions of your midlet for each handset (or platform), according to the availability of the given API. In order to make this easier, there are several software packages that can help you produce multiple versions of your source code; two of the most popular use C++-like pre-processor macros: Antenna and NetBeans Mobility Pack.
- Runtime-level differences: Those are found when you're using a certain API package that has runtime optional components. This happens mainly in Mobile Media API, which has a large set of optional features that may or may not be implemented by a device, but if those are indeed implemented, there are no changes in the source code, only in runtime behavior. For example, both 6230 and 6681 support Mobile Media API, therefore there are no source code-level differences here. However, 6230 does not support capturing pictures with the device's camera, neither capturing and recording audio, whilst 6681 supports both operations. In order to make your application run in both devices, you'll need to perform runtime checks, usually using system properties, to provide the best behavior for a good user experience.
- Hardware-level differences: Those refer mostly to the screen size and resolution. For example, 6230i has a 208x208 display, while E61 has a 320x240 landscape-oriented display. As I said before, if you're using only LCDUI classes, you don't need to worry about that, but if you are using screen size-dependent graphics, you'll have to either have multiple versions of your midlet or to perform runtime checks and adjusting your drawing functions according to the screen size.
Q: Can I acces DRM-protected content using Mobile Media API?
On S60 3rd. Edition devices, there is some DRM support. You can play a DRM-protected file, using the following syntax:
Player p = Manager.createPlayer("file:///C:/Path/To/File.dcf");
Q: I signed my midlet with a Verisign/Thawte and it's not installing on device <i>X</i>, what's wrong with it?
The root certificate for your certificate is either 1) not present in the root CA store of the device 2) not enabled to authorize and authenticate software installation.
You can check whether this is the case this way:
On Series 40 devices, go to "Menu/Services/Settings/Security Settings/Authority certificates/Certificate list". Check if the root certificate is there and, if so, it's enabled for application authentication, choosing "Options/Select use". Older S40 devices have the certificates under Services.
On S60 devices, go to "Tools/Settings/Security/Certificate management/Authority". To check if a given certificate is enabled for application authentication, go to "Options/Trust Settings".
Q: I signed my midlet and I'm still getting the security prompts when trying to access protected APIs.
First, you need to check if your application has the proper permissions for the operations you're trying to perform:
On Series 40, go to "Menu/Applications/Collection/Select Application/". Highlight your application's name, go to "Options/Application access", and configure the proper permissions for the actions your app wants to perform.</li>
On S60, go to "Tools/App. Manager/". Highlight your application's name, go to "Options/Suite Settings", and configure the proper permissions for the actions your app wants to perform.</li>
Please note that the default access rights are not ever the same as max access rights. The user has to manually change them.
If the permissions are correctly configured and you still get the security prompts, it may be that your phone has a firmware version customized for a given operator, which has the option of customizing the security domains policy, not allowing, for example, a midlet to connect to the network without user confirmation, or its access to the filesystem, using FileConnection API. This is unusual behavior, because in most cases like this the installation will simply fail.
In that case, you have to contact your operator, and ask them about their developer programs and partnering agreements, usually available only for companies, not individuals. Partnering with the operator makes it possible to sign your midlet with their certificate, which would put your midlet in the "Operator" security domain, giving it looser permission settings.
Why can't I have my midlet auto-started with PushRegistry without a security prompt being shown, even though the application is signed?
Please check this Forum Nokia Tech Library entry for details.