MIDP support on the 7925G? http://developer.cisco.com/c/message_boards/find_category?p_l_id=2371355&mbCategoryId=0 2013-05-19T11:09:28Z 2013-05-19T11:09:28Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2726862 2010-11-10T02:33:01Z 2010-11-10T02:33:01Z

We tried implementing our own setFocus(item) function as follows:   public void setFocus(Item item) { Display.getDisplay(AMC.getMIDlet()).setCurrentItem(item); }   The way we use this is that we call it as part of the implementation of the constructor of the Form with the intent that the specific item passed in would have focus when the form is displayed.   This approach works correctly in the WTK emulator but does not work correctly on the 7925 device.  What we see on the device is that the first item on the form is highlighted and has focus instead of the one we requested with our call to setForm().   Is there some other way to do this that will work correctly on the device?  One theory I have is that since we are calling it before the Form has actually been displayed we may be calling it too early in the lifecycle of the Form.  Would it work better if I tried this instead?   Display.runSerially(setFocus(item));   I believe this would delay invoking the call until after the UI thread has returned from creating the Form.

Craig Knighton 2010-11-10T02:33:01Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2726466 2010-11-09T23:29:24Z 2010-11-09T23:29:24Z

Good question - we would like this too.  For now we have resorted to using the device's MAC address as a unique identifier but what we really want is the extension that the user is using.   FYI - to get the MAC address:   String phoneNumber = System.getProperty("com.cisco.device.settings.network.macaddress");

Craig Knighton 2010-11-09T23:29:24Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2723306 2010-11-09T05:17:25Z 2010-11-09T05:17:25Z

I tried passing the vibrate URI on with a platformRequest but nothing happens on the phone (7925).  In the Java log I see:   2010-11-08 17:14:21:0730 CP-7925G user.err java: JwcNativePR(Vibrate:1000:0:1): Which suggests that my platform call is being made and I think it is formatted correctly.  Any suggestions as to why the phone would not vibrate?

Craig Knighton 2010-11-09T05:17:25Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2723149 2010-11-09T04:27:28Z 2010-11-09T04:27:28Z

I think I found it - it looks like the URI format is:   Vibrate:vibrateDuration:silenceDuration:count   For example, this will vibrate once for one second: Vibrate:1000:0:1   I'll be trying it by sending this string via a call to platformRequest

Craig Knighton 2010-11-09T04:27:28Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2723115 2010-11-09T04:11:51Z 2010-11-09T04:11:51Z

A couple of questions:   1.  Are there any built-in sounds available that we could expose through our application other than the ability to play a tone?   2.  We usually use MP3 format tones to reduce JAR file size and save space but the only format supported appears to be WAV files.  These are large enough that we can only include a few sounds before the JAR file gets too big to fit.  Any other suggestions for how to compress the data or use alternative formats that we are not aware of?  

Craig Knighton 2010-11-09T04:11:51Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2722729 2010-11-09T01:13:45Z 2010-11-09T01:13:45Z

We are trying to use the the playTone API on the Media Manager class to play tones on the device as follows:   Manager.playTone(ToneControl.C4 + 12, 1000, parameters.volume);   It does play a tone but always seems to play it at the same volume even though we have tried various values from 0 to 100.   On the call today Conrad mentioned that there was a concept of minimum volume that is controlled by the administrators - is it possible that this is preventing the application from requesting a lower volume, or is it possible that it is a firmware bug?    

Craig Knighton 2010-11-09T01:13:45Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2722721 2010-11-09T01:02:51Z 2010-11-09T01:02:51Z

[quote]  There is also an XSI Vibrate URI that can be used  in conjunction with the IPPhoneExecute command. The details on the syntax should be in the XML developer guide.   -Conrad[/quote] Can you elaborate on how to best call the XSI URI from inside the MIDlet?  Do you use the platformRequest API?  If so, what is the specific format for the request (or where are these documented)?   I have been successful using the Dial URI as follows - is it something like this?   "Dial:" + phoneNumber + ":1:Amcom/AMC/AMC"

Craig Knighton 2010-11-09T01:02:51Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2699621 2010-11-02T03:07:46Z 2010-11-02T03:07:46Z

