Continue reading the article at java.sun.com

So, unless you’ve lost internet access for the last 6 months (wow, that’s a scary thought) you’ve probably heard that Apple is going to release a tablet computer this year. Now, I don’t plan to spend alot of time on contributing to Apple’s free-PR-scheme, but I do have to say something about it, because of all the hype.

So, I understand the purpose of the iPhone - it’s a big ‘ole iPod screen, with good web browsing, and downloadable apps. Yeah, it what the Apple Newton should have been. There are billions of mobile phones on the planet, so making the iPhone suited a need that already existed.

My concern however is that…

…I don’t need a tablet…

I use computers ALOT, and every computing scenario for me is already covered by:

• servers
• desktops
• laptops
• mobile phones

Watch-based computers never really took off because nobody really needed them. So, whenever Apple presents its new tablet this year, I want to see Steve Jobs convince me that I need a tablet, because right now, I don’t.

So did you hear the news about Bluetooth 4.0? Now, you many be wondering, “Why are they announcing all these new features in Bluetooth 4.0, when there’s hardly any 3.0 devices available?”. True, I agree with you there — I wish that there would be more Bluetooth 3.0 devices available so that my camera can download pictures to my PC, which I think will be one of the major use cases for Bluetooth 3.0. Now, before I explain Bluetooth 4.0, I want you all to do a little experiment for me. Do all remember the versions of 802.11? Let’s take a look  at them in chronological order:

• 802.11 - 1 Mb/s
• 802.11b - 11 Mb/s
• 802.11a - ~22 Mb/s
• 802.11g - 54 Mb/s
• 802.11n - ~100 Mb/s

Conceptually, from a generic-stupid-consumer’s-point-of-view, it’s easy to see that newer versions are FASTER than the older versions, even if the naming scheme seems out of place (in other words, 802.11a came after 802.11b). That’s easy stuff, right?

Well, Bluetooth 4.0 in my opinion will confuse the average-everyday-consumer because the new spec has nothing to do with increased data rates — it’s actually all about power consumption — which equates to lower data rates. So, Bluetooth 4.0 devices will run on a coin-cell battery for YEARS (which is cool), but it will communicate at a maximum of data rate of 1 Mb/s, which may be a problem to average consumers. Additionally, Bluetooth 3.0, 2.1, 2.0, 1.1 and 1.0 are all compatible technologies, so this means that a Bluetooth 1.0 device can communicate with a Bluetooth 3.0 device. Nice huh? Well Bluetooth 4.0 won’t be able to communicate with older Bluetooth devices (which is terrible), unless one of them includes the architectures for Bluetooth 4.0 and Bluetooth 3.0 (which increases the price).

So, the technology is great, but they’re going to have a hard time explaining 4.0 to the consumer.

Thanks,

Bruce

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).

It appears that it’s been a LONG time since I wrote a post. Sorry for the extended vacation, I’ve been busy working on a lot of stuff. Ok, let’s get back into the swing of things!

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.

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.

Please allow me make a short comment/rant on the importance of DUN for mobile and wireless developers. Last week, I talked about what DUN is, and how it fits with the other Bluetooth Profiles. However, I failed to explain the importance of this profile. Let me put it succinctly:

If you want to your laptop to access the internet, the you need THIS profile enabled on your mobile phone and your laptop.

Yes, I do realize that DUN *could* be used by desktop computers to access the internet as well, but desktop computers are stationary devices, and WiFi is better suited for that task since power consumption is not a issue.

Yes, I also realize that PDAs *could* use DUN to connect to the internet, but nobody makes PDAs anymore. In fact, now that Microsoft has renamed Windows Mobile to Windows Phone, then that’s a good indicator that the PDA market is dead.

Please note however, that if you have a data plan on your mobile phone, your network carrier does NOT want you to connect your laptop to the internet over DUN. This concept is called “tethering”, and the carriers have decided to make DUN a complicated and pricey issue. Therefore, if you want to use DUN, you will most likely need to:

1. contact your network carrier
2. tell them that you want to tether over Bluetooth
3. wait for them to scream and faint
4. They will then tell you how much EXTRA you need to pay in order to tether (whether you use Bluetooth or not)
5. They will also tell you the username and passcode to enter in order to access the network over DUN

That doesn’t sound fair, does it? If you had a normal smartphone application on your phone, it doesn’t need to know a passcode to access the network. However, it you want to tether your laptop, then you do need to enter a  passcode on your laptop in order to access the internet.

I’m very tempted to write a hack that allow users to bypass all that nonsense. I’ll be sure to let you know if I make up my mind.

Profile Name: Dial-up Networking Profile

Abbreviation: DUN

UUID:  0×1103

Description: The Dial-up Networking Profile (DUN) is a profile that largely depends on the functionality of the Serial Port Profile (SPP) in order to operate, as you can see from the image above. This profile is modeled after the connection mechanism that was widely used in the 1990’s for home computers to get access to the internet: the dial-up modem. Please note that even though dial-up modems are not available today, this profile is still widely used by laptops and other mobile devices to access the internet through a Bluetooth-enabled mobile phone.

Common Implementations: laptop computers, desktop computers, mobile phones

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…

This device has an accelerometer, temperature sensor, a bunch of other cool stuff like a 802.15.4 radio. However, it doesn’t have Bluetooth (and that’s a shame). However, Dave Simmons wrote a nice blog posting on how to get your hands dirty and *MAKE* it Bluetooth-enabled. Be warned, however, that if you don’t feel comfortable with a soldering iron, then stay away.     :-)

