Slashdot Log In
Programming Wireless Devices With Java 2
from the hopped-up dept.
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.
Games? (Score:3, Interesting)
Re:Games? (Score:2, Informative)
Interesting ? (Score:3, Informative)
I'm assuming you are based in the US, because right now there are loads of games on mobile phones in Europe and Asia, and some of them are already interactive across the network.
And that was MIDP 1.0
Re:Games? (Score:2)
Why, that's just crazy talk!!
Oh yeah: "Duh!"
There are no such beasts (Score:5, Informative)
Too Complex (Score:5, Insightful)
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.
I beg to differ. (Score:5, Informative)
I find MIDP to be very simple and easy to use. Maybe it helps to be a Java progammer and understand the Java way of doing things, but I've built a few J2ME applications and I've been amazed at how little time they took to create, and how well the finished product performed.
Parent
Re:Too Complex (Score:3, Interesting)
I currently have an Ipaq, and it runs java via some JVM supplied by compaq. It looked cool and I thouht it would be great because this thing runs
Re:Too Complex (Score:3, Interesting)
So far.. (Score:5, Informative)
For an example six months ago I had to do a little program that sent data through Nokia 9210's irDa port. API seemed to support it, so I made a program that used the irDA. Unfortunately the program never could open the irDa port. After days of research I finally found out that Nokia had NEVER implemented the irDa port correctly to the library that Java used. They had a typo in the port name, but nobody seemed to care about 'a minor flaw' at Nokia. The bug had been there for years and there was no way you could use irDa with Java in Nokia 9210(i).
After that I just switched to the C++ and everything worked perfectly.
The problem with mobile phones and Java generally is that if hardware interface is not implemented correctly, you can do nothing about it. Can you imagine yourself coding hundreds of hours a Java program and finally realising that the API hasn't been yet implemented fully and the program can never run. Ok, maybe not never, but would you like to wait years before you get fully implemented API?
Java Isn't Trustworthy (Score:2, Insightful)
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
Re:Java Isn't Trustworthy (Score:2, Interesting)
To say that someone who is writing in Java is not writing a "serious program" is wrong. If I wrote a program for a mobile phone that interacted with an Exchange server, imported XML documents from your company intranet and performed some processing before presenting the result etc is not a trivial matter, but I do not need to necessarily to understand the low level details - which Java hides really well.
APIs Are Serious (Score:4, Interesting)
Um, did you or any of the asshat moderators bother to read my post or did you just interpolate from the highlighted word?
My point is that without the APIs encapsulating the hardware interfaces you can't write serious programs in Java, not that you shouldn't. How is your mobile phone going to interact with that Exchange server if you can't even use the phone's network interface? If the J2ME API is not fully implemented, then you're trapped in a little mobile jail.
I was arguing that industry has shown itself unable to properly implement APIs for high-level languages, so therefore volunteers need to implement them. As a result, someone needs to know the low-level language because Java can't be used to write its own APIs. Java can be used for serious programs, but only after someone else does some programming in a lower-level language.
Parent
Re:APIs Are Serious (Score:2)
But this is true for any language. Before someone can write a C application, they need a C compiler. And if the compiler has never
Self-Compiling Languages (Score:2)
Re:APIs Are Serious (Score:2, Interesting)
You may be looking at the wrong devices. I recommend you take a look at Motorola's iDEN phones site [motorola.com]--the J2ME implementation of various APIs in the phones are very complete and robust, including serial port interfaces, a half-dozen network protocols, crypto, interfaces to GPS hardware, etc. Yes, many of these are Motorola proprietary classes, but if you look at the MIDP 2.0 spec a lot of those proprietary features have become part of the general MIDP API.
Full disclosure: I work for Nextel. I also
Generalizations About Broads (Score:2)
too right, mate. (Score:3, Interesting)
Nor do they bother to comply with standards. Despite providing PCI token ring cards for their new e-servers, don't expect a device driver that is standards compliant from IBM. Never mind that we run a real time human grade system (thus, the olde skool token rings!)
I seem to remember another slashdot artic
Re:So far.. (Score:5, Insightful)
Parent
Why is this Java's fault? (Score:3, Insightful)
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.
Samsung N400 (Score:2)
Fair Comparison (Score:5, Funny)
First off, WinME. WinME is what computer people call an "Operation System", which means it is a program that can perform operations on a computer. What I really liked about WinME over its predecessor, MacOS9, is that the menu is on the bottom of the screen, there are great screen savers like a Star Wars -ish one where stars fly across your screen, and it supports a mouse with more than one button. Other noteworthy features of WinME was that I can sign up for AOL right off of the homepage, just by double-clicking on the little AOL picture. Neat!
Now, here is where the story gets good. J2ME is just like WinME in many ways - Microsoft designs them that way so you don't have to relearn your computer everytime you "install" a new "operation system" (see, this isn't so hard now, is it?). The only thing I didn't quite understand was that WinME comes on a CD-Ram, and J2ME comes on a cellular phone. Now, I am usually really savvy with computers, but I still just can't figure out how to get J2ME off of my cell phone and onto my PC. This is important to me, because I really want to "upgrade" my PC from MacOS9, which was an earlier version of WinME/J2ME that just isn't as good as those two.
Nevertheless, I think that Microsoft is doing a tremendous job with their entire 'ME' series of operation systems, and I hope you agree!
Java woes (Score:3, Interesting)
For example, I'm working on a project that involves a barcode scanner attached to a PDA, communicating wirelessly to a database. Java might let me do all the wireless/database stuff, but so many addon devices don't support Java.
Anyone know of a PCMCIA or CF barcode reader that does suport Java?
(crickets chirp)
Re:Java woes (Score:2)
Using Cellphone cameras under J2ME (Score:2)
Snipe Hunting? (Score:2)
Chemainus (Score:2)
Re:Snipe Hunting? (Offtopic) (Score:2)
I'm a canuck, and the the first I heard about snipe hunting was on the T.V. show "Cheers", in an old episode [tvtome.com].
Jeez, i miss that show
Re:Using Cellphone cameras under J2ME (Score:2)
But not impossible.
If you only need to do this with one phone, try writing your code in C++ for a Symbian phone like the Nokia 3650, so you aren't constrained by the crippled Java on Nokia phones.
--G
Re:Using Cellphone cameras under J2ME (Score:2)
Brief Introduction to the Mobile Media API v1.0 (with Camera instructions) [nokia.com]
Camera MIDlet: A Mobile Media API Example v1.0 [nokia.com]
And at The J2ME Mobile Media API [sun.com]:
Re:Using Cellphone cameras under J2ME (Score:2)
An accurate review (Score:2)
It is very much a reference work, and reads like it was written by a committee. (Six authors listed in fact.)
It's a suitable book for any Java programmer who wants to learn the J2ME platform.
Written by Finns (Score:3, Insightful)
"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.
Re:I thought Java was doomed (Score:4, Insightful)
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... ;-)
Parent
Re:I thought Java was doomed (Score:3, Interesting)
Nope, it goes directly to machine language. Plain old CPython with Psyco, that is.
Try Lisp. No, seriously. Think GCs and (native-code) compilers with 40 years of optimization, together with a really high-level, productive language. See this example [franz.com] where it seems to have worked quite well.
Re:I thought Java was doomed (Score:2)
What's interesting about Psyco [sourceforge.net] and similar efforts is that there exists a possibility of further optimzations than in regular compiled languages.
Suppose you have a function called do_it(), which takes an integer argument. Its got a loop in there that does some calculation. If you wrote it in C, you'd code up your for loop, and do it's thing.
However, a really smart optimization system would not only look at the code as you've written it, but also look how it is actually used in runtime.
Supposed t
Re:I thought Java was doomed (Score:2)
Re:I thought Java was doomed (Score:2)
Well, not sure what everyone's doing in this space. But its not what Sun is doing.
I looked at Sun's whitepaper: The Java HotSpot Virtual Machine, v1.4.1 [sun.com]. When they're talking about hotspots, they just mean running the JIT on the most-used sections of code. They're trying to get Java bytecode to match the speed of optimized C code.
The Psyco stuff I mentioned is talking about dynamic optimimization of functions you've already selected. They are trying to surpass the speed of optimized C code.
Even
Re:I thought Java was doomed (Score:2, Interesting)
"GC pauses and portability (consoles) are still issues for Java games"
I write mobile Java games for a living I have to say that pauses caused by garbage collection are not an issue I've come up against in modern (12 month old) phones. And portability isn't too much of an issue either, sure screen sizes are different and manufacturers API differ but it's not *that* problematic.
Re:I thought Java was doomed (Score:3, Informative)
Python can do everything Java can do (Turing-completeness, and all that) but better is far too subjective a claim. Python is a higher level language than Java is and offers more powerful language constructs. But, Java's current implementation tends to run faster than Python's for much the same reason. Python offers scores of standard libraries to perform useful tasks, but those libaries tend toward one-off minialism. Java
Re:I thought Java was doomed (Score:2)
With little insentive to do so (it's usually fast enough), there isn't a big push to make it lots faster. The general feeling is that Python could be heavily optimized and see a huge performance gain. Just the same, it's a big task and it is, generally fast enough already. So, it becomes a catch-22.
Re: Python can do everything Java can do... (Score:2)
-mike
Re:I thought Java was doomed (Score:4, Informative)
Parent
Re:I thought Java was doomed (Score:2, Insightful)
Traditionally, that has been the programmer's job.
Re:I thought Java was doomed (Score:2, Insightful)
Re:Washing Machines and Ad-hoc Networks (Score:4, Informative)
Some phones have better Java technology than others however.
Parent
You are denying reality... (Score:5, Informative)
Bloody hell.. lets see there are nearly 100 mobile phones that support J2ME, there are over 100 million sold in the last 12 months world wide and Nokia in ONE QUARTER ALONE sold over 800,000 of the high end smart phones.
Low end phones like the 6310i have been J2ME phones for around a year now. And now almost ALL phones released in Europe and Asia are J2ME enabled.
Basically you know zip, zero, nada about Mobile Applications.
This isn't new, this is way over 12 months old and represents already a multi-million dollar industry in selling J2ME applications to consumers.
Parent
Implementation != Use (Score:2)
If you bothered to actually read my original post, you'd realise that cell-phones aren't what I was talking about. Their screens are too puny for serious applications and their wireless capabilities are too limited to require the full po
YES.... (Score:2)
Okay on my desk right now I have a P800 and a 6310i. On the P800 are a few Java games which do full 3D. On the 6310i is an application that uses Web Services to connect to a weather information service.
But of course to you the 6310i couldn't possibly run J2ME and act as a weather service and cache route information and act as a timesheet which submits to a central server once a week. Because it can't be used in this way.
Java Smartphones out sell PDAs 5 to 1 already, and this number will rise. J2ME MID
"download new stain algorithms"? (Score:2)
Wow. Apparently I have missed out on new washing machine developments in the last four years or so (since I last bought such an item).
That, and I got a chuckle out of the phrase itself. YMMV, of course.
"I for one welcome our agitating overlords..."