Mobility Tech Tips

Java ME SDKs and Tools: The State of the Union

2009-07-08T10:46:43-07:00

This article demonstrates that Java ME developers have a wide array of choices -- in addition to the full-featured Java ME SDK (which replaces the well-known Wireless Toolkit) -- to create and test applications.

The Sun Java ME SDK 3.0, considered the de facto standard SDK when it comes to mobile application development, integrates the very popular Java Wireless Toolkit for CLDC and the Java Toolkit for CDC as a single product. It lets developers create Java ME applications for the following JVM platforms:

CLDC/MIDP: The common JVM configuration for hundreds of millions of mobile phones
CDC/FP/PBP/AGUI: The JVM configuration for high-end smart phones and other devices
CDC/FP/PBP/BD-J: The JVM configuration for Blu-ray Disc players

In addition to the Sun Java ME SDK 3.0, this article include details on the following offerings and then summarizes them in a handy comparison table:

NetBeans 6.5 IDE
MOTODEV Studio for Java ME
Nokia S60, S40, and NFC SDKs
BlackBerry JDE 4.7
Sony Ericsson SDK 2.5 for Java ME
LG SDK 1.2 for Java ME

The Java ME SDK Comparison Matrix table shows a list of all Java ME SDKs and tools that are evaluated in this article, with an entry for API support for each one. (Note: The NetBeans IDE supports multiple Java configurations, so its entries in this matrix apply to when it is configured with the Java ME SDK 3.0.)

Read the full article

Working with Bluetooth and GPS: Follow-up

2009-06-10T15:21:01-07:00

By Bruce Hopkins

After reading both Part 1 and Part 2 of the “Working with Bluetooth and GPS” series of articles, you were given a clear explanation of the example code that shows you how to do the following:

Therefore, the purpose of this tech tip is to provide answers to the questions that were submitted by the readers of both articles in the series.

Question 1: Hi Bruce, I have a problem when I start the Mpowerplayer tool with any MIDlet that uses Bluetooth and the JSR-82 API. When the application tries to execute my MIDet, it immediately displays a java.lang.NoClassDefFoundError: javax/bluetooth/DiscoveryListener. What could be the problem?

Answer 1: The MPowerplayer made a change on how it handles JSR-82 libraries between releases #1127 and #1185. Unfortunately, it not explicitly stated in the documentation, but you need to make two simple changes in order to run MIDlets that require the JSR-82 API:

/mpp-sdk

bt.jar

After you make those two changes, you will be able to run any application requires the JSR-82 APIs.

Question 2: Hi Bruce, this is a nice article. I would like to know how to get GPS data from a mobile phone that already has a GPS receiver built-in.

Answer 2: If your mobile phone is MSA-compliant and already has a GPS radio built-in, then you don’t need to use the JSR-82 API to connect to a remote GPS receiver. All you need to do is use the JSR-179 Location APIs in order to retrieve your location data from an embedded GPS receiver. If you’d like to get started with the JSR-179 API, then Qusay Mahmoud has written a great article, Java ME and Location-Based Services, on that topic.

Question 3: I have a Bluetooth-enabled GPS receiver: the Holux Slim 236. I also have a Bluetooth-enabled computer. Can I run this example with what I have?

Answer 3: Yes, you should have no problem running the example code using the tools that you have. If you plan to use the current version of Mpowerplayer, then be sure to follow the instructions in the answer to Q1 first.

Question 4: Hi Bruce, thanks for creating this meaningful guide for developers. Your original article shows developers how to use the Avetana Bluetooth JSR-82 implementation with the Mpowerplayer SDK. The problem, however is that Aventana implementation only provides a free 14-day trial, and afterwards requires a license fee. Is there any way to configure the Mpowerplayer with the BlueCove JSR-82 implementation which is open source?

Answer 4: Yes, please refer to the answer provided to Q1 listed above in order to find out how to use the BlueCove library with the MPowerplayer SDK.

Question 5: Hi, I am having problem with this example with WTK 2.5.2 and NetBeans IDE 6.1 which are both installed in my PC. When I run this application on my PC, I’m not able to get any data from the remote Bluetooth devices.

Answer 5: Actually, the whole point of Part 1 in the two-part series was to show developers how to debug and test their JSR-82 applications on their PCs using the Mpowerplayer. Neither the WTK, the NetBeans IDE, nor the Java ME SDK have the ability to leverage the Bluetooth hardware of your PC in order to discover or search for services on remote Bluetooth devices.

Question 6: I have a Bluetooth-enabled phone with a built-in GPS receiver. I want to send NMEA data from the phone to a Bluetooth-enabled PC. I have a desktop application (Streets & Trips) that can consume GPS data. Since my phone support GPS and Bluetooth, is there a Java ME application that will enable my mobile phone to do this?

Answer 6: I don’t know of any Java ME applications that do this, however this sounds like the basis for another article!

Final Thoughts

Thanks to all the readers who took the time to provide feedback to this article series! Your input, thoughts, questions, and ideas are always welcome and appreciated.

Using the Location API for Favorite Spots

2009-04-22T18:11:04-07:00

By Vikram Goyal

Developing location-aware applications seems like a lot of work, especially since getting started seems to be the hardest part. In this tech tip, I will show you how to get started using the Location API (JSR 179) to get over the initial hurdle, and build a small location-aware application that you can use to tag your favorite spots.

I have tested and verified that the MIDlet works on a Nokia N95 device. When testing this on your device, make sure that it supports the Location API (JSR 179).

There are three steps in this tech tip

Find and initialize a location provider
Listen and act on location updates given by this provider
Store and list favorite spots

The following paragraphs elaborate on these steps. It may help to have the entire source code of this MIDlet available for review while following the code snippets in these steps.

Step 1: Find and initialize a location provider

The process of discovery of a suitable location provider is broken down into two further steps. First, you need to create a set of criteria for the location provider. Second, you need to create an instance of this provider using these criteria.

The Location API provides two classes for these two steps: Criteria and LocationProvider.

To create a valid criteria, you create an instance of this class, set various parameters of the criteria. The code below, taken from the source code, creates a criteria that is suitable for our purposes.


  // create a very basic criteria for the provider
  Criteria criteria = new Criteria();
  criteria.setHorizontalAccuracy(Criteria.NO_REQUIREMENT);
  criteria.setVerticalAccuracy(Criteria.NO_REQUIREMENT);
  criteria.setPreferredResponseTime(Criteria.NO_REQUIREMENT);
  criteria.setCostAllowed(false);

As you can see, this is a very relaxed criteria. There are no specific requirements for horizontal or vertical accuracy or for response times. The only restriction is that there should not be a cost involved in using the Location API (possibly linked to the network provider).

We should be allowed to proceed only if the Location API built into your device can provide a provider based on these criteria. We do so, by asking the LocationProvider class for a provider using these criteria as the guiding set.


  // get the provider based on this criteria
  LocationProvider provider = LocationProvider.getInstance(criteria);

  // provider found
  if (provider != null) {
    provider.setLocationListener(this, -1, 0, 0);
  } else {
    display.setCurrent(
      new Alert("Error!",
      "Phone does not support Location Provider with the given criteria",
      null, AlertType.ERROR));
  }

If a provider with the given criteria cannot be found, a message is given to the user, and the MIDlet cannot proceed. But if the device can provide a valid location provider, the MIDlet sets up a location listener to listen to all the updates given by the location provider. In this case, the listener is the MIDlet itself.

Step 2: Listen and act on location updates

In the previous step, the location listener is set to the MIDlet itself. This means that the MIDlet must implement two methods provided by the LocationListener class. These two methods are locationUpdated(LocationProvider lp, Location l) and providerStateChanged(LocationProvider lp, int newState). The code below shows the implementation of the locationUpdated method.


  // if valid location is found, update the coords and status
  if(location != null && location.isValid()) {
    QualifiedCoordinates coords = location.getQualifiedCoordinates();
    coordsDisplay.setText(
      truncate(coords.getLatitude()) + ", " +
      truncate(coords.getLongitude()));
    statusDisplay.setText("Available");
    currentLocation = location;
  } else {
    coordsDisplay.setText("--, --");
    statusDisplay.setText("Unavailable");
    currentLocation = null;
  }

Each time the location of the device is updated, the location provider sends out the new location using the Location parameter in the locationUpdated method. The new location's coordinates can be picked using the getQualifiedCoordinates method.

Of course, if the device is out of range of the GPS satellites, then the provider will not be able to get the correct coordinates and, therefore, the actual location will be either null or invalid. The method checks for this before updating the status and the current location of the device.

The providerStateChanged method accepts updates when the location provider goes in and out of range of the GPS satellites. However, I found that my implementation on the Nokia N95 did not reliably send out updates for the providerStateChanged method. I therefore used the locationUpdated method to find out the status of the provider, However, I have kept the code in the providerStateChanged in case it works on other devices.

NOTE

To be on the safe side, the code in the locationUpdated method (and the corresponding providerStateChanged method) should be in its own thread to make sure that it doesn't block the normal MIDlet thread.

Step 3: Store and list favorite spots

Once the current location using the latitude and longitude have been found, it is a simple method to store this location with a tag as your favorite spot. The Location API makes it ridiculously simple by providing the Landmark store. You can either create your own Landmark store, or use the default one.

The default Landmark store is shared by all the MIDlets within the device. You create a Landmark store by using the static method provided by the LandmarkStore class. By passing in null, as shown in the following code, you are asking for the default store from this instance.

  store = LandmarkStore.getInstance(null);