I’ve been commissioned by Sun to write the first article on MIDP 3.0 technology. Cool, huh? So, if you missed the MIDP 3.0 sessions this year at JavaOne, or if you have a burning question about the next Java platform that will be on billions of mobile devices in the coming years, then this is your grand opportunity for you to ensure that the article will answer your question. So, if you have a question about MIDP 3.0, then post it below!

This happens every year. For whatever reason, you need to get started with a Java ME project. Usually it’s one of the following reasons:

1. Your boss has a great idea, and he wants to see a mobile app
2. You’re a graduate student, and you think it’s really cool to write mobile apps
3. You’re trying to participate in a contest
4. You have a client who needs a mobile app

Either way, for whatever reason, you need to get started *now* on creating that application. Now, if you’ve never created a mobile Java application before, then I feel sorry for you because there’s alot of information available to confuse a newbie. However, there’s hope!

I just wrote an article for Sun describing alot of the free Java ME tools that are available for Java ME developers. The article is entitled, “Java ME Tools: The State of the Union, Q2 2009” and it will be updated regularly to help developers on how to get started with the best tools available.

By the way, if you like the article (or not) then feel free to rate the article, or provide comments. At the time of this writing, there’s currently a lively discussion going on regarding Mac and Linux support.

Thanks to everyone who took the time to read my two-part series on how to use a Bluetooth-enabled GPS receiver. Since that time, alot of you tried the examples with the MPowerplayer, and you found out that they changed how it handles JSR-82 API implementations. So, I wrote a quick follow-up article that answers all of your questions that were posted on the java.sun.com site. As always, you can find a link to all Java Bluetooth articles on the main site.

…Thanks dude. Anyway, I found Moscone North and South where the conference was held, and I was able to register, and go to the Java Champions dinner on Monday. Anyway, he’s a list of the the pro’s and con’s that I learned at JavaOne:

Pro’s

• The Java SE VM is on a billion desktops
• The Java ME VM is on 2.6 billion mobile devices
• The Java7 SDK was released at JavaOne
• The JavaEE 6 SDK was released at JavaOne
• Verizon (the largest mobile carrier in the US) plans to open their platform to Java ME
• The Java Store was announced (http://store.java.com)
• Larry Ellison plans to enhance OpenOffice with JavaFX technology
• Larry Ellison wants to support the Android platform

Con’s

• The Java Store is not ready yet
• Nobody showed much interest in Java 7 (can you name any of the new features?)
• No MIDP 3 SDK was available for download
• No MIDP 3 phones were available for purchase

All-in-all, it was a great conference, and I hope to be able to attend next year.

So, it’s very easy to qualify for the beta test. First of all, we won’t require any personal information. All you need to do is write a comment in this blog posting that answers the following five (5) questions:

1. Why do want to try out BlogRadio? (Most people will use it while commuting, but we’re curious about if there are any other use cases that we haven’t explored)
2.  What mobile devices do you own that you can test with? (If you’re like me, then you have more than one mobile device)
3. BlogRadio currently reads blog items in English, but what other language(s) should we support?
4. Do you have a blog? (If the answer is “no”, that’s ok).
5. What are the top 3 blogs that you would use BlogRadio for?

We’re going to accept applications for the beta only for this week (Sunday May 17 - Saturday May 23). If you’re chosen for the beta test, then we’ll contact you via email about further instructions and how to get started.

First of all, let’s take a look at some wireless standards (you’re probably familiar with the first one):

• 802.11
• 802.15.1
• 802.15.4

So, in the past decade, the IEEE standards body came together, designed, and formed all of the wireless standards listed above. Now, Wi-Fi is a brand name of *an* implementation of 802.11 wireless standard. Wi-Fi is such a common brand name, it is synonymous as the only implementation of the 802.11 standard. But that’s not the case.

The same things goes for Bluetooth. Bluetooth is an implementation of the 802.15.1 wireless standard, but it is not necessarily the only implementation. Likewise, this pattern applies to ZigBee. The SunSpot wireless devices natively communicate over the 802.15.4 wireless protocol, but they do NOT implement the ZigBee protocol stack.

So here’s what you can expect in the new Bluetooth 3.0 devices that will be coming next year. Bluetooth 3.0 devices will be able to discover and search for services for remote Bluetooth 3.0, 2.1, 2.0, 1.1, and 1.0 devices. However, if both devices support Bluetooth 3.0, then when the data payload is being sent, the data will be sent over the 802.11 “channel” and not the 802.15.1 “channel”.

I hope this makes sense.

I won’t be presenting this year, but if you can find me, I’ll either be wearing a BlogRadio t-shirt or a Java Champions shirt. And yes, I will have the prototype of BlogRadio with me  :-)

1. The registration process could be time intensive
2. The user my be required to give personal information
3. The user my be required to give their email address (and you can spam them)
4. The user will have to try to remember yet another username and password pair
5. The user may have to read a long license, disclaimer, or privacy policy (which protects YOU, not them)

Currently, I’m at the point where I’m walking away from the sites where I have to sign up, unless it’s REALLY worth the hassle. And guess what? Your potential customers are doing the same thing.

So, what are we doing differently with BlogRadio (coming in June 2009 to the Ovi store)? Take a look at the beta version of the BlogRadio Desktop Manager, shown below:

The whole purpose of the Desktop Manager is to allow users to manage the list of blogs that they want to hear on the BlogRadio Mobile application. So, if we don’t force the user to sign up, the how can we determine the data coming from one copy of the Desktop Manager among the thousands of copies of the Desktop Manager?

Key codes.

If you look at the bottom-left section of the image above, you’ll see that we assigned a key code to this particular user. When the user initializes their mobile client for the first time, all they need to do is enter in the key code that’s clearly shown on their Desktop Manager. We now have everything that we need to send their personal blog list to their mobile client. And of course, the user is happy because they don’t have to register.