Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

(Difference between revisions)

Java ME FAQ

From Wiki
Jump to: navigation, search
dcrocha (Talk | contribs)
hamishwillee (Talk | contribs)
m (Hamishwillee - Fix categories)
 
(25 intermediate revisions by 9 users not shown)
Line 1: Line 1:
= Work in progress [[User:Dcrocha|dcrocha]] 19:26, 30 October 2007 (EET)=
+
[[Category:Debugging on Java ME]][[Category:FAQ]]
 +
{{ArticleMetaData <!-- v1.1 -->
 +
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Qt SDK 1.1.4]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20071030
 +
|author= [[User:Dcrocha]]
 +
}}
  
This article contains the most frequently asked questions on the  [http://discussion.forum.nokia.com/forum/showthread.php?t=85660 Java Discussion Boards]. Many important pieces of information that can help you solve the most basic/recurrent problems when developing in Java ME.
 
  
 +
This article contains the most frequently asked questions on the [http://www.developer.nokia.com/Community/Discussion/showthread.php?85660-FAQ-%28General-issues%29-for-Java-discussion-boards-read-this-before-posting Java Discussion Boards]. Many important pieces of information that can help you solve the most basic/recurrent problems when developing in Java ME.
  
'''Q: I cannot get this midlet of mine working? Please HELP ME! Urgent!'''
+
==I cannot get this midlet of mine working? Please HELP ME! Urgent!==
  
First check the Javadocs for that API (those are included in all SDK installations). There are also sample midlets and documentation available on Forum Nokia Web site ([http://www.forum.nokia.com/main/resources/technologies/java/documentation/index.html]). And you can find wealth of information in here (Discussion Boards at [http://discussion.forum.nokia.com]) and on Sun’s JavaME web site ([http://java.sun.com/javame]). And finally check also Forum Nokia Technical Library at [http://www.forum.nokia.com/document/Forum_Nokia_Technical_Library/index.html], which you can also download to your computer).
+
First check the Javadocs for that API (those are included in all SDK installations). There are also sample midlets and documentation available on Nokia Developer website ([http://www.developer.nokia.com/Develop/]). And you can find wealth of information in here (Discussion Boards at [http://www.developer.nokia.com/Community/Discussion/]) and on Sun’s JavaME web site ([http://www.oracle.com/technetwork/java/javame/index.html]).
  
 
If you are still having problems, please include relevant parts of the source code in your post, and also specify which devices you are working on. If the problem has something to do with your desktop computer, please add OS information for your desktop computer too. In some cases the firmware version of the device might provide valuable information to the readers (*#0000# in the idle screen).
 
If you are still having problems, please include relevant parts of the source code in your post, and also specify which devices you are working on. If the problem has something to do with your desktop computer, please add OS information for your desktop computer too. In some cases the firmware version of the device might provide valuable information to the readers (*#0000# in the idle screen).
  
'''Q: What tools do I need to create my first midlet?'''
+
==What tools do I need to create my first midlet?==
  
 
You can write your code in your favorite text editor or you could use an IDE (Integrated Development Environment), such as Eclipse, Netbeans, or JBuilder.
 
You can write your code in your favorite text editor or you could use an IDE (Integrated Development Environment), such as Eclipse, Netbeans, or JBuilder.
Line 17: Line 39:
 
When you use Sun’s Wireless Toolkit, NetBeans with Mobility pack, and other mobile Java development environments, you should remember that if you are developing your midlet for Nokia devices, it is advisable to test the application with Nokia emulators (as well as on real devices), as the generic emulators behave differently from Nokia emulators and Nokia devices.
 
When you use Sun’s Wireless Toolkit, NetBeans with Mobility pack, and other mobile Java development environments, you should remember that if you are developing your midlet for Nokia devices, it is advisable to test the application with Nokia emulators (as well as on real devices), as the generic emulators behave differently from Nokia emulators and Nokia devices.
  
'''Q: I need to download Nokia Development Suite X.X for J2ME. Where can I find it?'''
+
{{Nokia SDK for Java}}
  
NDS was replaced with Carbide.j which has been also removed from the tools portfolio. Please use Eclipse ME or NetBeans with Mobility Pack for your MIDlet development
+
== I need to download Nokia Development Suite X.X for J2ME. Where can I find it? ==
  
'''Q: How can I transfer my midlet to the handset?'''
+
NDS was replaced with [[Carbide.j]], which was in its turn removed from Nokia's tools portfolio in 2007.  Please use [[Eclipse]] + [[EclipseME]] or [[NetBeans]] + [[NetBeans|Mobility Pack]] for your MIDlet development.  See [[Getting started with Java ME]] and [[Installing Java ME development tools for S60]].
  
On S60 phones and newer Series 40 phones: Send the JAR and JAD files over Bluetooth from the File Browser.
+
==How can I transfer my midlet to the handset?==
  
On older Series 40 phones, you need to use PC Suite. PC Suite works well also with S60 and newer Series 40 phones.
+
On Symbian phones and newer Series 40 phones: Send the JAR and JAD files over Bluetooth from the File Browser.
 +
 
 +
On older Series 40 phones, you need to use PC Suite. PC Suite works well also with Symbian and newer Series 40 phones.
  
 
An advanced option is to store the JAR and JAD files on a Web server and connect to the JAD file using the phone browser. Make sure the mime types are set correctly on the server (“application/java-archive” for jar and “text/vnd.sun.j2me.app-descriptor” for jad).
 
An advanced option is to store the JAR and JAD files on a Web server and connect to the JAD file using the phone browser. Make sure the mime types are set correctly on the server (“application/java-archive” for jar and “text/vnd.sun.j2me.app-descriptor” for jad).
  
'''Q: How can I debug my midlet?'''
+
==How can I debug my midlet?==
  
 
All SDKs contain an emulator, which basically emulates the phone Java environment and the set of APIs included in that SDK on your PC. When you run your midlet in the emulator, you can see diagnostic information (like printStackTrace() output) in the IDE's console screen.
 
All SDKs contain an emulator, which basically emulates the phone Java environment and the set of APIs included in that SDK on your PC. When you run your midlet in the emulator, you can see diagnostic information (like printStackTrace() output) in the IDE's console screen.
Line 35: Line 59:
 
You should always test your application on a real device as some of the phone capabilities cannot be emulated on PC. Also there are subtle differences in the phone implementations.
 
You should always test your application on a real device as some of the phone capabilities cannot be emulated on PC. Also there are subtle differences in the phone implementations.
  
'''Q: Why are there so many SDKs, can’t I just use one to code and test my midlet?'''
+
==Why are there so many SDKs, can’t I just use one to code and test my midlet?==
 +
 
 +
{{Nokia SDK for Java}}
  
Different phones have different set of APIs, and the SDKs provide a compatible set of APIs for each device (and an emulator to test the midlets on). Nokia devices are based on platforms (like Series 40, S60, and Series 80), editions (1st, 2nd, and 3rd edition so far), and Feature Packs. Each device belongs to one of platform edition / feature pack combination.
+
Different phones have different set of APIs, and the SDKs provide a compatible set of APIs for each device (and an emulator to test the midlets on). Nokia devices are based on platforms (like Series 40, Symbian , and Series 80), editions (1st, 2nd, and 3rd edition so far), and Feature Packs. Each device belongs to one of platform edition / feature pack combination.
  
 
For example if you are developing an application for N70 smart phone, which is a S60 2nd Edition Feature Pack 3 device, you should be using that specific SDK to develop the midlet on. If you are using an earlier SDK version, some of the APIs might be missing. If you are using a newer SDK version, you might end up using features which are not available on N70. Additionally the emulator of the S60 2nd Ed FP3 SDK provides the closest emulation of that specific device of all the available emulators.
 
For example if you are developing an application for N70 smart phone, which is a S60 2nd Edition Feature Pack 3 device, you should be using that specific SDK to develop the midlet on. If you are using an earlier SDK version, some of the APIs might be missing. If you are using a newer SDK version, you might end up using features which are not available on N70. Additionally the emulator of the S60 2nd Ed FP3 SDK provides the closest emulation of that specific device of all the available emulators.
  
'''Q: What are the prototype SDKs?'''
+
==Does my handset support API xyz?==
  
Prototype SDKs are meant for developers, who are targeting future devices. The prototype SDK contains a number of APIs which are not yet implemented on any device, but which will be available on future devices. With the Prototype SDK the developer can start developing his/her application before the devices are launched, so the midlet can be distributed to the marketplace earlier.
+
Please check the device specifications at http://www.developer.nokia.com/Devices/
  
The emulators of these Prototype SDKs are based on reference implementation of future devices, not on real device / platform software like in Platform SDKs. Hence the implementation of UI and new APIs might not be exactly the same as on real devices. Hence, always test your application on final SDKs and on real devices.
+
You can also use a shortcut URL – add the phone model number in the end of the previous URL. For example if you want to see the specifications of Nokia 6131 phone you can go to this URL http://www.developer.nokia.com/Devices/Device_specifications/6131/
  
'''Q: Does my handset support API xyz?'''
+
Or if you are looking for API availability on devices from other manufacturers, you can also check the J2ME Polish Device Database at [http://www.enough.de/products/j2me-polish/].
  
Please check the device specifications at http://www.forum.nokia.com/devices
+
For most of the newer APIs it is also possible to query the phone during execution time if a certain API exists. This is done using System.getProperty() method call. Please check the correct query strings (for example microedition.pim.version for PIM API) from this document [http://www.developer.nokia.com/info/sw.nokia.com/id/37086440-dcce-4fb4-aa3e-8d8c16d62b33/MIDP_System_Properties_v1_2_en.zip.html]
  
You can also use a shortcut URL – add the phone model number in the end of the previous URL. For example if you want to see the specifications of Nokia 6131 phone you can go to this URL http://www.forum.nokia.com/devices/6131
+
A special case is MMAPI, which contains a lot of optional features. For example not all phones are able to use the camera. You can check how the MMAPI is supported on various Nokia devices from this doc [http://www.developer.nokia.com/info/sw.nokia.com/id/bc00e4ce-7df3-4527-962c-d39843a808d0/MIDP_Mobile_Media_API_Support_In_Nokia_Devices_v1_0_en.pdf.html  MMAPI Support In Nokia Devices]
  
Or if you are looking for API availability on devices from other manufacturers, you can also check the J2ME Polish Device Database at [http://j2mepolish.org/devices-overview.html] or Tastephone MIDP phone info at [http://www.club-java.com/TastePhone/J2ME/MIDP_mobile.jsp]
+
==My phone does not seem to have support for API xyz. Can it be added on the phone?==
 
+
For most of the newer APIs it is also possible to query the phone during execution time if a certain API exists. This is done using System.getProperty() method call. Please check the correct query strings (for example microedition.pim.version for PIM API) from this document [http://www.forum.nokia.com/info/sw.nokia.com/id/37086440-dcce-4fb4-aa3e-8d8c16d62b33/MIDP_System_Properties_v1_2_en.zip.html]
+
 
+
A special case is MMAPI, which contains a lot of optional features. For example not all phones are able to use the camera. You can check how the MMAPI is supported on various Nokia devices from this doc [http://forum.nokia.com/info/sw.nokia.com/id/bc00e4ce-7df3-4527-962c-d39843a808d0/MIDP_Mobile_Media_API_Support_In_Nokia_Devices_v1_0_en.pdf.html  MMAPI Support In Nokia Devices]
+
 
+
'''Q: My phone does not seem to have support for API xyz. Can it be added on the phone?'''
+
  
 
Short answer: No.
 
Short answer: No.
Line 65: Line 85:
 
Longer answer: No, but if the API can be implemented on using the existing Java APIs on the phone, you can include the required class files in your midlet. This of course makes your midlet bigger and if you need to use the same classes in another midlet, you need to include the classes in that midlet too, as the classes of another midlet are not accessible from other midlets. Also note that in most cases this is not possible as usually the new API requires access to the system functions of the phone.
 
Longer answer: No, but if the API can be implemented on using the existing Java APIs on the phone, you can include the required class files in your midlet. This of course makes your midlet bigger and if you need to use the same classes in another midlet, you need to include the classes in that midlet too, as the classes of another midlet are not accessible from other midlets. Also note that in most cases this is not possible as usually the new API requires access to the system functions of the phone.
  
'''Q: Can I read and write files on my mobile phone using a midlet?'''
+
==Can I read and write files on my mobile phone using a midlet?==
  
Yes, if your phone supports the FileConnection API, which is an optional package of JSR-75. Check also this introductory document and the example midlet included [http://www.forum.nokia.com/info/sw.nokia.com/id/82644083-2f4b-4775-a292-c02d6bf5be57/Introduction_To_The_FileConnection_API_v1_1.zip.html here]
+
Yes, if your phone supports the FileConnection API, which is an optional package of JSR-75. Check also this introductory document and the example midlet included [http://www.developer.nokia.com/info/sw.nokia.com/id/82644083-2f4b-4775-a292-c02d6bf5be57/Introduction_To_The_FileConnection_API_v1_1.zip.html here]
  
'''Q: Can I access the address book /to-do list/calendar on my phone'''
+
==Can I access the address book /to-do list/calendar on my phone==
  
Yes, if your phone supports the PIM API, which is an optional package of JSR-75. Check also this introductory document and the example midlet included [http://www.forum.nokia.com/info/sw.nokia.com/id/8837fbf6-b655-4990-be73-d6cffd5f8b29/Introduction_To_The_PIM_API_v1_1.zip.html here]
+
Yes, if your phone supports the PIM API, which is an optional package of JSR-75. Check also this introductory document and the example midlet included [http://www.developer.nokia.com/info/sw.nokia.com/id/8837fbf6-b655-4990-be73-d6cffd5f8b29/Introduction_To_The_PIM_API_v1_1.zip.html here]
  
'''Q: My midlet seems to be too big for my phone. How can I make my JAR files smaller?'''
+
==My midlet seems to be too big for my phone. How can I make my JAR files smaller?==
  
 
Obfuscation replaces the class and method names with short (1 character) names, which has the side effect of making the class files smaller. Originally obfuscation was intended to be a tool to make the reverse engineering of the midlet harder. One example of such tools is Proguard.
 
Obfuscation replaces the class and method names with short (1 character) names, which has the side effect of making the class files smaller. Originally obfuscation was intended to be a tool to make the reverse engineering of the midlet harder. One example of such tools is Proguard.
Line 81: Line 101:
 
You can also shave some bytes off your JAR-file by making the folder names really short.
 
You can also shave some bytes off your JAR-file by making the folder names really short.
  
'''Q: Every time my MIDlet tries to access network/contacts/… there are these annoying confirmation dialogs. Can I get rid of them?'''
+
==Every time my MIDlet tries to access network/contacts/… there are these annoying confirmation dialogs. Can I get rid of them?==
  
 
The new security model introduced in MIDP 2.0 is protects the phone and the user from malicious applications by restricting access to APIs that are considered sensitive. In general the midlet is granted only minimal access to these APIs, meaning that the user is asked for confirmation every time the API is accessed.
 
The new security model introduced in MIDP 2.0 is protects the phone and the user from malicious applications by restricting access to APIs that are considered sensitive. In general the midlet is granted only minimal access to these APIs, meaning that the user is asked for confirmation every time the API is accessed.
  
The user can manually change the default permissions a little through the Application Manager (on S60 devices use the separate Application Manager; on Series 40 devices you can change the application settings from the through the Application Menu).
+
The user can manually change the default permissions a little through the Application Manager (on Symbian devices use the separate Application Manager; on Series 40 devices you can change the application settings from the through the Application Menu).
  
The developer can also sign the MIDlet with a certificate so the MIDlet has less restricted access to the sensitive APIs. The corresponding root certificate has to be available on the target phone; otherwise the installation will fail. The Java Verified certificate is widely available on devices from all manufacturers. Your MIDlet will be signed with this certificate after it passes the Java Verified testing. The testing criteria is available at Java Verified Web site (http://www.javaverified.com).
+
The developer can also sign the MIDlet with a certificate so the MIDlet has less restricted access to the sensitive APIs. The corresponding root certificate has to be available on the target phone; otherwise the installation will fail. The Java Verified certificate is widely available on devices from all manufacturers. Your MIDlet will be signed with this certificate after it passes the Java Verified testing. The testing criteria is available at Java Verified Web site (http://javaverified.com/).
For more information on signed MIDlets, see Signed MIDlet Developer's Guide ([http://www.forum.nokia.com/info/sw.nokia.com/id/3f8c9f9e-e940-4327-8548-49ed023bfe88/MIDP_2_0_Signed_MIDlet_Developers_Guide_v2_0_en.pdf.html]).
+
For more information on signed MIDlets, see Signed MIDlet Developer's Guide ([http://www.developer.nokia.com/info/sw.nokia.com/id/3f8c9f9e-e940-4327-8548-49ed023bfe88/MIDP_2_0_Signed_MIDlet_Developers_Guide_v2_0_en.pdf.html]).
  
'''Q: What kinds of permissions are available for signed and unsigned MIDlets?'''
+
==What kinds of permissions are available for signed and unsigned MIDlets?==
  
This MIDP 2.0 specification addendum ([http://jcp.org/aboutJava/communityprocess/maintenance/jsr118/MIDP_2.0.1_MR_addendum.pdf]) lists the default permissions as well as other available permissions for trusted 3rd party MIDlets and untrusted MIDlets. Note that some carriers/operators grant different permissions to the MIDlets. For example Cingular’s Java Signing Requirement documentation is available on the Cingular developer Web site (http://developer.cingular.com).
+
This MIDP 2.0 specification addendum ([http://jcp.org/aboutJava/communityprocess/maintenance/jsr118/MIDP_2.0.1_MR_addendum.pdf]) lists the default permissions as well as other available permissions for trusted 3rd party MIDlets and untrusted MIDlets. Note that some carriers/operators grant different permissions to the MIDlets. For example Cingular’s Java Signing Overview documentation is available on the at&t developer Web site (http://developer.att.com/developer/forward.jsp?passedItemId=300004m).
  
'''Q: What certificates should I use to sign my MIDlet?'''
+
==What certificates should I use to sign my MIDlet?==
  
 
You can sign your MIDlet with any certificate available on the target devices and allowing the Java Application installation. (You can check what certificates are available on the device through security settings – make sure the certificate you are thinking to use is set to allow Java application signing).
 
You can sign your MIDlet with any certificate available on the target devices and allowing the Java Application installation. (You can check what certificates are available on the device through security settings – make sure the certificate you are thinking to use is set to allow Java application signing).
  
The Java Verified certificate is widely available on devices from all manufacturers. Your MIDlet will be signed with this certificate after it passes the Java Verified testing. The testing criteria is available at Java Verified Web site (http://www.javaverified.com).
+
The Java Verified certificate is widely available on devices from all manufacturers. Your MIDlet will be signed with this certificate after it passes the Java Verified testing. The testing criteria is available at Java Verified Web site (http://javaverified.com/).
  
'''Q: Can I use a certificate and key created by me to sign my midlets?'''
+
==Can I use a certificate and key created by me to sign my midlets?==
  
 
Yes, you can run a midlet signed with a certificate created by you on emulators. Self-signing does not work on Series 40 devices nor S60 3rd edition devices.
 
Yes, you can run a midlet signed with a certificate created by you on emulators. Self-signing does not work on Series 40 devices nor S60 3rd edition devices.
  
'''Q: I have a signed MIDlet I cannot install on my device. Is there any way to install this MIDlet?'''
+
==I have a signed MIDlet I cannot install on my device. Is there any way to install this MIDlet?==
  
 
Check that all the required permissions are requested in the JAD file. You can also try removing the <i>MIDlet-Jar-RSA-SHA1:</i> and <i>MIDlet-Certificate-1-1:</i> entries from the JAD file (your signed MIDlet will now be treated as unsigned midlet). If the installation still fails, check that the JAR file size attribute is correct in the JAD file. Make also sure that all the JAD properties are set a non-empty value.
 
Check that all the required permissions are requested in the JAD file. You can also try removing the <i>MIDlet-Jar-RSA-SHA1:</i> and <i>MIDlet-Certificate-1-1:</i> entries from the JAD file (your signed MIDlet will now be treated as unsigned midlet). If the installation still fails, check that the JAR file size attribute is correct in the JAD file. Make also sure that all the JAD properties are set a non-empty value.
  
'''Q: How do I retrieve the phone number from my midlet?'''
+
==How do I retrieve the phone number from my midlet?==
  
You would have to use the [http://jcp.org/aboutJava/communityprocess/final/jsr253/index.html 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.
+
You would have to use the [http://jcp.org/aboutJava/communityprocess/final/jsr253/index.html JSR 253 - Mobile Telephony API] which allows you to have a fairly good set of call-related functionality, 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:
 
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.
+
*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 {{Icode|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 [CODE]Message.getAddress()[/CODE] 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 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 [CODE]Message.getAddress()[/CODE] 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.
+
*If you are using an Symbian 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.  
  
 +
==How do I get the IMEI of a phone from my midlet?==
 +
Refer to [[How to get IMEI in Java ME]]
  
'''Q: How do I get the IMEI of a phone from my midlet?'''
+
==Will my Java ME application run unmodified across all platforms?==
Refer to [[How_to_get_IMEI_in_Java_ME]]
+
 
+
'''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.
+
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, Symbian and Series 80.
  
 
There are several degrees of portability, however:  
 
There are several degrees of portability, however:  
Line 139: Line 158:
 
----
 
----
  
*'''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 [http://forum.nokia.com/devices/6230i Nokia 6230i], but not on [http://forum.nokia.com/devices/6101 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:  
+
*'''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 [http://www.developer.nokia.com/Devices/Device_specifications/6230i/ Nokia 6230i], but not on [http://www.developer.nokia.com/Devices/Device_specifications/6101/ 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:  
 
**[http://antenna.sourceforge.net Antenna]  
 
**[http://antenna.sourceforge.net Antenna]  
**[http://www.netbeans.org/kb/articles/mobility.html NetBeans Mobility Pack].
+
**[http://netbeans.org/ NetBeans].
*'''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 [http://forum.nokia.com/devices/6230 6230] and [http://forum.nokia.com/devices/6681 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.
+
*'''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 [http://www.developer.nokia.com/Devices/Device_specifications/6230/ 6230] and [http://www.developer.nokia.com/Devices/Device_specifications/6681/ 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, [http://forum.nokia.com/devices/6230i 6230i] has a 208x208 display, while [http://forum.nokia.com/devices/E61 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.
+
*'''Hardware-level differences''': Those refer mostly to the screen size and resolution. For example, [http://www.developer.nokia.com/Devices/Device_specifications/6230i/ 6230i] has a 208x208 display, while [http://www.developer.nokia.com/Devices/Device_specifications/E61/ 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?'''
+
==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:
 
On S60 3rd. Edition devices, there is some DRM support. You can play a DRM-protected file, using the following syntax:
Line 154: Line 173:
 
</code>
 
</code>
  
'''Q: I signed my midlet with a Verisign/Thawte and it's not installing on device <i>X</i>, what's wrong with it?'''
+
==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.  
 
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.  
Line 160: Line 179:
 
You can check whether this is the case this way:
 
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 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 Series 40 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".
+
On Symbian 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.'''
+
==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:
 
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.
 
*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.
*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.
+
*On Symbian, 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.
  
 
Please note that the default access rights are not ever the same as max access rights. The user has to manually change them.
 
Please note that the default access rights are not ever the same as max access rights. The user has to manually change them.
Line 177: Line 196:
 
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.
 
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?'''
+
==Why can't I have my midlet auto-started with PushRegistry without a security prompt being shown, even though the application is signed?==
 +
 
 +
See [[Variance in security domains for MIDlets on certain operator variant Series 40 2nd Edition phones (Known Issue)]].
  
Please check this [http://forum.nokia.com/document/Forum_Nokia_Technical_Library/contents/FNTL/PushRegistry_confirmation_on_Series_40_MIDlets.htm Forum Nokia Tech Library entry] for details.
+
[[Category:Getting Started on Java ME]]

Latest revision as of 05:03, 25 July 2013

Article Metadata
Article
Created: dcrocha (30 Oct 2007)
Last edited: hamishwillee (25 Jul 2013)


This article contains the most frequently asked questions on the Java Discussion Boards. Many important pieces of information that can help you solve the most basic/recurrent problems when developing in Java ME.

Contents

[edit] I cannot get this midlet of mine working? Please HELP ME! Urgent!

First check the Javadocs for that API (those are included in all SDK installations). There are also sample midlets and documentation available on Nokia Developer website ([1]). And you can find wealth of information in here (Discussion Boards at [2]) and on Sun’s JavaME web site ([3]).

If you are still having problems, please include relevant parts of the source code in your post, and also specify which devices you are working on. If the problem has something to do with your desktop computer, please add OS information for your desktop computer too. In some cases the firmware version of the device might provide valuable information to the readers (*#0000# in the idle screen).

[edit] What tools do I need to create my first midlet?

You can write your code in your favorite text editor or you could use an IDE (Integrated Development Environment), such as Eclipse, Netbeans, or JBuilder. [Note: reference to Carbide.j has been removed as Nokia does not provide that tool anymore]

When you use Sun’s Wireless Toolkit, NetBeans with Mobility pack, and other mobile Java development environments, you should remember that if you are developing your midlet for Nokia devices, it is advisable to test the application with Nokia emulators (as well as on real devices), as the generic emulators behave differently from Nokia emulators and Nokia devices.

Announcements.pngNokia Asha SDK 1.0 (beta) (14 May 2013): Nokia Asha SDK 1.0 (beta) is available for download. This SDK enables you to target your Java apps at phones based on Nokia Asha software platform 1.0. SDKs for Series 40 (including Nokia SDK 2.0 for Java), can be downloaded from here.

[edit] I need to download Nokia Development Suite X.X for J2ME. Where can I find it?

NDS was replaced with Carbide.j, which was in its turn removed from Nokia's tools portfolio in 2007. Please use Eclipse + EclipseME or NetBeans + Mobility Pack for your MIDlet development. See Getting started with Java ME and Installing Java ME development tools for S60.

[edit] How can I transfer my midlet to the handset?

On Symbian phones and newer Series 40 phones: Send the JAR and JAD files over Bluetooth from the File Browser.

On older Series 40 phones, you need to use PC Suite. PC Suite works well also with Symbian and newer Series 40 phones.

An advanced option is to store the JAR and JAD files on a Web server and connect to the JAD file using the phone browser. Make sure the mime types are set correctly on the server (“application/java-archive” for jar and “text/vnd.sun.j2me.app-descriptor” for jad).

[edit] How can I debug my midlet?

All SDKs contain an emulator, which basically emulates the phone Java environment and the set of APIs included in that SDK on your PC. When you run your midlet in the emulator, you can see diagnostic information (like printStackTrace() output) in the IDE's console screen.

You should always test your application on a real device as some of the phone capabilities cannot be emulated on PC. Also there are subtle differences in the phone implementations.

[edit] Why are there so many SDKs, can’t I just use one to code and test my midlet?

Announcements.pngNokia Asha SDK 1.0 (beta) (14 May 2013): Nokia Asha SDK 1.0 (beta) is available for download. This SDK enables you to target your Java apps at phones based on Nokia Asha software platform 1.0. SDKs for Series 40 (including Nokia SDK 2.0 for Java), can be downloaded from here.

Different phones have different set of APIs, and the SDKs provide a compatible set of APIs for each device (and an emulator to test the midlets on). Nokia devices are based on platforms (like Series 40, Symbian , and Series 80), editions (1st, 2nd, and 3rd edition so far), and Feature Packs. Each device belongs to one of platform edition / feature pack combination.

For example if you are developing an application for N70 smart phone, which is a S60 2nd Edition Feature Pack 3 device, you should be using that specific SDK to develop the midlet on. If you are using an earlier SDK version, some of the APIs might be missing. If you are using a newer SDK version, you might end up using features which are not available on N70. Additionally the emulator of the S60 2nd Ed FP3 SDK provides the closest emulation of that specific device of all the available emulators.

[edit] Does my handset support API xyz?

Please check the device specifications at http://www.developer.nokia.com/Devices/

You can also use a shortcut URL – add the phone model number in the end of the previous URL. For example if you want to see the specifications of Nokia 6131 phone you can go to this URL http://www.developer.nokia.com/Devices/Device_specifications/6131/

Or if you are looking for API availability on devices from other manufacturers, you can also check the J2ME Polish Device Database at [4].

For most of the newer APIs it is also possible to query the phone during execution time if a certain API exists. This is done using System.getProperty() method call. Please check the correct query strings (for example microedition.pim.version for PIM API) from this document [5]

A special case is MMAPI, which contains a lot of optional features. For example not all phones are able to use the camera. You can check how the MMAPI is supported on various Nokia devices from this doc MMAPI Support In Nokia Devices

[edit] My phone does not seem to have support for API xyz. Can it be added on the phone?

Short answer: No.

Longer answer: No, but if the API can be implemented on using the existing Java APIs on the phone, you can include the required class files in your midlet. This of course makes your midlet bigger and if you need to use the same classes in another midlet, you need to include the classes in that midlet too, as the classes of another midlet are not accessible from other midlets. Also note that in most cases this is not possible as usually the new API requires access to the system functions of the phone.

[edit] Can I read and write files on my mobile phone using a midlet?

Yes, if your phone supports the FileConnection API, which is an optional package of JSR-75. Check also this introductory document and the example midlet included here

[edit] Can I access the address book /to-do list/calendar on my phone

Yes, if your phone supports the PIM API, which is an optional package of JSR-75. Check also this introductory document and the example midlet included here

[edit] My midlet seems to be too big for my phone. How can I make my JAR files smaller?

Obfuscation replaces the class and method names with short (1 character) names, which has the side effect of making the class files smaller. Originally obfuscation was intended to be a tool to make the reverse engineering of the midlet harder. One example of such tools is Proguard.

If your application uses resource files (images, audio, or video), make sure they are optimized for the small devices (suitable bit depth, image resolution, audio bit rate, and so on.)

You can also shave some bytes off your JAR-file by making the folder names really short.

[edit] Every time my MIDlet tries to access network/contacts/… there are these annoying confirmation dialogs. Can I get rid of them?

The new security model introduced in MIDP 2.0 is protects the phone and the user from malicious applications by restricting access to APIs that are considered sensitive. In general the midlet is granted only minimal access to these APIs, meaning that the user is asked for confirmation every time the API is accessed.

The user can manually change the default permissions a little through the Application Manager (on Symbian devices use the separate Application Manager; on Series 40 devices you can change the application settings from the through the Application Menu).

The developer can also sign the MIDlet with a certificate so the MIDlet has less restricted access to the sensitive APIs. The corresponding root certificate has to be available on the target phone; otherwise the installation will fail. The Java Verified certificate is widely available on devices from all manufacturers. Your MIDlet will be signed with this certificate after it passes the Java Verified testing. The testing criteria is available at Java Verified Web site (http://javaverified.com/). For more information on signed MIDlets, see Signed MIDlet Developer's Guide ([6]).

[edit] What kinds of permissions are available for signed and unsigned MIDlets?

This MIDP 2.0 specification addendum ([7]) lists the default permissions as well as other available permissions for trusted 3rd party MIDlets and untrusted MIDlets. Note that some carriers/operators grant different permissions to the MIDlets. For example Cingular’s Java Signing Overview documentation is available on the at&t developer Web site (http://developer.att.com/developer/forward.jsp?passedItemId=300004m).

[edit] What certificates should I use to sign my MIDlet?

You can sign your MIDlet with any certificate available on the target devices and allowing the Java Application installation. (You can check what certificates are available on the device through security settings – make sure the certificate you are thinking to use is set to allow Java application signing).

The Java Verified certificate is widely available on devices from all manufacturers. Your MIDlet will be signed with this certificate after it passes the Java Verified testing. The testing criteria is available at Java Verified Web site (http://javaverified.com/).

[edit] Can I use a certificate and key created by me to sign my midlets?

Yes, you can run a midlet signed with a certificate created by you on emulators. Self-signing does not work on Series 40 devices nor S60 3rd edition devices.

[edit] I have a signed MIDlet I cannot install on my device. Is there any way to install this MIDlet?

Check that all the required permissions are requested in the JAD file. You can also try removing the MIDlet-Jar-RSA-SHA1: and MIDlet-Certificate-1-1: entries from the JAD file (your signed MIDlet will now be treated as unsigned midlet). If the installation still fails, check that the JAR file size attribute is correct in the JAD file. Make also sure that all the JAD properties are set a non-empty value.

[edit] 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 functionality, 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 [CODE]Message.getAddress()[/CODE] 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 Symbian 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.

[edit] How do I get the IMEI of a phone from my midlet?

Refer to How to get IMEI in Java ME

[edit] 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, Symbian 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:
  • 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.

[edit] 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");
p.start();

[edit] I signed my midlet with a Verisign/Thawte and it's not installing on device X, 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 Series 40 devices have the certificates under Services.

On Symbian 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".

[edit] 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.
  • On Symbian, 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.

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.

[edit] Why can't I have my midlet auto-started with PushRegistry without a security prompt being shown, even though the application is signed?

See Variance in security domains for MIDlets on certain operator variant Series 40 2nd Edition phones (Known Issue).

This page was last modified on 25 July 2013, at 05:03.
1794 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×