The Landmark store contains the details of a location using the Landmark class. As shown in the following code, you can create a landmark by giving it a name (provide by you as a name for your favorite spot), a description (this is empty in the code below), and of course, the all important coordinates. The last parameter that is accepted by this constructor is an AddressInfo object that can be used to store actual address information, if supported by the provider. In this case, I have kept these details as simple as possible.


    // create the landmark
    Landmark landmark =
      new Landmark(name, "", currentLocation.getQualifiedCoordinates(), null);

    // and save it
    try {
      store.addLandmark(landmark, null);

      display.setCurrent(
        new Alert("Message", "Done", null, AlertType.INFO), displayForm);

      return;

    } catch(Exception ex) {
      handleError(ex);
    }

Once you have created the landmark, you can store it in the store using the addLandmark method. The second parameter specifies a category for that landmark, but I have kept it simple by putting it in the default category.

The list of existing landmarks can be retrieved using the getLandmarks method. This returns an enumeration that can be iterated over to display to the user in a list. This is shown in the following code.


  Enumeration en = store.getLandmarks();
  while(en.hasMoreElements()) {
    Landmark landmark = (Landmark)en.nextElement();
    landmarkList.append(
      landmark.getName() +
      " - " +
      truncate(landmark.getQualifiedCoordinates().getLatitude()) + ", " +
      truncate(landmark.getQualifiedCoordinates().getLongitude()), null);

Resources

Source code as a Netbeans project
Location API (JSR 179)

Q&A on Blu-ray Disc Application Development with Java ME

2009-04-01T11:57:39-07:00

By Bruce Hopkins

Java technology is an integral part of the new high-definition video standard: the Blu-ray Disc standard. In the past year, Sun published a two-part series to lower the learning curve for Java developers who want to get started using the Blu-ray Disc for Java (BD-J) platform.

In Part 1: Creating Your First Application, I provided an introduction to the BD-J platform and provided information on the various APIs that are required by BD-J, including GEM/MHP (Globally Executable Multi Home Platform) and Java TV. In Part 2: Responding to User Input, I showed you how to use the Java ME SDK to create an application that can respond to the user via the remote.

Among the thousands of readers of this series, several readers submitted the following questions in the Comments section of the articles.

Question: Is it really a good idea to use org.havi and org.dvb classes? Will this work on all Blu-ray players?

Answer: Yes, it is perfectly fine to use any of the use org.havi and org.dvb classes that are a part of the BD-J specification. Specifically, those classes originate from the GEM/MHP layer of the BD-J software stack, and all Blu-ray players must support them. Please refer to Part 1, where I provide a complete list of all the Java packages that must be supported in all Blu-ray players on the market (including PC-based Blu-ray players).

Question: I have following the problem when I compile the source file:

Fatal Error: Unable to find package java.lang in classpath or bootclasspath

Details message:  target="${javac.target}"
 deprecation="${javac.deprecation}" optimize="${javac.optimize}"
 debug="${javac.debug}"
 srcdir="${buildsystem.baton}" destdir="${build.classes.dir}"
 bootclasspath="${platform.bootclasspath}"
 includes="${javac.includes}"
 encoding="${javac.encoding}">

Answer: If you’re using the Java ME SDK 3.0 platform and you’re having a compilation error, then please refer to the instructions provided in Part 2: I list step-by-step instructions on how to set up the Java ME SDK 3.0 to compile BD-J applications. Note that the Java ME SDK 3.0 cannot compile BD-J applications in its default state after you install the SDK. It must be configured with the BD-J libraries to compile BD-J applications.

Final Thoughts

Thanks to all the readers who took the time to provide feedback to this article series! Your input, thoughts, questions, and ideas are always welcome and appreciated.

Discovering Devices and Sending Files via Bluetooth in Java ME

2009-03-19T19:56:23-07:00

By Vikram Goyal

One of the first steps in implementing Bluetooth applications on Java ME devices is the discovery process. In a nutshell, the discovery process is the process by which Bluetooth-enabled devices find each other, and then handshake to find out the services that they can each support. The next step, invariably, is learning how to send data between these paired devices.

In this tech tip, I will show you how to create a MIDlet that will search for devices and services, and then will allow the user to send a simple note to one of the found devices. I have tested and verified that the MIDlet works on a Nokia N95 device, and that it connects to a computer running Windows Vista, with Bluetooth support enabled.

I have broken down the whole process into the following steps:

Start the discovery process.
Query the devices found in the discovery process for supported services.
Initiate and process an OBEX data exchange using the supported service URL.

The following paragraphs elaborate on these steps. It may help to have the whole source code of this MIDlet available for review while following the code snippets in these steps. The source code is available as a zipped file under Resources.

Step 1: Start the discovery process

The discovery process is used to tell the local Bluetooth stack that it should look within the nearby vicinity for any Bluetooth devices that are available for pairing. In the case of the MIDlet, this stack will be the implementation provided by your device provider for JSR 82.

This process of discovery is initiated by the discovery agent present in the local device, as shown in the following code.


    // get the local discovery agent
    agent = LocalDevice.getLocalDevice().getDiscoveryAgent();

    // start the inquiry for general unlimited inquiry
    agent.startInquiry(DiscoveryAgent.GIAC, this);

Once the discovery agent has started the discovery process, it will call various callback methods on a class that implements the DiscoveryListener interface. In our case, this is our MIDlet class.

Specifically, four methods of this interface must be implemented, two of which are interest to us in the discovery phase: deviceDiscovered(RemoteDevice btDevice, DeviceClass cod) and inquiryCompleted(int discType). These two methods handle the discovery of a device and completion of the discovery process, respectively. As shown in the following code from the MIDlet, we use these methods to append our UI with devices as they are discovered and when the process is completed.


  public void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod) {
    try {
      // add the devices using the friendly names
      listofDevices.append(btDevice.getFriendlyName(false), null);
      // add to the devices hashtable
      devices.put(new Long(listofDevices.size()), btDevice);
    } catch(Exception ex) { handleError(ex); }
  }

  public void inquiryCompleted(int discType) {
    // once the inquiry is completed, show the list of devices to the user
    if(listofDevices.size() == 0) {
      display.setCurrent(nothing, noteBox);
    } else {
      display.setCurrent(listofDevices);
    }
  }



Step 2: Start the service discovery on discovered devices
Since our aim in this tip is to allow data transfer from our MIDlet to a compatible device, we need to find services on the discovered devices that enable this goal. To do so, we need to specify the correct attributes and UUIDs in our service discovery process. The following code shows how to do so:


  agent.searchServices(
    null,
    new UUID[] {new UUID(0x1105L)}, // we want the OBEX PUSH Profile
    device,
    this);



As you may guess, the code uses the local agent that we had used earlier to search for devices. We are not after a particular set of attributes, so we pass null as the first parameter, but the UUID must be OBEX PUSH profile, as this is the most open way of transferring data.

We talked about the DiscoveryListener interface which has two other methods that can be used to employ discovered services. These two methods are servicesDiscovered(int transID, ServiceRecord[] servRecord) and serviceSearchCompleted(int transID, int respCode). As the names
suggest, the first method is called each time a service is discovered, while the second method is called when the service process has completed.

Each time a service is discovered, we need to find out the connection URL for that particular service on the respective device. This connection URL will be used to make the OBEX connection for putting our data across, and consists of the Bluetooth hardware address of the device, among other things. In the code below, this connection URL is retrieved in the servicesDiscovered method:


String connURL = servRecord[i].getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT, false);


With this connection URL, we can now move to the process of transferring our data across to the discovered device.

Step 3: Send data using OBEX PUT
In this MIDlet, we are going to allow the user to type some text as a note, and then send that across using the discovered device/service. To do so,
we will need the connection URL we got in the previous step (and of course, the note data as a String).


    // open a client session
    ClientSession clientSession =
      (ClientSession) Connector.open(connURL);

    // connect using no headers
    clientSession.connect(null);

    if(rHeaders.getResponseCode() != ResponseCodes.OBEX_HTTP_OK) {
      // the connection could not be established
      handleError(
        new Exception("Remote client returned invalid response code: " +
          rHeaders.getResponseCode()));
      return;
    }

    // if we are here, then response code was ok

    // create a new set of headers
    HeaderSet headers = clientSession.createHeaderSet();
    headers.setHeader(
      HeaderSet.LENGTH,
      new Long(noteBox.getString().length()));
    headers.setHeader(HeaderSet.NAME, "myNote.txt");
    headers.setHeader(HeaderSet.TYPE, "text/plain");

    // create an operation using the headers we have just created
    Operation op = clientSession.put(headers);

    // on this operation, create the output stream
    OutputStream out = op.openOutputStream();

    // and send the note
    out.write(noteBox.getString().getBytes());



To send the data, a client session is opened and a connection established with empty headers. At this point, your target device will ask for confirmation of  receipt of data from a new device. It may also ask you for a passkey if you have never paired the devices before.

Once the connection is established, some headers that explain the purpose of the data are created, and a new Operation created with these headers. The Operation is then used to send the data via the available OutputStream.

The received note will be available in the default Bluetooth exchange folder on the target device.


Resources

  Source code as a Netbeans project
  Bluetooth JSR 82 API



Three Reasons Why Your Next Java ME Mobile Application Should Include JavaFX Mobile
2009-02-06T12:01:11-08:00
By Bruce Hopkins

