Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Wireless Networking Book Reviews Hardware Technology

Programming Wireless Devices With Java 2 108

Posted by timothy from the hopped-up dept.
Jeff Carroll writes "Developers building Java applications for wireless handheld devices have been looking forward for some time now to the release of devices supporting version 2.0 of the Connected Limited Device Configuration (CLDC), and version 1.1 of the Mobile Information Device Profile (MIDP). These new releases contain support for features demanded by developers that didn't make the original releases. In support of CLDC 2.0 and MIDP 1.1, Roger Riggs and his team of authors from Sun, Nokia, and Motorola have released Programming Wireless Devices with the Java 2 Platform, Micro Edition, Second Edition (since I don't have a copy of the first edition, I can only evaluate the new edition on its own merits)." (Read on for his review.) Update: 07/23 16:31 GMT by T : Whoops -- that's CLDC 1.1 and MIDP 2.0, not the other way around.
Programming Wireless Devices with the Java 2 Platform, Micro Edition, 2ed.
author Roger Riggs, Antero Taivalsaari, Jim Van Peursem, Jyri Huopaniemi, Mark Patel, Aleksi Uotila
pages 464
publisher Addison-Wesley Professional
rating 7
reviewer Jeff Carroll
ISBN 0321197984
summary In-depth introduction to and reference on CLDC 2.0 and MIDP 1.1.

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.
This discussion has been archived. No new comments can be posted.

Programming Wireless Devices With Java 2 More

Programming Wireless Devices With Java 2