[quote]If you do not specify a version number in the service parameters, it will download the MIDlet each time it is loaded.[/quote]   I found I wasn't sure this method worked - if you watch the debug log messages you'll see that it looks like it compares the version number retrieved from the JAD file on the server to the version number that was last installed on the phone and if they match it looks like it skips downloading the JAR file again.  As such, I think your build process would need to update the version number on every build to be sure the new version gets to the phone.   I wasn't willing to do that yet so I have stuck with unsubscribing/subscribing to be sure.  Does anyone else no for sure that it always downloads and installs the new JAR regardless of the version number in the JAD?

Craig Knighton 2010-11-02T03:07:46Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2690405 2010-10-28T21:15:05Z 2010-10-28T21:15:05Z

I don't think that it is, and I'll also try to save you some time in looking elsewhere - JSR226 would provide an implementation of the org.w3c.dom classes such as Document, Note, etc but that does not seem to be implemented either.  Here's a link with some possible parser implementations to consider although none seem to implement the org.w3c.dom spec:   Check out the middle of this article for a list of MIDP products available (note that not all of them are MIDP ready out of the box):   [url=http://developers.sun.com/mobility/midp/articles/parsingxml/]http://developers.sun.com/mobility/midp/articles/parsingxml/[/url]

Craig Knighton 2010-10-28T21:15:05Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2688202 2010-10-28T18:59:51Z 2010-10-28T18:59:51Z

Can anyone tell me if the 7925/7926 phone hardware supports vibrate?  I'm assuming they don't as I found no evidence of it.  Is there support in the API for it and is it worth coding against those API's in case future phones do have support?   Also, is there any way to control the color or state of the LED indicator on these same phones?   Thanks in advance, CK

Craig Knighton 2010-10-28T18:59:51Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2688626 2010-10-28T01:24:01Z 2010-10-28T01:24:01Z

That seems like a response from an IIS web server - are you sure you have the right IP address for the phone?  You can find it on the phone under Settings->Device Information->Network->IP Address.

Craig Knighton 2010-10-28T01:24:01Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2688574 2010-10-28T01:08:19Z 2010-10-28T01:08:19Z

I just resolved a similar issue - it turned out that the problem was that the phone was not able to reliably download the MIDlet over the URL that was provided.  I assume that you are seeing the MIDlet listed on your SERVICES screen but that this error happens when you try to launch it.   I suspect that if you look at your web server logs for the web server that is hosting the URL where the JAD/JAR are located you will see that the phone is never reaching the server or that if it is the connection is failing before the entire JAD or JAR is downloaded.  I had both problems happening and needed to relocate closer to the access point to get a reliable connection.   You can get more information about what is happening by connecting to the web server on the phone from a browser and elevating the trace settings on that phone to record full debug for all Java messages.  If you do this you should be able to see the messages around the attempt to retrieve the JAD and JAR and if that process is failing.  The steps for allowing access to the admin console on the phone are in the Admin guide for the phone.

Craig Knighton 2010-10-28T01:08:19Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2680209 2010-10-26T20:47:50Z 2010-10-26T20:47:50Z

You were right - the issue was that the JAD and/or JAR were not being downloaded successfully because of poor wifi coverage in the area where I was working.  As a result, while your Phone Service would be listed, when you clicked on it you just got an error that said "Error, contact administrator".   I stumbled on this because it happened to succeed once this morning and I was able to see what it looks like when a Java midlet does attempt to launch.  One way to diagnose the problem is that when an midlet does try to launch you will see the Java logo pop on the title bar.   I did have JAD file issues earlier but my attempts to resolve them and test the fix were failing because of the connectivity issues.  Another way to diagnose this issue is that you also can not retrieve any details about the midlet - you just get the same error displayed.  If you were successful at downloading the application then you will at least see details even if the application fails to launch successfully.

Craig Knighton 2010-10-26T20:47:50Z Craig Knighton http://developer.cisco.com/c/message_boards/find_message?p_l_id=2371355&messageId=2633443 2010-10-13T02:22:43Z 2010-10-13T02:22:43Z

I have a "Hello World" applet built that I am trying to deploy to my 7925G phone via CUCM 7.  The provisioning process for the IP Phone Service and subscription on the phone for the MIDLet all seem to work as expected and the MIDLet ends up listed as available under the Services menu, but when I select it, nothing happens.  I have examined the web logs to confirm that the phone is not even attempting to read the JAD/JAR files from the specified URL.   Any ideas what is happening?  From what I can see, MIDLets on the 7925 are supported without any special signing, but I'm stumped as to why the phone will not attempt to download the application as expected.  Could this relate to the version of firmware in use on the phone?

Craig Knighton 2010-10-13T02:22:43Z