Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
True, Java ME improves matters by integrating Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC) configurations in one SDK. But the primary goal for JavaFX Mobile, one would think, should be to flatten the playing field: provide some level of guarantee that a scripted app will run unaltered across a broad range of certified compatible phones, without resorting to pre-processor directives and the like. As these are limited-resource devices, it seems that a Fail Gracefully API should be a central part of the platform. Ease the number one pain point for Java ME developers worldwide. Unfortunately there's no such API or capability in sight.
In fact there's currently very little information to be had regarding even the differences between targeting a mobile device and a desktop using JavaFX. Aside from concerns such as screen dimensions and image file sizes, the same JavaFXScript desktop code should run unaltered on your smartphone. At least, that's what we're being promised.
However, some notes casually buried away in the 1.1 release notes suggest otherwise: the javafx.ext.Swing package isn't available in the common profile so won't work in mobile applications - this means no standard desktop UI components such as buttons, trees and listboxes.
You do get one component, javafx.scene.control.TextBox. But the richness of the desktop component set just isn't there in the mobile configuration. When you look at the existing mobile demos, you'll quickly realize the colorful, motion-blurred, willy waving - such as a custom image masquerading as a button - divert attention from the lack of GUI components.
In the meantime, Veriana Networks senior vice president of technology and JavaFX blogger and writer Jim Weaver, has written that we should start seeing "lots of UI controls" in the Common profile, anticipated "before" JavaOne 2009. Which in the meantime leaves the cupboard looking rather bare.
In theory you could integrate a proper mobile GUI toolkit such as the Light-Weight User Interface Toolkit (LWUIT), but details are currently thin on the ground. This all makes me wonder how Sun can release JavaFX Mobile to the world and call it "1.0" with a straight face. A clear case of marketing racing ahead of reality.
Window of opportunity
Sun has had a massive window of opportunity to establish JavaFX Mobile, but the current stunted release dressed up in pretty colors strikes me as a little underwhelming given the time Sun's had to work on this. Twelve months ago it could have shipped something less compelling and still had the rapt attention of the major mobile vendors and carriers.
Luckily for Sun, Microsoft has yet to show Silverlight for mobile, due for release "sometime" in 2009 and even then on a limited range of devices. Adobe has Flash Lite, which has yet to make waves, and more denials than announcements concerning a possible Flex for mobile.
How long it'll take for Microsoft and Adobe to move beyond this limbo and into real products and adoption, it's hard to tell. Unfortunately, once they do, they'll both have the tools, resources, runtimes and developer buy in that's currently not evident from Sun.
While there are many cool new things in JavaFX 1.1, developers are advised to ignore Sun's frantic hand-waving in front of a half-baked platform and avoid being an early adopter. Java ME with LWUIT is actually far more appealing - and proven - right now. ®
Matt Stephens co-authored Use Case Driven Object Modeling with UML: Theory and Practice, which illustrates how to create the ideal software design with Enterprise Architect, Spring Framework and JUnit.
COMMENTS
@MIDP signing is killing JavaME
Agreed - even a freely available "developer" certificate would be nice. I wanted to get into homebrew mobile apps with Java ME, but I can't justify 300 quid for a certificate for something which I'm in all likelihood never going to pass to another person.
I can understand some of the reasons behind it - stopping "dodgy" apps sending SMS messages every second, or downloading buckets of data maliciously, basically anything that would cost - but if I want a homebuilt GPS tracking app on my phone I have to fork out quite a chunk of cash for one user.
Thanks for the mention, Matt!
Matt,
Thanks for the mention in this article. I do look forward to a good set of skinnable, CSS-styled, set of UI controls for JavaFX. This will accelerate the development of JavaFX apps, including mobile devices.
Jim Weaver
http://JavaFXpert.com (Learn JavaFX blog)
MIDP signing is killing JavaME
JavaME's window of opportunity died when they yielded to mobile network operators and introduced certificates and signed applications. Case in point - every advanced feature on mobile phones that JavaME has access to (camera, bluetooth, Internet access, sensors, file system access [not private data access; regular mp3-storing-kind file system]) is restricted only to signed applications. This is killing small, independent developers (shareware / freeware) that made such a big part of what e.g. PalmOS once was. Often, it's not enough to sign applications (midlets) by a well-known CA (Thawte etc.) but the application needs to be signed by a carrier-specific CA before it can use these features.
A direct consequence of this is that freely available JavaME applications usually look crummy and outdated, which then sheds a bad light on the entire platform. About the only popular category of midlets are games, distributed, of course, by cell operators, which is a shame when the platform is in the ideal position to do a lot more.
Of course, if JavaFX mobile needs any kind of upgrade or an add-on runtime library to existing JavaME installations (which seems likely), it will be stillborn.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