Comments Filter:

  • Games? (Score:3, Interesting)

    by Nick of NSTime ( 597712 ) on Wednesday July 23, 2003 @12:16PM (#6512181)
    Could this be applied to wireless games on cell phones?

    • Re:Games? (Score:2, Informative)

      by Nick of NSTime ( 597712 )
      I meant to say wireless networked games on cell phones.

    • Interesting ? (Score:3, Informative)

      by MosesJones ( 55544 )

      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
    • That's what MIDP is used for in phones .. I haven't seen many applications that are NOT games - and MIDP2 is a lot better for games than MIDP1 was/is.
    • yes it can.. anyone who says "no it can't" is a fool. J2ME is specifically for this stuff.. Lots of phones can use it. Especially newer Sprint phone (sanyo samsung) and I'd assume many of the others.
    • Could this be applied to wireless games on cell phones?
      Why, that's just crazy talk!!

      Oh yeah: "Duh!"

  • There are no such beasts (Score:5, Informative)

    by Gzip Christ ( 683175 ) on Wednesday July 23, 2003 @12:20PM (#6512231) Homepage
    Developers building Java applications for wireless handheld devices have been looking forward for some time now to the release of devices supporting version 2.0 of the Connected Limited Device Configuration (CLDC), and version 1.1 of the Mobile Information Device Profile (MIDP).
    You've got that backwards dude. It's MIDP2.0 and CLDC1.1. See here [sun.com] and here [sun.com].

  • Too Complex (Score:5, Insightful)

    by nathanz ( 555048 ) on Wednesday July 23, 2003 @12:24PM (#6512265)
    I hate to sound like a VB programmer here, but I think part of the problem with all these Java API's, VM's, etc. for mobile platforms is that they are too complex. When the MIDP and the kvm first came out for Palm, I just at it, but was quickly frustrated by the complexity of creating an application and the limited number of controls.

    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)

      by Dr. Bent ( 533421 ) <<ben> <at> <int.com>> on Wednesday July 23, 2003 @01:03PM (#6512618) Homepage
      There are only about 125 classes in the entire MIDP specification, and alot of these are things like Integer and IllegalStateException. When you get down to the meat of it, there's maybe a couple dozen classes that you really need to understand.

      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.

    • Re:Too Complex (Score:3, Interesting)

      by FatherOfONe ( 515801 )
      I agree with our main point. However don't blame Sun too much for the crap that was KVM. Remember they turned that over to "PALM" to head up. I never understood that at all. Why would Palm EVER want to support JAVA? They owned like 90+% of the PDA market. They want people to write to their platform, not a generic one, that would let people move off of Palm.

      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)

      by nate1138 ( 325593 )
      If you want an easy to code PDA platform, try Ewe [ewesoft.com]. It's got a full featured class library, a fast-ass VM, and it runs on anything (PocketPC, Linux, win32, mac). We've been using it to deploy wireless pocketPC apps, and it rocks.

      • Ewe Free? (Score:1)

        by Anonymous Coward
        What's the deal with licensing/deploying Ewe?

        Looks like everything is free. Am I reading that wrong?

    • Re:Too Complex (Score:1, Flamebait)

      by pmz ( 462998 )
      I shouldn't need a book to create Java applications for a mobile device.

      You know, working for a living is also hard. Why not just sit back and let those welfare checks, food stamps, and magical tax returns roll in. Did you know there are people who get back more money from the IRS than they put in? It's called Earned Income Credit. Check it out.

      I think the technology industry has led itself into a delusional state, where marketing is somehow reality. Too many people start pet projects thinking, "Gee

  • So far.. (Score:5, Informative)

    by Dexter77 ( 442723 ) on Wednesday July 23, 2003 @12:34PM (#6512366)
    I've been involved with wireless programming and Java since late 90's. So far Java hasn't lived up to its promises. Sure, you can do nice games on mobile phones, but real programming is a joke.

    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)

      by Vagary ( 21383 )

      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

      • Totally disagree with you I'm afraid.

        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)

          by Vagary ( 21383 ) <jawarrenNO@SPAMgmail.com> on Wednesday July 23, 2003 @01:31PM (#6512881) Journal

          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.

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

            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

            • Yes, but to write a C API (or compiler), all you need to know is C. Yes, you need low-level knowledge of the hardware interfaces, but that's an assumed requirement for writing an API, isn't it? Whereas with Java, you can't write the API in Java because it doesn't have low-level hardware access. Therefore, Java only works on a platform if the hardware vendor or some other kind soul decides to allow it to work.

          • Re:APIs Are Serious (Score:2, Interesting)

            by juanfe ( 466699 )
            Vagary,

            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

            • Obviously there are a few hardware platforms with good J2ME API implementations, but as long as they're not consistently good you're left with write-once-debug-everywhere. Am I supposed to tell my customer who complains that an application isn't working to "take a look at Motorola's iDEN phones"?
              • In a nutshell, yes. You've already told your customers to "take a look at x" in multiple ways by the time you sell your software.

                By the time you sell a desktop app, you've consciously or implicitly come up with recommended hardware, configurations, service providers. You'll have implicitly made choices about:

                Desktop hardware: you'll have specified minimum requirements because you probably don't want to even try supporting your new and sharp 3D topographic elevation GIS app on a Mac LC.

                OS: Even if you've

      • too right, mate. (Score:3, Interesting)

        by mekkab ( 133181 )
        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.

        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)

      by Anonymous Coward on Wednesday July 23, 2003 @01:03PM (#6512620)
      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.
  • Could I use this book to learn how to write software for the Samsung N400 [samsung.com]?

  • Fair Comparison (Score:5, Funny)

    by Anonymous Coward on Wednesday July 23, 2003 @12:43PM (#6512436)
    This weekend, I took the time to review two competing programs for your computer: J2ME, and WinME.

    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)

    by Mondoz ( 672060 ) on Wednesday July 23, 2003 @12:44PM (#6512448)
    It's great that there's more support for the actual wireless aspect, but there's not enough Java support for the other devices that interact with the wireless.

    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)

    • How about a cell phone that has J2ME and that also has a barcode scanner that it can talk to?

      http://www.symbol.com/products/barcode_scanners/ ba rcode_psm20i.html

      • There's lots of dedicated 'one piece' devices that Java can interact with, the problem is finding add-on devices that Java can talk to.
  • I'm curious if this book (or any other) goes into using the cameras on cellphones under J2ME. I'd like to write a "real webcam program" for a Sanyo SCP-5300, i.e., one that takes a picture every few minutes and ftps it to a server. Is there any hope for this kind of thing to be written?
  • This one is a great addition to the book shelf, you all know how to use basic java under J2ME but this book clarifies nicely why you are actually doing it the way you are. Also, it introduces nice advanced concepts which regular java programmers might not have come across before.
  • Isn't there a special version of java just for embedded ? How much memory usage?

  • WiFi blew up (Score:1, Offtopic)

    by ratfynk ( 456467 )
    I spilled my coffee all over my WiFi, My java didn't work too well, I am about as good with coffee as I am with Java!
  • I have just got this book and was in fact planning to review it here myself... This is a good and accurate account of what the book does in my opinion - bar the mix-up in version numbers that several have noted.
    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)

    by aminorex ( 141494 ) on Wednesday July 23, 2003 @02:33PM (#6513475) Homepage Journal
    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.

  • J2ME news and articles (Score:1, Informative)

    by Anonymous Coward
    There are many sites focused on J2ME. This one is for news and developer articles (it also has links to other J2ME resources):

    Lurker's Guide to J2ME [blueboard.com]

Slashdot Top Deals

If all else fails, lower your standards.

Close