Let's assume that you're in the middle of your development cycle, and you realize that your mobile application needs to perform some very important but non-GUI-related operations such as:

 Discover a local Bluetooth device in the vicinity
 Communicate with a SIP registrar or proxy
 Determine your geo-location via a GPS device


So now what do you do? You want to write your killer-app using great declarative syntax of JavaFX, but you also realize that the Java standard specifications for Bluetooth wireless technology (JSR-82), SIP communication (JSR-180), and location-based application development (JSR-179) and are available as Java ME APIs.

Fortunately, the JavaFX runtime is completely dependent upon (and compatible with) the Java virtual machine (JVM). Simply stated, it means the following:

 Your JavaFX Mobile application has no restrictions on calling any class bundled in the JAR or any JSR API library that's present on the handset.
 Your JavaFX Desktop application will work seamlessly upon any deployment platform that has the current version of the JRE:

 For Windows machines, this will be Java 6, update 11 (or later)
 For Mac OS X machines, this will be Java 5, update 13 (or later)


Independent of the operating system, your JavaFX Desktop application will also be able to call any class that's bundled in the JAR package for your desktop application. Note: On the Windows desktop, JavaFX runs on Java 5 and it degrades gracefully (for example, the Drag2Install feature does not work) — that is, it does not break your application.

Read the full article,  with source code.


Notes from the Java Mobile, Media & Embedded Developer Days
2009-01-21T16:16:32-08:00
January 21, 2009, Wednesday. Sun Microsystems campus, Santa Clara, Caifornia.



These are notes from the presentations I attended at the Java Mobile, Media & Embedded Developer Days (M3DD). For more details, please go to the M3DD website and view the specific presentation's slides.


Sun Microsystems Mobile and Embedded community manager Roger Brinkley and evangelist Terrence Barr briefly welcomed the group to the second developer days, sponsored by Sony Ericsson and Sun Microsystems, then launched into the packed agenda. While the numbers rose and fell during the day, there were some 100 participants at the conference and another 150 participating via the live stream.


Marketing VP Eric Klein and Engineering VP Jeet Kaul gave the keynote speech. Eric stressed that the 2009 keywords for Java are "open" and "expressive." Eric noted that customers today consume and create business and personal content 24x7, across the screens of their life (mobile, desktop, television).


Eric spent some minutes reviewing Sun's "open" history, including the open collaboration around Java for over 12 years, resulting in Java being completely open source. Today's focus is on using Java to create a rich, immersive, expressive platform, so that developers can solve complex customer problems, using multiple data sources. The 6.5 million Java developers worldwide can combine with the 8 million content authors/web developers to grow a vibrant mobile platform. Jeet talked about his focus on streamlining the designer-developer workflow, embracing the native tools used by the community.


Jeet and Eric spoke of two current initiatives to address fragmentation issues: Java ODP and JavaFX. Java On Device Portal (ODP) allows the use of mobile widgets across global mobile devices, while JavaFX is positioned as the unifying technology for rich internet applications (RIA), web, and Java development across all screens (desktop, mobile, television). Eric also talked about Project Hydrazine (aka rocket fuel), which is an initiative to develop internet and operator services.


Florian Tournier, Sun senior product line manager, presented an overview of the Java mobility roadmap. First, the numbers:



 2.6 billion Java phone base

 6 billion Java Cards deployed

 840 million Java-enabled desktops

 40 million+ Blu-ray and TV devices




Florian stressed Sun's continuing commitment to open source and standards. Open source is exemplified by the regular phoneME releases -- phoneME Feature being the open-source implementation based on CLDC and MIDP, while phoneME Advanced is an open-source implementation of CDC for consumer devices and advanced phones -- and the open-sourcing of the LWUIT interface. LightWeight User Interface Toolkit (LWUIT), a standalone library, creates rich UIs easily for Java apps, which runs on any CLDC 1.1/MIDP 2.0 device. Standards are demonstrated by the Mobile Service Architecture (MSA) platform for Java in wireless, industry initiatives against fragmentation, and popular development/testing tools.


For 2009, Florian foresees the return of the feature (as opposed to smart) phone, with increasingly expressive experiences. He sees more emphasis on the browser, so discussed JSR 290, the mobile browser APIs for Java ME, mobile web servers (such as the Sprint Titan architecture), and Java Card 3. Innovations in Java show up in MSA2/MIDP3 functionality, CDC on phone (Sprint Titan with OSGi), modularization (Java SE first, then Java ME), and testing and tools in the Java ME SDK, with CLDC/CDC and BD-J support.


Phil Bender of CableLabs was the speaker at the next talk I attended. tru2way is Java-based middleware that allows interactivity with the television set, without requiring cable-top boxes. OpenCable project is on java.net, and there will be a developers conference on February 10. CableLabs also has a Visiting Engineer program. Cognizant's visiting engineer did a TeenLocator app, ported from Cognizant's IMS app for mobile, that lets users find a family member's mobile phone and map its location with driving directions. 


The new Java TV standard for digital TV in Brazil came next, by Sun's Michael Lagally and Jens Pätzold. Interactive TV (TV plus apps) lets you augment A/V with Java apps, which are synchronized to the A/V content. Brazil has the world's largest dual terrestrial-mobile TV deployment. It has the world's 4th largest TV network (around 80 million viewers a day), so the Brazilian goverment has a standards body (Sistema Brasileiro de Televisao Digital, or SBTVD), which requested Sun to create royalty-free DTV specification. People use television to connect to the internet in Brazil, so it is used for many things as eGovernment apps (such as to obtain a driver's license).


Several lightning talks followed, with each person having 7 minutes to introduce his or her material. Patrick Curran talked about the Java Community Process (JCP). and noted there are 26 active Java ME JSRs. Nokia's Jackson Feijo Filho gave usability testing tips for mobile developers, including a usability checklist. Gail Rahn Frederick talked about multi-modal search in On Device Portals, and Medio Systems' handset-resident mobile search-driven ODP application, requiring JSR 135. SunLabs' Eric Arseneau showed a video on First, which will tie into his Project Squawk presentation on January 22.


Next, Ken Gilmer of Bug Labs talked about mobile Java on the BUG programmable and modular open-source gadget platform, which lets you use electronic building blocks to build personalized hardware devices. The BUG device is a mobile Linux computer in a small metal rectangle, the size of an older clunky mobile phone, with several pluggable modules (e.g., camera, LCD, GPS, and the lovely Von Hippel breakout board). It contains an OSGi runtime on a CDC JVM (Concierge on phoneME) and has an SDK with a virual BUG emulator. 


That's it for today's presentation notes. If you'd like to follow the rest of today's or tomorrow's sessions, you can stream the conference. If needed, find the instructions here.




Mixing MIDI, Tone, and Sampled Audio using MMAPI
2009-01-20T15:10:36-08:00
By Vikram Goyal
Mobile Media API (MMAPI) is a protocol- and format-agnostic API for playing
  and manipulating multimedia content in mobile devices. It is a diverse API and
  handles several different types of media seamlessly, depending upon device capabilities.
  In this tech tip, you will learn how to mix and play multiple media content
  at the same time.
Understanding the issues of mixing in MMAPI
On the face of it, mixing sounds in a mobile applications is a desirable attribute
  to have, especially for multimedia-rich applications like games. MMAPI provides
  you the ability to mix different media, but there are pitfalls. The following
  sections describe some of these issues.
Device fragmentation
MMAPI implementations that return a value of true for supports.mixing system
  property should, in theory, be able to do the following.

  Support the playing of at least two tones simultaneously,
  Use Manager.playTone() when another player instance
    is playing back audio, and
  Support the playback of at least two instances of audio players.

In practice, not all MMAPI implementations follow these guidelines. This is
  due to device fragmentation. You should consult the design guidelines supplied
  by the device manufacturer to find out the capabilities of the device that you
  are working with.
Multiple player instances
With multiple player instances active in an application, there is a danger
  of too many resources being taken up to service these instances. When a player
  instance is in a prefetched/realized state, it will become a memory liability
  if kept around for a long time, especially because player instances in this
  state can request exclusive access to system resources, like the audio hardware.
  Thus, even if your device's MMAPI implementation allows for more than 2 player
  instances to be active at any time, it is prudent to keep this number low.
MIDI, tones, and sampled audio
As I said earlier, what can be mixed depends on your device's MMAPI implementation.
  Generally, most implementations will allow you to mix one instance of sampled
  audio and one instance of either a simple tone or MIDI sound, or both.
Putting together the code
Mixing sounds is a common feature in games where a background sound plays
  throughout the game, while various user or application events generate their
  own short lived sounds. In the following example, I will use a basic sampled
  audio as a background score, while various events during the game play will
  be mixed using MIDI and Tone control. The example is created and run using Netbeans
  6.5. Make sure that MMAPI is selected as an optional API while
  creating this application, as MIDIControl is not part of the basic MIDP 2.0
  MMAPI package.

When you run this code (supplied as a Netbeans project),
  you will be able to mix a MIDI sound and a system-generated tone with the continuous
  background music. This is tested in Sun Wireless Toolkit 2.2 supplied with Netbeans.
  If you run this in other toolkits, or better still, on an actual device, you
  will need to make sure that MIDIControl is supported.
Resources

  Source code as a Netbeans project
  Mobile Media API
  Mobile
    Media API Book



EXAMPLE SOURCE CODE

/*
 * TechnicalTipMIDlet.java
 *
 */

