Bluetooth Everywhere

As an application developer, you can easily understand the difference between the capabilities of a mobile device as opposed to those of a desktop or server. If you’re a Java developer creating mobile applications, you may have experienced some of the limitations of either the handset itself, the mobile operator’s network, or the Java ME framework on the device. The Mobile Information Device Profile (MIDP) 2.0 implementation is the most widely deployed Java ME framework, with over 2 billion mobile phones worldwide that are Java technology-enabled.

Continue reading the article at java.sun.com

Ok, do you remember my original post about the the lack of Java on major smartphone platforms? Well, here’s an updated list of the major smartphones today:

1.  iPhone 3GS
2. Motorola Droid
3. Palm Pre
4. Nokia N97
5. Nokia 5300/5800
6. Blackberry Storm 2
7. HTC Hero
8. Nokia N900

Now Alex pointed to the updated spec docs for the N97, which *now* show that the device runs Java ME CLDC. Please note that those spec docs for that device have historically shown that the N97 was supposed to run a JDK 1.4 JVM, but Nokia decided to update the docs. Thanks for informing me about that Alex.

Additionally, Chris pointed out the Java ME CDC is still alive on the Sprint Titan platform. Thanks Chris!

However, I still make the case that Java ME CDC (the most powerful and capable mobile Java platform) is NOT on any of the devices that are listed above. Sun will have to do something quickly in order to make Java relevant on mobile devices again. Did you know that by the end of 2010, Flash applications will be on all of the devices listed above?

Here’s what Sun needs to do for MIDP 3.0 to launch it as the best mobile application framework.

1. Enable MIDP3.0 application code to natively compile to iPhone 3GS runtimes
2. Enable MIDP3.o application code to natively compile to Android 2.0 runtimes
3. Enable MIDP3.0 application code to natively compile to Palm Pre runtimes

This will enable the millions of Java developers to create mobile phone applications for the RELEVANT mobile platforms. I’m sorry to say that Java ME CDC is obsolete for mobile smartphones, and if Sun doesn’t do something quickly, MIDP 3.0 will be obsolete within 6 months (even before the spec is finalized).

Bluetooth 2.1 technology allows two devices near each other to communicate at a maximum speed of 3 Mb per second. In the grand scheme of wireless communication, Bluetooth is roughly two times faster than the data throughput of a 3G wireless phone but still 10 to 20 times slower than today’s Wi-Fi speeds.

More than one billion Bluetooth-enabled devices are currently on the market, and Bluetooth does a good job of transferring files that are smaller than 10 MB in size. However, due to the inherent nature of most wireless communication protocols, Bluetooth devices need to discover other Bluetooth devices, even if both devices are right next to each other. Finding a remote Bluetooth device is great, but what services does that remote Bluetooth device offer? If the remote device is a printer, does it offer the commonly used Basic Printing Profile (BPP) or the more advanced printing service known as the Hard Copy Cable Replacement Profile (HCRP)?

To find the available services on a remote Bluetooth device, you also need to search for a service. Bluetooth device-discovery and service-searching capabilities are great when you are trying to find any remote Bluetooth device in the vicinity that can suit your needs.

But device discovery and service searching are extremely time-consuming and frustrating to use when you’re trying to communicate with a device that’s right in front of you. This article shows you how to get Bluetooth applications to completely bypass the device-discovery and service-searching processes simply by using Near-Field Communication (NFC) technology and JSR 257: Contactless Communication API.

You can also find this article in the list of all articles on this site.

Every developer in their software development lifetime will eventually have to create user interfaces. For some developers, this stuff is easy. However, for folks like me, creating a good user interface is HARD. Of course, I know a slick user interface when I see one, it’s just very difficult for me to create one from scratch. Therefore, any frameworks that help in the process of creating a quick and pretty (not quick and dirty) UI is something that I always want to be aware of.

So if you’re a Java ME developer, and if you have created user interfaces, then you’re aware that there aren’t many UI frameworks available. One of the most recently announced UI toolkits is LWUIT (pronounced “lew-it”) and here’s a rundown of it’s features:

• LWUIT Designer - Allows creating themes and resources for LWUIT
• Swing Like MVC (Model View Controller)
• Layouts
• PLAF (Pluggable Look And Feel) & Themes
• Fonts
• Touch Screen
• Animations & Transitions
• Rich widgets
• 3D Integration
• Painters
• Modal Dialogs
• External Tools
• I18N/L10N
• SVG Integration

Well, the wonderful folks at Packt Publishing have graciously allowed me offered to offer to my readers Chapter 10 of the book, “LWUIT 1.1 for Java ME Developers”.

If you’d like to know more information about this book, and to see a full description, then browse over to the Packt website for more information. When my copy arrives this week, I hope to give you all a good review of the book later this month.  However, I think that you’ll enjoy the free chapter of the book, especially since it’s 26-pages-of-meaty-Java-ME-UI-goodness.

Ok, most of you know that I’m a proponent for Java ME. I love writing applications for mobile devices, and I’ve been doing it for a LONG time (over 10 years). I like this stuff so much, I even wrote a book about it. Java ME is so popular, it on over a billion mobile phones (remember, there’s a difference between mobile phones and smart phones). One of the major benefits for Java and Java ME is platform independence, but I’m starting to see an alarming trend in the industry. So, as an experiment, I want to you think of the major *touchscreen* smartphones. Here’s the ones that come to mind for me:

1.  iPhone 3G
2. Palm Pre
3. Nokia N97
4. Nokia 5800
5. Blackberry Storm
6.  Samsung Instinct
7. G1 (Google Android)
8. HTC Touch Diamond

Alright, now your list may have +/- a few phones, but your list should be quite similar to mine. Now, back in the day, we were told that Java ME CLDC was the JVM platform for the mass market mobile phones, and Java ME CDC was the JVM platform for high-end smartphones with extra processing power. Now today, touchscreen smartphones are truly high-end, so which of the phones in my list (or your list) come enabled out-of-the-box with Java ME CDC?

Maybe two of them — maybe.

If the device is a Samsung Instinct or HTC Touch Diamond, and if it came from Sprint, then there’s a high probability that it includes Java ME CDC (via Sprint Titan). I’m not too familiar with Sprint’s success with the Titan platform, so I could be wrong. Even Nokia (which has been a huge supporter of Java ME) put Java SE 1.4 on their new flagship device, the N97.

Folks, if you ask me, this is not a good sign. What is the platform independent language for touchscreen smart phones? Did you know that Flash runs on more than 1/2 of those devices. Hmmm…