Slashdot Mirror
Programming Wireless Devices With Java 2
As is characteristic of the titles I've seen from Sun's Java series, this book goes into great detail about architectural decisions, standards process, and philosophy underlying the new release. The first six chapters are given over to this discussion. This material is mostly great for experienced developers seeking a deeper understanding, occasionally so abstract as to be silly (as in the case of the Java washing machine and its downloadable stain-removing code), but likely to be of only secondary interest to new J2ME developers focused on coming up to speed.
What this book does best is comprehensive exposition of the J2ME APIs. There are chapters dedicated to the APIs for forms, graphics, games, sound, persistence, and networking, with code samples offered in most cases, and a Java Almanac-style reference to all J2ME-specific classes and interfaces is provided as an appendix. Features that are new to the J2ME second edition are clearly identified.
The remainder of the book constitutes a detailed discussion of the new technologies for event-driven launch, application security, and over-the-air deployment, perhaps the most potentially confusing of which is event-driven application launch. While the book explains the new technology well, it doesn't address how it will be introduced by network operators, or how it might interact with or replace similar existing proprietary technologies such as Sprint's MUGlets.
Another subject that is not dealt with here that will soon be relevant to developers for any particular J2ME-supporting network is that of optional packages (OPs) - features to be supported at the option of particular device vendors and/or network service providers. It is fairly clear that, going forward, the wireless network infrastructure and its supported features will be an integral part of the J2ME platform that will have to be taken into account by developers, and books which fail to discuss popular and commonly adopted OPs will be of limited usefulness (you'd think that Sun would know that after all that rhetoric about the network being the computer). In general, a book of this sort would benefit from the participation of network operators, as it does from that of device manufacturers Nokia and Motorola.
All the code samples and background on architecture notwithstanding, this book is clearly targeted at experienced Java programmers, not handheld device programmers working in other technologies. If you don't already know Java, this book will not teach you. There is also nothing said here about selection, configuration, or use of development tools; readers who are not already adept at the use of J2ME development tools, including the Wireless Tool Kit (WTK), should not expect to acquire that knowledge from this book. (People who need help in this area may want to consider Jonathan Knudsen's Wireless Java or Kim Topley's J2ME in a Nutshell.)
Keeping the aforementioned caveats in mind, this is an excellent introduction to and reference on the new release of J2ME.
You can purchase Programming Wireless Devices with the Java 2 Platform, Micro Edition, 2ed. from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I shouldn't need a book to create Java applications for a mobile device. I should need a two page cheat-sheet that maps "mobile" concepts to core Java/Swing concepts.
BTW, I did finally get my Palm program working by using Waba (http://www.wabasoft.com), which I thought was far superior to what Sun was putting out.
Whats to believe?
What's the fastest runtime for Python? Can it translate to C code?
The fastest Java runtimes are approaching C++/Fortran speeds.
My personal quest has been for a productive, portable language that's efficient enough for high-end gaming applications. C++ isn't too productive, but GC pauses and portability (consoles) are still issues for Java games. Gcj looks interesting - with it you can disable bounds checking and GC (not a problem if you use mostly static objects).
One point of synergy between Python and Java is Jython - Python that compiles to Java byte code. Perhaps the JVM is the fastest Python runtime... ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
If you use a language that won't let you get to the hardware yourself or an API that isn't open source, then you're at the mercy of the hardware vendors to make the nice little garden paths you need to go down. And a reoccuring theme is that they don't.
For right or wrong, a lot of hardware vendors seem to assume that people using high-level languages aren't writing serious programs. As a result, they don't bother to fully implement their interfaces. This leads to a catch-22 because, of course, without the interfaces you can't write serious programs. Since I assume the hardware industry isn't about to get a clue, the only solution seems to be volunteer-implemented APIs -- either that, or using programming languages that are actually designed for hardware interfacing.
In all honesty though that isn't JAVAs fault. The problem was that Nokia had made a mistake. Having had several nokia phones, I will admit they are a bit prone to mistakes as well, especially regarding IRDA. I had several Nokia phones, that while they had IRDA ports, the ports were not even turned on, or at least not in the US editions. Don't blame a mistake that was made by an OEM on the people who made the software.
After days of research I finally found out that Nokia had NEVER implemented the irDa port correctly to the library that Java used.
So why exactly is this a problem with Java? Nokia didn't stick to the specification, and your program doesn't run because of it. If Nokia didn't stick to the spec for thier native libraries, you would have the exact same problem with your C++ app.
Sounds to me like the real issue here is with Nokia not doing thier job.
Just a heads-up for those who might miss the fine print:
"Written by a team of authors that includes the original J2ME technology experts from Sun, Motorola, and Nokia..."
Now, doesn't that just tell you everything you need to
know. Wirtten by "technologists" and "architects", who
don't know how to write code and don't give a crap.
-I like my women like I like my tea: green-
I'll have to look into that. my main complaint with java is that it is so high level, and programmer-centric. There's so much stuff in there that only helps the programmer. I would gladly pay the price in time and study to make something more user friendly
Traditionally, that has been the programmer's job.
This isn't any ordinary darkness. It's advanced darkness.
What kind of things do you expect to see in a programming language that are there for the user's benefit, where "user" is not defined as "the programmer"???