import javax.microedition.media.*;
import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;
import javax.microedition.media.control.MIDIControl;

/*
 * TechnicalTipMIDlet mixes audio, MIDI and tone
 * @author  Vikram Goyal
 */
public class TechnicalTipMIDlet extends MIDlet implements CommandListener {

  // define variables

  // the players for background music and MIDI
  private Player backgroundMusic = null;
  private Player aPlayer = null;

  // the MIDIControl extracted from aPlayer
  private MIDIControl mControl = null;

  // display items, the display
  private Display display = null;

  // and an alert
  private Alert alert = null;

  // commands to exit, for aCommand (MIDI) and bCommand (tone)
  private Command exitCommand = null;
  private Command aCommand = null;
  private Command bCommand = null;

  public TechnicalTipMIDlet() {

    // initialize the display
    display = Display.getDisplay(this);

    // a message for the user
    alert = new Alert("Message");
    alert.setString("Press A to play a tone, Press B to play a MIDI");
    alert.setTimeout(Alert.FOREVER);

    // create commands
    exitCommand = new Command("Exit", Command.EXIT, 1);
    aCommand = new Command("A", Command.ITEM, 1);
    bCommand = new Command("B", Command.ITEM, 1);

    // add to alert
    alert.addCommand(exitCommand);
    alert.addCommand(aCommand);
    alert.addCommand(bCommand);

    // set this class as command listener
    alert.setCommandListener(this);

    // and initialize the player instances
    initialize();
  }

  private void initialize() {

    // create and prefetch player instances
    try {

      // for the background music, load a simple wav file and put it on
      // infinite loop
      backgroundMusic =
        Manager.createPlayer(
          getClass().getResourceAsStream("music.wav"), "audio/x-wav");
      backgroundMusic.prefetch();
      backgroundMusic.setLoopCount(-1);

      // create the MIDI player, prefetch
      aPlayer = Manager.createPlayer(Manager.MIDI_DEVICE_LOCATOR);
      aPlayer.prefetch();

      // and extract the MIDIControl
      mControl =
        (MIDIControl)aPlayer.getControl(
          "javax.microedition.media.control.MIDIControl");

    } catch(Exception ex) {
      handleError(ex);
    }
  }

  public void commandAction(Command cmd, Displayable disp) {

    // handle the exit command
    if(cmd == exitCommand) {
      destroyApp(true);
      notifyDestroyed();
      return;
    }

    try {

      // if it's the aCommand
      if(cmd == aCommand) {

        // play a short MIDI event
        mControl.shortMidiEvent(MIDIControl.NOTE_ON | 11, 60, 100);
      }

      if(cmd == bCommand) {

        // if bCommand, use the Manager class to play a simple tone
        Manager.playTone(61, 1000, 100);
      }
    } catch(Exception ex) {
      handleError(ex);
    }
  }

  public void startApp() {

    try {

      // start the background music if it was created successfully
      if(backgroundMusic != null) backgroundMusic.start();
      else handleError(new Exception("Error with background player"));
    } catch(Exception ex) { handleError(ex); }

    display.setCurrent(alert);
  }

  public void pauseApp() {
  }

  public void destroyApp(boolean unconditional) {

    try {

      // close players
      if(backgroundMusic != null) {
        backgroundMusic.close();
        backgroundMusic = null;
      }

      if(aPlayer != null) {
        aPlayer.close();
        aPlayer = null;
      }

    } catch(Exception e) {
      handleError(e);
    }

  }

  // handles errors
  private void handleError(Exception ex) {
    alert.setTitle("Error");
    alert.setString(ex.getMessage());
    display.setCurrent(alert);
    ex.printStackTrace();
  }
}



Vikram Goyal is the author of Pro Java ME MMAPI, published by Apress. This book explains how to add audio, video and other multimedia capabilities to a Java-enabled phone. Vikram is also the author of the Jakarta Commons Online Bookshelf and helps manage a free craft projects website.


Blu-ray Disc Application Development with Java ME, Part 2: Responding to User Input
2009-01-07T15:55:34-08:00
Bruce Hopkins serves up Part 2 of his series on Blu-ray Disc Java development.



Part 1 introduces the BD-J platform and discusses the significant differences between the system requirements for developing, compared to playing, Blu-ray content. Additionally, we learn that the BD-J platform comprises various other supporting APIs, including GEM/MHP (Globally Executable Multi Home Platform) and Java TV. We are introduced to the application lifecycle of BD-J Xlets.



In Part 2, Hopkins delves into the Java ME SDK 3.0, which is the perfect tool for all Java ME development — whether you're doing Blu-ray application development or mobile phone application development. The Java ME SDK 3.0 provides substantial enhancements to its predecessor, the Wireless Toolkit for CLDC 2.5, mainly due to the fact that it allows developers the ability to author, edit, and compile all Java ME applications — especially of course, BD-J applications. Using the BD-J APIs, developers can create Java ME applications for all Blu-ray disc players, including the Sony PlayStation 3 gaming console.



Read the full article





Early Access to Java On Device Portal SDK
2008-12-09T21:53:33-08:00
A Java mobile widget is a small chunk of Java ME code installed and operated by the Java On Device Portal (Java ODP) technology.


While other Java ODP solutions force developers to write mobile widgets using a proprietary scripting language, the Java ODP platform leverages Java ME technology. You can write widgets in pure Java and take advantage of Java's full capabilities, such as packages for Personal Information Management (PIM), location-based services (LBS), multimedia, and more.





Register here to join program to receive access to the Early Access SDK.




JavaFX and JNLPs: How to Develop and Run JavaFX Applets and Applications Offline
2008-12-03T21:42:54-08:00
By Thomas Ng


While developing your JavaFX applet or application by using NetBeans IDE 6.5 for the JavaFX 1.0 platform, you might want to run the JavaFX application/applet offline for debugging and testing purposes. Following are the steps to run the JavaFX application or applet when your machine is disconnected from the network.



Requirements:  


You must have Java SE Development Kit (JDK) 6 Update 10 (or later) installed on your local machine.



Your applet or application must be JNLP enabled.



1. Download the following files to your local machine:

   
http://java.com/js/deployJava.js 

   http://dl.javafx.com/dtfx.js

   http://dl.javafx.com/javafx-loading-100x100.gif

   http://dl.javafx.com/javafx-loading-25x25.gif



2. Save the files to a local directory on your machine. For example:

   
c:\offline\deployJava.js

   c:\offline\dtfx.js

   c:\offline\javafx-loading-100x100.gif

   c:\oflline\javafx-loading-25x25.gif



3. Edit the dtfx.js file:

   
a. Replace the reference to http://java.com/js/deployJava.js with file:/c:/offline/deployJava.js.

   b. Replace the reference to http://dl.javafx.com/javafx-loading-100x100.gif with file:/c:/offline/javafx-loading-100x100.gif.

   c. Replace the reference to http://dl.javafx.com/javafx-loading-25x25.gif with file:/c:/offline/javafx-loading-25x25.gif.



4. While your machine is connected to the network, run the following command, which ensures that the latest JavaFX runtime is installed into your local cache:

   
javaws -import http://dl.javafx.com/javafx-cache.jnlp

This command ensures the latest JavaFX runtime is cached in your system. You will see a Java splash screen, followed by a progress dialog box, if any download takes place.  After that, the command will exit silently, which means you now have the latest JavaFX runtime cached. If an error is encountered, an error dialog box  appears.




5. Disconnect your machine from the network.



6. Ensure that the JNLP file for your JavaFX applet or application uses the following <extension> tag for its JavaFX runtime:

   
<extension name="JavaFX Runtime" href="http://dl.javafx.com/javafx-rt.jnlp"/>

   This is the default that is generated by the NetBeans IDE. This allows your application/applet to be launched offline by using the cached JavaFX runtime.



7. In your applet or application HTML page, change the reference of dtfx.js to your local copy.

   
a. For example, find this reference: <script src="http://dl.javafx.com/dtfx.js"></script>

   b. Change it to the following: <script src="file:/c:/offline/dtfx.js"></script>



8. Run your application or applet offline.



The compile and run functions of the NetBeans IDE always regenerate the HTML and JNLP files of your JavaFX applet or application and overwrite the changes you made to default value of http://dl.javafx.com instead of to your local copy. Therefore, you must make a copy of these offline-specific HTML and JNLP files and navigate to them directly when running offline. Remember to change the JNLP href in each offline JNLP file that points to the offline copy.



You can continue to work on your JavaFX applets and applications while your computer is offline.





Thomas Ng is a software engineer in the Java Deployment team at Sun Microsystems. He has worked on developing Java Web Start software since version 1.0.




Report from Africa: A Java ME MIDlet for User-Generated Localization
2008-11-03T16:14:43-08:00
This article is by J.D. Moore (User Experience manager, Emerging Market Services, Nokia) and Daniel Orwa Ochieng (lecturer at the School of Computing and Informatics at the University of Nairobi's College of Biological and Physical Sciences, Kenya).



Mobile user-interface heuristics have shown these factors as critical in ease-of-use:



 Be consistent and build on experiences found locally in the user's environment

 Offer efficient menus, avoiding deep hierarchies -- particularly critical where there is rampant illiteracy.

 Provide clear feedback in the local language, for optimum comprehension.

 Let the user be in control, including decisions on resource usage (cost control).

 Simplify dialog boxes and navigation, and expect to deal with diversity via a simple user interface.

 Offer useful text labels with localized iconography (culturally sensitive).




As an example of these theories in action, Gergely Herenyi of Nokia developed an FM Radio Reference MIDlet, posted on the Nokia Forum. The MIDlet supports user-generated localization for an application to connect people to community radio stations. You can download the full source code from that site as well.



Read the full article
 




Asynchronous Communications with Java ME and SIP: Part 2
2008-10-31T09:53:04-07:00
By Bruce Hopkins

As you may recall from Part 1 of this series, I showed you two example applications that used the Session Initiation Protocol (SIP) to send a simple message asynchronously from one application to the other. In this tech tip, we are going to explore why the REGISTER method type is important and learn how to use it. 

The SIP protocol supports the following method types when SIP devices are communicating:


 ACK MESSAGE REFER
 BYE NOTIFY REGISTER
 CANCEL OPTIONS SUBSCRIBE
 INFO PRACK UPDATE
 INVITE PUBLISH  


In the previous example, you saw how easy it was for each user to communicate with each other using the MESSAGE method type. This was, of course, due to the fact that each user had a routable IP address, and there were no barriers in place (such as a firewall) to impede the communication between the devices. This gets a little tricky, however, when one or both of the users are located behind a firewall or NAT proxy as shown in Figure 1.



Figure 1. Incoming Requests to Devices Behind a Firewall Are Blocked

If you're lucky, you can always ask the network administrator at your organization to open a port on the firewall for your device. However, that solution is definitely not scalable -- what if other people in your company wanted a port open for their devices, too?  Additionally, what would you need to do if the IP address of your mobile device changed? Your network administrator would have to reconfigure the firewall to point to your new address. Figure 2, below, shows the scalability problem if you open a port on the firewall for each SIP device.

 

Figure 2: Opening Individual Ports on the Firewall for Incoming SIP Requests Is Not a Scalable Solution

Obviously, there must be a scalable solution for multiple SIP devices to communicate if one or more of them are located behind a firewall. Fortunately, that's where the REGISTER method type comes into play. As you can see in Figures 3 and 4 below, the use of a SIP proxy and the REGISTER method type provide a simple, yet scalable solution. When a SIP device is behind a firewall, it needs to send a REGISTER method type to the external SIP proxy located outside the firewall. For the purposes of this tech tip, the external SIP proxy will also act as a registrar.


 
Figure 3. REGISTER Requests are Sent Directly to External SIP Proxy


 
Figure 4. Incoming SIP Messages Are Now Routed to the Proper Devices

What happens when your SIP device get a new IP address? All it needs to do is send a new RIGISTER request to the SIP proxy with its new IP address – and that’s it! The SIP Proxy will route all messages to your device now that it knows how to contact you. 

If you want to try this out yourself, all you need to do is to standup the embedded SIP Proxy/Registrar inside the Sun Java Wireless Toolkit 2.5.2 application. To start the SIP proxy, execute the “Utilities” application with the Wireless Toolkit program group. After the Utilities application starts, click on the “Start SIP Server” option. After the server starts, you can then now register yourself with the SIP Proxy by sending to it a REGISTER message. The code in Listing 1 provides a practical example on how it is done:

    public void register(final SipClientConnectionListener listener, final Thread waitFor){
        Thread t = new Thread() {
                public void run() {
                    runGauge();

                    try {
                        try {
                            if (waitFor != null) {
                                waitFor.join();
                            } else {
                            }
                        } catch (InterruptedException ie) {
                        }

                        scc = (SipClientConnection)Connector.open("sip:" + proxyAddress +
                                ":5060;transport=udp");
                        scc.setListener(listener);
                        scc.initRequest("REGISTER", scn);

                        String adr =
                            myDisplayName + " ";
                        scc.setHeader("To", adr);
                        scc.setHeader("From", adr);
                        scc.setHeader("Content-Length", "0");
                        scc.setHeader("Max-Forwards", "6");
                        uaStatus.setStatus(REGISTERING);
                        scc.send();
                        uaStatus.waitUntilChanged();
                        progressGaugeFinished = true;
                    } catch (Exception e) {
                        e.printStackTrace();
                        failMessage = e.getMessage();
                        commandAction(failedCmd, currentDisplay);

                        return;
                    }
                }
            };

        t.start();
    }


Listing 1. Using the JSR-180 API to Create and Send a Register Request

The following image shows the results of the REGISTER request that was sent to my SIP Proxy. As you can see, I am now registered with the proxy. Now anyone can send a message to me via the proxy. Be sure to note that the proxy also functions a handy debug tool, and it shows you the contents of the SIP messages that it proxies.

 

Figure 5. The Result of the REGISTER Request Sent to the SIP Proxy

Conclusion

It doesn’t take a lot of effort to use the JSR-180 API to register your device with a SIP Proxy/Registrar. If you’re looking for a fully functioning example, be sure to try out the GoSIP demo application in the Sun Java Wireless Toolkit 2.5.2*. This application works out-of-the-box with the embedded SIP Proxy in the Wireless Toolkit, so that you can register multiple devices and to communicate via the proxy.

*NOTE: The Sun Wireless Toolkit is called the Java ME SDK as of version 3.0.



Bluetooth and GPS: Part 2 - Parsing GPS Data and Rendering a Map
2008-10-27T19:13:23-07:00
By Bruce Hopkins


This article shows how easy it is to use the JSR-82 (Bluetooth) API to access the data from a Bluetooth-enabled GPS receiver, parse the data streams, and obtain the coordinates of current location. Additionally, you'll see how to formulate the HTTP request to access an external mapping service, use JSR-172 (XML Parsing and Web Services) API to parse the result, and make the final request to obtain the map image. Both JSR-82 and JSR-172 are included in the Java ME MSA standard.


Read the full article.


Also, see the Follow Up to this series, where Bruce Hopkins answers questions from readers of this series.




Blu-ray Disc Application Development with Java ME
2008-09-16T11:51:35-07:00
By Bruce Hopkins


The Java platform for Blue-ray disc players is called BD-J. In the first part of this series, I'm going to cover the following topics:


    * Basic Requirements for BD-J Development

    * What the BD-J Platform Can Do

    * BD-J Specification and APIs

    * Understanding the Blu-ray Profiles

    * Xlets and Xlet Lifecycles

    * Creating Your First BD-J Application


Included is sample code that creates a simple application that implements all the Xlet lifecycle methods. It performs a very simple operation: writing text on the screen.


I'm going to assume that you have absolutely no Java ME or video-content creation experience whatsoever. Having that said, let's get started.


Continue on to the full article




Using JavaScript Object Notation (JSON) in Java ME for Data Interchange
2008-09-04T20:19:09-07:00
In mobile applications, developers typically rely on home-grown data-interchange formats or on the Extensible Markup Language (XML). The advantage of the former is that it can be tailored to particular situations for the purpose of maximizing performance and/or computational resources. The advantage of the latter, when used over HTTP, is that it is a de facto standard for data interchange. In addition, the text-based/human-readable representation used in XML makes it easier to debug.


Yet these two approaches also have disadvantages, one being proprietary in nature, non-standard, and potentially non-interoperable, while the other one could be considered too heavy and verbose for data representation, again this is especially true for mobile and embedded applications. 


An alternative to consider is JSON, a lightweight data-interchange format. JSON is defined as part of JavaScript (ECMAScript) scripting language. Being native to JavaScript, JSON is ideal for browser-based applications. But JSON is not limited to JavaScript, and its lightweight characteristics make it very attractive for mobile and embedded applications in general.


This article covers the following topics:


- JSON-Supported Data Types

- JSON on Java ME

- Using JSON

- The Core JSON JSONObject Class  	

- The Example DataTypes Class

- Serializing to JSON: Generating JSON Text

- Deserializing JSON: Initializing the Class from JSON Text

- Using the Serialization Methods


Read the full article




JavaFX Preview SDK - "Experts" Q&A
2008-08-25T13:26:26-07:00
During the week of August 18, 2008, we encouraged you to "Ask the Experts" your questions about the recent JavaFX Preview SDK release. In this session, our experts were Joshua Marinacci, Martin Brehovsky, and Lawrence McDonough of the JavaFX engineering team. Jeff Dinkins, engineering manager for Java Graphics & Media, also pitched in for one question.


You can read a transcript of the session. The following topics are addressed:


•	Using a node-based approach versus Swing component-based approach

•	Putting a layout component in a Frame object or a layout component

•	Getting different results when invoking static methods on a class

•	Deploying applets

•	Decreasing the Java installation time and size

•	Comparing Java Server Faces (JSF) and JavaFX

•	Working with Hibernate and Seam

•	Adding more components

•	Developing a web-mapping/tile-based server solution in JavaFX versus JavaScript

•	Working with the previous release's Eclipse plugin

•	Supporting the designer-developer workflow

•	Using multiple inheritance versus interfaces

•	Improving the sample applications

•	Communicating with applets dragged outside the browser

•	Using data binding with Java objects

•	Using traditional web technologies for javafx.com site

•	Installing JavaFX 

•	Open-sourcing the JavaFX platform

•	Supporting javafx.ext.swing classes and multiline formatted text

•	Developing third-party components

•	Providing database-driven samples

•	Providing local persistence storage (or embedded database) 

•	Building graphic assets for use in JavaFX

•	Using the Scene Graph UI

•	Persisting UI state and user data

•	Using transparent backgrounds

•	Needing more JavaFX documentation

•	Defining the tween keyword

•	Encoding/decoding video formats and audio types




Creating a Custom Scrollable Table with JavaFX
2008-08-19T15:04:28-07:00
JavaFX expert Jim Weaver continues his series of articles with this latest one, TableNode: Creating a Custom Scrollable Table in JavaFX.


In this collaborative series,  he works with graphics designer Mark Dingman of Malden Labs on an imaginary Sound Beans application. The objectives are to show how to create custom UI controls in JavaFX, and to provide a case study in how a graphics designer and an application developer can work together effectively in developing JavaFX applications. Each 

article contains the source code and Java Web Start to run the application.


Read the article series   in his JavaFXpert.com blog.  




Ask the Experts: JavaFX Preview, August 18-22
2008-08-07T16:57:00-07:00
The JavaFX family of products includes the tools and platform SDK that developers, web scripters, and designers need to create dynamic applications for the next generation of web-delivered content. Sun recently released a JavaFX Preview designed to help early adopters become familiar with JavaFX.


If you have a question about the JavaFX Preview, post your questions during this session and get answers from three key members of Sun's JavaFX engineering team: Josh Marinacci, Martin Brehovsky, and Larry McDonough.


Typically, a one week period is designated for questions on a specific Ask the Experts topic. You can submit a question on that topic any time during that week. We'll collect the questions periodically and send them to the experts. We'll then post a selected set of questions and answers. Although the experts will try to answer as many questions as feasible, there is no guarantee that all questions will be answered.


Get more information at the Ask The Experts website.




JavaFX Learning Curve Journal Updates
2008-07-31T10:16:28-07:00
In August and September 2007, the Sun Developer Network staff started a Learning Curve Journal, a series designed to help users get started with the JavaFX Script programming language (shortened to JavaFX Script hereafter). A number of significant advances have been made to the language since then. Perhaps most important is the availability of a compiler-based version of JavaFX Script, which replaces the earlier interpreter-based version of the language. The Learning Curve Journal described the use of the interpreter-based version of the language. The Learning Curve Journal has been updated to show you how to use the compiler-based version of the language. Other changes have been made to make the articles current.


Part 1: Exploring JavaFX Script gets you started with a simple JavaFX program, that is, a simple program written in the JavaFX Script language. You'll learn how to set up your environment for programming in JavaFX Script and how to build and run a JavaFX program. 


Part 2: Declarative User Interfaces focuses on the declarative style of coding enabled by JavaFX Script. You'll see how this style can make the code for a graphical application simpler and more intuitive. 


Part 3: JavaFX Script Functions shows you how to use JavaFX Script functions to implement actions in a Java FX program.




Bluetooth and GPS: Part 1 - Reading Wireless Serial Port Data
2008-07-16T15:26:29-07:00
For some developers, working with wireless technologies can be daunting -- and sometimes downright intimidating. When communication is wireless, you can't just "look up" and see, for instance, 1 MB of data going by. In addition, it is really difficult to debug wireless applications once they are deployed to a mobile device, since you don't have access to system traces or log files to pinpoint the errors while the application is running.


This technical article addresses the following tasks:


    * Helps demystify some wireless concepts using Bluetooth and the JSR-82 API

    * Shows how to run and debug Java ME Bluetooth applications on your desktop computer

    * Explains how to read data from a Bluetooth-enabled GPS device


The good news is that you're going to learn how to construct a low-cost solution that allows you to install, debug, and test your JSR-82 applications on your computer. I'm going to introduce to you the Mpowerplayer, a CLDC emulator for the computer that can be configured to behave like a JSR-82 Bluetooth-enabled phone. With this configuration, the Mpowerplayer will behave just like a JSR-82 Bluetooth-enabled mobile phone, but you'll have access to the System.out and have the ability to view stacktraces, both of which are essential in debugging your wireless application.


Read the full article and download the source code.


Also, see the Follow Up to this series, where Bruce Hopkins answers questions from readers of this series.




Digisoft.tv's John Allen on Interactive Television
2008-07-15T16:31:01-07:00
Sun Microsystems and DigiSoft.tv have each explored using Java technology to address the challenges related to content development for the IP-based interactive TV market. Developers face tough challenges writing and deploying applications for existing proprietary middleware platforms.


To address these developer challenges, Sun and DigiSoft worked together and, in April 2008, announced the general availability of a Java Platform, Micro Edition (Java ME) based client platform for IPTV set-top boxes (STBs). This client solution incorporates Sun's Java technology-based media client and Digisoft.tv's middleware/SDK. This combined solution is suitable for IP-based media receivers.


Sun's Sr. Product Line Manager for digital media, Jennifer Yonemitsu, recently sat down with Digisoft.tv CEO John Allen to discuss this joint solution.


Read the full interview.




Near-Field Communication and the Contactless Communication API (JSR 257)
2008-06-19T17:22:42-07:00
By C. Enrique Ortiz


Near-field Communication (NFC) is characterized as a very short-range radio communication technology with a lot of potential, especially when applied to mobile handsets. Imagine yourself using your cellphone to interact with posters, magazines, and even with products while at the store, and with such interaction initiating a request or search for related information in real-time. Other usages of NFC include the electronic wallet to make payments using your handset, the same way you do with your credit card. With NFC all this is possible. But NFC is still a young technology. That said, NFC-enabled handsets are being introduced into the market, and deployments and pilots around the world are occurring. This article explores NFC and how you can leverage it in your Java application by using the Contactless Communications API. Read the full article.




The Bluetooth Conundrum
2008-06-02T13:03:04-07:00
By Richard Marejka

Question: How do you programmatically detect the presence of the JSR 82 Bluetooth APIs?

Answer: It would be nice if the answer were this:

import	javax.microedition.*;
import	javax.bluetooth.*;

...

String	BluetoothVersion = System.getProperty( "bluetooth.api.version" );
boolean	isBluetoothHere  = false;

...

if ( BluetoothVersion != null )
	isBluetoothHere = true;


On a Bluetooth v1.0 device, the previous code will always result in:

BluetoothVersion = null;
isBluetoothHere  = false;


that is, a negative or a false negative detection of Bluetooth.

The reason it is not as simple as the first code sample lies in the first version of JSR 82 Bluetooth APIs. In the original Bluetooth specification, JSR 82 v1.0a (Apr 5, 2002), section 3.3.4 Device Properties states: "This API defines the additional system properties that may be retrieved by a call to LocalDevice.getProperty(), as shown in Table 3-2."

The table in question contains a bluetooth.api.version property that will return 1.0 if Bluetooth is supported. To correctly discover Bluetooth on a v1.0 device, the required code follows:

import	javax.bluetooth.*;

...

String	BluetoothVersion = null;
boolean	isBluetoothHere  = true;

...

try {
	Class.forName( "javax.bluetooth.LocalDevice" );    // does the class exist?

	BluetoothVersion = javax.bluetooth.LocalDevice.getProperty( "bluetooth.api.version" );

} catch( ClassNotFoundException cnf ) {    // class does not exist -> no Bluetooth
	isBluetoothHere  = false;
}


Access to javax.bluetooth.LocalDevice is required to determine if Bluetooth is present. The Class.forName() method is used to test for the presence of a class in the run-time environment. If the class is found, then LocalDevice can be safely accessed to retrieve the Bluetooth version.

This somewhat non-intuitive detection method was changed in JSR 82 v1.1 (Sep 02, 2006, Maintenance Release 2). Section 3.3.4 has been revised to include the sentence: "Additionally, all properties defined in the Bluetooth API and available through the LocalDevice.getProperty method MUST also be available through the CLDC System.getProperty() method."

The same section also defines the property/value pairs in Table 3-2:

bluetooth.api.version  "1.1"
obex.api.version       "1.1"


which means the System.getProperty() method will work as expected.

As for JSR 248 MSA: Bluetooth is conditionally mandatory; that is, if there is Bluetooth hardware then the JSR 82 APIs are present. Bluetooth v1.1 is part of both MSA and MSA Subset.

Lastly, note that the first code sample will still work and produce the correct answer on both Bluetooth 1.0 and 1.1 devices. In cases where there is no Bluetooth, the result is:

isBluetoothHere  = false;
BluetoothVersion = null;


or if Bluetooth is present, the result is either

isBluetoothHere  = true;
BluetoothVersion = "1.0";


or

isBluetoothHere  = true;
BluetoothVersion = "1.1";




Comparing Mobile Platforms: Java ME and Adobe Flash Lite
2008-05-27T22:57:54-07:00
By Bruce Hopkins


If you’re a mobile developer, you may have noticed that more devices these days are supporting Adobe Flash Lite. According to the latest figures, approximately 300 million devices in the market support some form of the Flash Lite specification. Of course that’s nothing compared to the 1.2 billion (yes, that’s with a “b”) Java ME devices that are currently available, but I thought that it would be worthwhile to see the strengths and weaknesses of each platform side by side. In the tables that follow, I’ll compare the latest and greatest specifications for both platforms in the following categories:


Graphics

Multimedia

Local Device Accessibility

Security

Network Connectivity

Miscellaneous


Our first category for comparison is graphics. As you can see in the table below, the Flash Lite 3 platform supports all the standard rasterized graphic formats and supports FLA (Flash format) and SVG formats for vector graphics. In my opinion, FLA is a superior vector graphics format compared to SVG, and the tools required to create sophisticated applications are easier (and more widely available) to use for FLA compared to SVG. So, the Flash Lite 3 platform is a worthy competitor in the graphics department for mobile applications, and it is easy to see why many Flash Lite applications are games. One downside, however, is that Flash Lite 3 has no support for 3D graphics.





When it comes to multimedia (the playback of various formats and codecs of audio and video). The Flash Lite 3 platform is a clear winner. It not only supports the Flash 8 video specification but also Sorensen video, which is an industry standard for compressed video. Both platforms support streaming audio and video, which is crucial when your mobile device needs to communicate with a media server.





How do the two platforms compare when you want to gain access to local resources on the mobile device? As you can see in the table below, the Java ME MSA specification gives the developer an unprecedented amount of access to local resources such as the GPS radio, camera, and microphone. 


This may be a little known fact: both platforms support the capability to initiate a request to the handset to dial a phone number. However, since the Java ME MSA platform can also read phonebook entries on the local device, it’s more suited for creating powerful business applications. Note that there are Java ME and Flash Lite implementations that do have access to sensor data from accelerometers, but such functionality is not a part of the Java ME MSA spec or Flash Lite 3.





In the security realm, both platforms support HTTPS, so you can use either platform to securely communicate with a SSL-enabled web server. However, applications that use the Java ME MSA platform can also use digital certificates for secure identification. MSA devices have the added ability to use various encryption algorithms to secure data at rest (that is, on the filesystem).





Which platform provides more options for connectivity when your mobile application needs to communicate with external resources? The following table gives you a good idea of what you can expect when you create a mobile application that needs to communicate to a networked or local device. As you can see, both platforms support the capability for mobile applications to initiate requests using raw TCP sockets or with the HTTP protocol. However, mobile devices that support the Java ME MSA standard have the additional capability to act as servers, and wait for incoming requests on various protocols on both TCP and UDP transports. This allows the mobile device to communicate in a peer-to-peer mode without the necessity of server-to-proxy requests between them. If you’re in server mode, your application doesn’t even need to be running in order to receive its data. The PushRegistry allows Java ME application to “wake up” upon an incoming network request. 


Mobile devices that adhere to the Java ME MSA standard also have the ability to use the local serial and infrared ports on the mobile device.





The following capabilities really didn’t fit in any of the categories discussed earlier in this article. For those of you who have never developed Flash Lite applications, you may be surprised to learn that it supports floating point math, XML parsing, and even TCP/IP networking without necessitating the use of a threading framework for its developers.





Conclusion



Each platform has its own strengths and weaknesses when it comes to mobile application development. Flash Lite-enabled devices are really good at displaying graphics and multimedia, which lends itself to several gaming applications. On the other hand, devices that support the Java ME MSA platform are the obvious choice when you need to communicate with Bluetooth devices, use location based services, capture audio/video, render 3D graphics, or perform any form of asynchronous communication. 


I’m really glad to see that one of the Java ME licensees, Sony Ericsson, has made significant progress on bridging the gap between both platforms with its Capuchin technology, which was announced in late April: "...a Java ME API that defines a bridge between the Java ME and Adobe Flash Lite programming environments. This API makes it possible to use Flash Lite as the front end and Java ME as the back end of applications, meaning that Flash tools can be used for UI design while still having access to all the phone services available to Java ME." Both platforms have made significant advances from their initial 1.0 versions. I can’t wait to see what’s on the horizon for both platforms as the standards evolve.


Bruce Hopkins is the author of the book, Bluetooth for Java (Apress Publishers), and is the creator of the JB-22 developer kit.




New Gaming Experiences with OpenGL ES and the Mobile Sensor API
2008-04-30T17:17:07-07:00
By Erik Hellman


Several mobile devices on the market today have a built in accelerometer, much like the one used in the controls for the Nintendo Wii. These can be used to detect motion and the current tilt of the device. Since the feedback from the accelerometer is near real-time, it provides a new way to interact with our devices.


We have just recently started to see the use of accelerometers in applications and games, and I believe that built-in accelerometers in mobile phones will become even more common as new mobile games appear. For Java ME, we already have an API for reading these accelerometers, the Mobile Sensor API (JSR-256). This article will describe a very simple game for a Sony Ericsson w910i that uses both the OpenGL ES API for Java ME and the Mobile Sensor API.


Read the full article




Asynchronous Communications with Java ME and SIP: Part I
2008-04-21T11:57:22-07:00
By Bruce Hopkins

This tech tip teaches developers how to use the JSR 180 APIs to communicate asynchronously using the SIP protocol.

Your mobile application needs to receive information from a server or from another mobile user via a server. Everything works fine when the communication between the mobile device and the server are synchronous. All you need to do is open a connection to send a request, and the server uses that same connection to return a response to you. 

The HTTP protocol is great for synchronous transactions, which happens billions of times a day when people access websites and web services all over the world. However, things get tricky when a web server needs to contact your web browser when the connection no longer exists. Since this is tax season for those of us in North America, consider the following concept. If you used a web application to submit your taxes, how did you get the response to inform you that your tax filing was accepted or rejected? You either got your response over an asynchronous protocol (like SMTP, also known as  email) or a polling mechanism had to be employed over a synchronous protocol (like HTTP) to check the status of the tax application. 

This is the classic problem: If your mobile application needs to receive a notification of some event, you either need to poll using a synchronous protocol or use an asynchronous protocol. If you have used Java ME for any significant amount of time, then you are already aware that every Java ME device has supported the HTTP protocol since MIDP 1.0. So, the purpose of this tech tip is to get developers up to use the JSR 180 APIs to communicate asynchronously using the SIP protocol. Fortunately, JSR 180 is a part of the MSA standard, so more and more mobile devices are supporting this API. 

In the following sample code, I show two MIDlets that will use the SIP protocol and the JSR 180 API to communicate asynchronously (and without needing a SIP server/proxy between them). However, before getting started, I need to list all the materials that required for you to run this example:

 
Sun Wireless Toolkit 2.5 for CLDC 

Yup, you don’t even need two computers to run the sender and the receiver applications. Both examples can be run from the same computer at the same time.


SipReceiver.java MIDlet

I’m going to assume that you’ve already had some experience creating a MIDlet before, so I’m not going to much detail on the MIDlet lifecycle or the constructor. There are  several tutorials available where you can get up to speed on Java ME basics if you need to: Learning Path: MIDlet Life Cycle, Wireless Development Tutorial, Part I, or Introduction to Mobility Java Technology. However, let’s take a look the first lines of code:

import javax.microedition.sip.*;

public class SipReceiver extends MIDlet implements CommandListener{

	public Display display;
	public long startTime;
	public Form form;
	public TextField portTextField;
	public ImageItem userImageItem;
	public Image userImage;
	public Command startCommand;
	public Command exitCommand ;
	public SipConnectionNotifier scn = null;
	public SipServerConnection ssc = null;


The SipServerConnection class is the class that binds to a port and listens for a incoming request. For all this to work, the SipServerConnection works hand-in-hand with a SipConnectionNotifier. The SipConnectionNotifier is an interface that you need to implement so that you can be notified when a SIP request has been received by your MIDlet. As you can see from the class declaration, I didn’t implement the SipConnectionNotifier  interface, because I prefer to have an inner class to handle all my I/O. The following code snippet  shows the details of my inner class, DataTransfer.

   class DataTransfer extends Thread implements SipServerConnectionListener {

      public void run(){

         try {
            if(scn != null)
               scn.close();
            scn = (SipConnectionNotifier) Connector.open("sip:" + portTextField.getString());
            scn.setListener(this);
            form.append("Listening to port: " + scn.getLocalPort());
         } catch(Exception ex) {
            ex.printStackTrace();
         }
      }

      public void notifyRequest(SipConnectionNotifier scn) {
         try {
            ssc = scn.acceptAndOpen();
            if(ssc.getMethod().equals("MESSAGE")) {
               String contentType = ssc.getHeader("Content-Type");
               String contentLength = ssc.getHeader("Content-Length");
               int length = Integer.parseInt(contentLength);
               if((contentType != null) && contentType.equals("text/plain")) {
                  InputStream is = ssc.openContentInputStream();
                  int i=0;
                  byte testBuffer[] = new byte[length];
                  i = is.read(testBuffer);

                  String message = new String(testBuffer, 0, i);

                  form.append(new StringItem("Subject:", ssc.getHeader("Subject")));
                  form.append(new StringItem("Message:", message));
               }
               ssc.initResponse(200);
               ssc.send();
                }
       
         } catch(IOException ex) {
            form.append("Exception: "+ex.getMessage());
         }
      }
   }


You should notice two obvious things: 

My inner class extends Thread, because all blocking I/O operations need to operate in a separate thread.
My inner class implements SipConnectionNotifier, which was explained earlier. Now that my class implements the SipConnectionNotifier, its notifyRequest() will be called when a new request comes in.


Now that you’ve seen the bulk of the work required to receive a SIP message, let’s take a look at the code required to send a message.


SipSender.java MIDlet

As in the previous example, I’m going to let an inner class do all my heavy lifting, so let's dive right in the inner class code to see what’s going on.

   class DataTransfer extends Thread implements SipClientConnectionListener{

      public void run() {
         SipClientConnection sc = null;
         try {
            sc = (SipClientConnection) Connector.open(addressTextField.getString());
            sc.setListener(this);
            String message = messageTextField.getString();
            sc.initRequest("MESSAGE", null);
            sc.setHeader("From", addressTextField.getString());
            sc.setHeader("Subject", subjectTextField.getString());
            sc.setHeader("Content-Type", "text/plain");
            sc.setHeader("Content-Length", "" + message.length());
            OutputStream os = sc.openContentOutputStream();
            os.write(message.getBytes());
            os.close(); 
       
         } catch(Exception e) {
            e.printStackTrace();
         }
      }

      public void notifyResponse(SipClientConnection scc) {
         try {
            scc.receive(1);
            form.append("notifyResponse: "+scc.getStatusCode()+" "+scc.getReasonPhrase());
            scc.close();
         } catch(Exception e) {
            form.append(e.getMessage());
         }
      }
   }


Once again, there are few things that I want to point out:

The inner class extends Thread for performance reasons, and you don’t want the entire application to hang when I/O requests are generated. 
We need to implement the interface SipClientConnectionListener, which forces us to implement the callback method notifyResponse(). The allows us to check the status code of our message. The SIP status code is very similar to HTTP, so a 200 status means that your request was successfully received and understood. 


The following images show the both applications running, using the Sun Wireless Toolkit.

  


Conclusion

As  you can see, it doesn’t take a lot of effort to the JSR 180 API to send and receive messages using the SIP protocol. The great thing about SIP is that its response codes are  modeled after the HTTP protocol, so most of you should feel very comfortable using the protocol. In Part 2, we’ll take a deeper look into the SIP protocol, and find out the benefits of using a Registrar or a Proxy.




Source Code

Following is the full source code for SipReceiver.java and SipSender.java.


SipReceiver.java
SipSender.java





The Future of Content Consumption: Which Screen?
2008-03-28T14:51:06-07:00
March 2008 - Liz Gannes from NewTeeVee moderated a Stanford/MIT Venture Lab panel discussion regarding two startups offering opposite approaches to long-form video content delivery: VUZE for delivering/viewing free (ad-supported) content on computers and VUDU for delivering/viewing fee-based content on TVs via a VUDU device.


Some of the terminology that got flung about follows:

- Long-form video (movies, sports events) versus short-form video (typical YouTube snippets)

- Tail comprises the specialized segments for vertical audiences (e.g., snowboarding events, documentaries on esoteric subjects)

- Leaning Forward vs Sitting Back - Younger people who are accustomed to viewing and interacting with content on their laptops "lean forward" to view 10 inches away; over 35 age range tends to "sit back" 10 feet away from TV and be broadcast to. Describes an attitude toward video, versus just the physical posture.

- Live - the definition of "Live" was debated by panelists/audience. In the end, there seemed agreement around a "Live Event" (e.g., a boxing match or a concert) being watched in a linear manner in real-time (no time-shifting via DVR), and "Live Broadcast" which would be watching the live event in a time-shifted manner (DVR). Agreement that even pausing for 5 seconds makes it no longer "live."


The panelists were Mark Jung, CEO, VUDU; Gilles BianRosa, CEO, VUZE; Ben Huang, Product Mgmt director, Microsoft TV; Gary Lauder, Managing Partner, Lauder Partners (venture capitalists); and Howard Hartenbaum, General Partner, Draper Richards (venture capitalists).


VUDU


Jung started off with a demo of VUDU, a closed-end peer-to-peer network for distribution storage via the VUDU boxes, each of which "volunteers" to serve any other VUDU boxes in its vicinity. Jung wants to merge the internet with TV on your TV (not on your laptop). The "special sauce" VUDU adds is the painstaking but small-footprint encoding to bring movies to DVD or Blu-ray quality. 


VUDU serves what he sees as the 2 kinds of viewers: those who know what they want to see and want to find it easily; those who was to be recommended to. VUDU lets you surf your TV the way you surf the internet. Jung believes such consumption will displace physical DVDs, pay-per-view, and broadcast TV consumption.


The UI makes aims to make the transaction process so easy that you (the consumer) don't realize how much you're spending -- for example, clicking a button to choose "Buy" rather than "Rent" in the middle of watching a video.  


Jung also said they are looking at adding a publishing channel using their API where independent filmmakers can publish their videos and decide how much to charge for them. There was criticism that this was a filter, but Jung noted that State Attorney Generals will quickly sue publishers for "indecent" content so they have to check for that.


VUZE


BianRosa then talked about VUZE's diametrically opposite approach, which is to serve content via laptops as "a global distribution and exchange channel for high-res digital content." He noted that as the numbers of subscribers/users grow, the numbers of views of tail content also increases, thus making it more defensible to serve up. 


VUZE is open-platform, uses open-source APIs, and offers open pricing/business models to content providers. He says that in surveys, more than half of those surveyed preferred "free" ad-supported viewing (15-30 second ads) versus paying for content.


There was discussion around the cost of content delivery over the internet. Vuze has filed a complaint with the FCC against an ISP for its alleged restrictions on what its  consumers are allowed to download.


DISCUSSION


Venture capitalist Hartenbaum observed that the trend is toward personalization. At his home (wife and kids), everyone watches different material on a different device because of divergent interests. He also noted that fewer and fewer people globally want to be served only American-generated content so what will have to change are the distribution rights/model.


Lauder (who owns a VUDU box) praised it as having a "really, really good user interface," which he believes is key -- a user's ability to quickly find the content she or he wants to view is critical.


Microsoft's Huang noted that Microsoft IS in people's living rooms already, via devices such as the XBox. He noted that people who have purchased a device are more willing to pay for content on that device -- $60 games, for example.


All in all, a thought-provoking session. It will be interesting to look back in another 12 months and see where both VUDU and VUZE are on the landscape.




Using Filters With the Java ME Device Matrix
2008-03-06T11:32:58-08:00
by Richard Marejka

Let's say you have a design for a mobile application, and you know what technology (JSR) is required by the platform. You then want to know: What handsets will support your design?

The SDN Device Matrix is a table that lists information on hundreds of devices that run Java ME technology.



Searching on Multiple Filters

To get the answer to your question about support for specific technology, use the Device Table Software Filter to select a set of multiple JSRs. When you click Go, the Device Matrix will show only those devices that satisfy your user-defined filter.

For example, to find all devices that support Bluetooth, CHAPI, CLDC 1.1, Location API, and Scalable Vector Graphics, do the following steps using the software filter list:


Hold down the left button on your mouse and click Bluetooth to select it in the list.
Hold down the CTRL key and, using your mouse, left-click CHAPI, CLDC 1.1, Location API, and Scalable 2D Vector Graphics.

 The following figure shows the software filter with two of the five selections visible in the scrolling list.


When you click Go, the table will display the search results set, as shown in the following figure.


Searching on MSA

To see the devices that support the platform of choice today, set the Software Filter to  MSA, the Mobile Services Architecture as defined in JSR 248. MSA comprises a set  of 17 JSRs (or 9 JSRs in the MSA subset case) that define a Java ME platform. It is becoming the platform of choice for mobile developers because it provides a stable and feature-rich deployment environment.

Sending Feedback

The Device Matrix database  is updated quarterly with devices from major manufacturers. You can submit comments or updates using the Corrections or updates link found top and center on the page.


Detecting Java ME Optional Packages
2008-02-06T14:40:45-08:00
By Eric Giguere

The Java ME platform comprises configurations, profiles, and optional packages. Like configures and profiles, an optional package is a set of APIs. Unlike a profile, however, it does not define a complete application environment. An optional package is always used with a configuration or a profile. It extends the runtime environment to support device capabilities that are not universal enough to be defined as part of a profile or that need to be shared by different profiles.

Consider the Wireless Messaging API (WMA), a set of classes for sending and receiving Short Message Service (SMS) messages. Because the WMA is an optional package, it can be included on any Java ME device with SMS capabilities, not just MIDP-enabled cellphones. If WMA were part of a specific profile, such as MIDP, its use would have been limited to that profile and its supersets.

Just like profiles and configurations, optional packages are specified through the Java Community Process. So each has its own reference implementation (RI) and test compatibility toolkit (TCK).

Note that it is the vendor of a Java runtime environment – in many cases, the device manufacturer – that controls which optional packages are available, just as it controls which configuration is used and which profiles are available. In general, it isn't possible to use an optional package if it isn't preloaded onto a device as part of the runtime environment. It takes some time after an optional package's specification has been finalized before implementations of the package appear in commercially available devices.

Using Optional Packages

For the application developer, an optional package is just another set of Java classes to place in the Java compiler's classpath. The classes are not packaged with the applications, of course, because the devices that support the optional package include them in their runtime environments.

To detect the presence or absence of an optional package, test for the existence of a class unique to the optional package:

    ...
    public static boolean isWMAPresent(){
        try {
            Class.forName(
                   "javax.wireless.messaging.MessageConnection" );
            return true;
        }
        catch( Exception e ){
            return false;
        }
    }
    ...


Choose the class to test with care. For example, the existence of the java.rmi.Remote interface does not imply that the RMI Optional Package (JSR 66) is supported, because the Personal Basis Profile includes the same interface as part of its support for inter-Xlet communication.

If an optional package is required for your application to function, make sure the application checks for its existence, and exits gracefully if it isn't found. Letting the application terminate with a cryptic Class not found error will confuse users.

Example Optional Packages

Optional packages are defined through the Java Community Process. For the complete list of optional packages, refer to the JCP web site for Java ME-related JSRs.


About the Author
Eric Giguere is a software developer and has written extensively on computing topics. He  holds BMath and MMath degrees in Computer Science.

ACK	MESSAGE	REFER
BYE	NOTIFY	REGISTER
CANCEL	OPTIONS	SUBSCRIBE
INFO	PRACK	UPDATE
INVITE	PUBLISH