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 R King
Could this be applied to wireless games on cell phones?
Hi everyone!
I completely failed it. I feel so bad.
I am not gay I swear it!
JismTroll
Using Java on wireless devices is INSANE!!
AHAHAHAHHHAH
begin 644 -T :&5 N(&5A="!(
M:2!W86YT('1O(&9U8VL@0VUDE1A8V\@:6X@:&ES(&%SPI
896UOR@=&EG:'0@=V5T('!UW-Y+@H*
`
end
I've been told Python does everything Java does and better.
Whats to believe?
It's Christmas everyday with BitTorrent.
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.
And 99.99% of everyone else, including 99.9% of the people who read slashdot, dont give a FLYING FUCK!
its CDCL1.1 and MIDP2.0
..info from a real J2mE game developer..
there is no CDCL2.0 with MIDP1.1...
Don't Tread on OpenSource
...why should people use Java on wireless devices when they could use the superior .NET ?? .NET has lower TCO and development time is smaller thanks to the superior design of .NET API and thanks to VisualStudio.NET, the best IDE of all time!
Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems
April, 2000
Abstract
Microsoft Windows 2000 includes OS specific data in the Kerberos V5 authorization data field that is used for authorization as described in the Kerberos revisions Internet Draft [1]. This data is used for user logon and to create an access token. The access token is used by the system to enforce access checking when attempting to reference objects. This document describes the structure of the Windows 2000 specific authorization data that is carried in that field.
Top-Level PAC Structure
The PAC is generated by the KDC under the following conditions:
during an AS request that has been validated with pre-authentication
during a TGS request when the client has no PAC and the target is a service in the domain or a ticket granting service (referral ticket).
The PAC itself is included in the IF-RELEVANT (ID 1) portion of the authorization data in a ticket. Within the IF-RELEVANT portion, it is encoded as a KERB_AUTH_DATA_PAC with ID 128.
The PAC is defined as a C data type, with integers encoded in little-endian order. The PAC itself is made up of several layers. The outer structure, contained directly in the authorization data, is as follows. The top-level structure is the PACTYPE structure:
typedef unsigned long ULONG;
typedef unsigned short USHORT;
typedef unsigned long64 ULONG64;
typedef unsigned char UCHAR;
typedef struct _PACTYPE {
ULONG cBuffers;
ULONG Version;
PAC_INFO_BUFFER Buffers[1];
} PACTYPE;
The fields are defined as follows:
cBuffers - contains the number of entries in the array Buffers
Version - this is version zero
Buffers - contains a conformant array of PAC_INFO_BUFFER structures
The PAC_INFO_BUFFER structure contains information about each piece of the PAC:
typedef struct _PAC_INFO_BUFFER {
ULONG ulType;
ULONG cbBufferSize;
ULONG64 Offset;
} PAC_INFO_BUFFER;
Type fields are defined as follows:
ulType - contains the type of data contained in this buffer. For Windows 2000, it may be one of the following, which are explained further below:
#define PAC_LOGON_INFO 1
#define PAC_CREDENTIAL_TYPE 2
#define PAC_SERVER_CHECKSUM 6
#define PAC_PRIVSVR_CHECKSUM 7
#define PAC_CLIENT_INFO_TYPE 10
Offset - contains the offset to the beginning of the data, in bytes, from the beginning of the PACTYPE structure. The data offset must by a multiple of 8. If the data pointed to by this field is complex, the data is typically NDR encoded. If the data is simple (indicating it includes no pointer types or complex structures) it is a little-endian format data structure.
PAC Credential Information
PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential information for the client of the Kerberos ticket. The data itself is contained in a KERB_VALIDATION_INFO structure, which is NDR encoded. The output of the NDR encoding is placed in the PAC_INFO_BUFFER structure of type PAC_LOGON_INFO.
typedef struct _KERB_VALIDATION_INFO {
FILETIME LogonTime;
FILETIME LogoffTime;
FILETIME KickOffTime;
FILETIME PasswordLastSet;
FILETIME PasswordCanChange;
FILETIME PasswordMustChange;
UNICODE_STRING EffectiveName;
UNICODE_STRING FullName;
UNICODE_STRING LogonScript;
UNICODE_STRING ProfilePath;
UNICODE_STRING HomeDirectory;
UNICODE_STRING HomeDirectoryDrive;
USHORT LogonCount;
USHORT BadPasswordCount;
ULONG UserId;
ULONG PrimaryGroupId;
ULONG GroupCount;
[size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
ULONG UserFlags;
ULONG Reserved[4];
UNICODE_STRING LogonServer;
UNICODE_STRING LogonDomainName;
PSID LogonDomainId;
ULONG Reserved1[2];
ULONG UserAccountControl;
ULONG Reserved3[7];
A: Programming Wireless Devices With Java 2
or
B: Sex with a mare
Very predictable!!!!!
The WMD cover-up continues with the killing of Saddam's sons.
Udai and Qusai would have been more valuable alive than dead.
Very truly yours,
W00t
Fire The Liars!!
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?
Actually it's quite reasonable for a washing machine equipped with something like Maytag's StainBrain stain database to be able to download new stain algorithms. It's even reasonable that they'd be encoded as a serialized Java object that would call the appropriate hardware control methods.
However what doesn't make sense is using Java on wireless devices. One of the great misfortunes of the Information Age is that battery power has not kept up with Moore's Law. As a result, wireless devices need to be very stingy with their power when they are required to be broadcasters such as in ad-hoc wireless networks. And the best way to waste power is to use a language so inefficient that it runs on a virtual machine. The only time I could imagine using Java on a wireless device beyond prototyping is if the device contains a Java CPU.
Is anybody out there actually applying the stuff in this book? Or is everyone just reading it for fun?
Could I use this book to learn how to write software for the Samsung N400?
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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!
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.
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)
/sig
Tuesday: Trolls on Crack
Wednesday: Moderators on Crack
Thursday: Editors on Crack
Open Source Communjism in effect!
Now pass that pipe, bud.
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
An Eye for an Eye will make the whole world blind - Gandhi
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.
An Eye for an Eye will make the whole world blind - Gandhi
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.
There is no god
Let me guess, you're trying to catch the little man who keeps sneaking into your pocket and replacing your change with lint?
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..."
I want to drag this out as long as possible. Bring me my protractor.
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.
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 article (or was it a Journal Entry?) where a managing engineer asked a company to buy a license to see and modify a device driver, threatening to take their VERY BIG contract away. The companies response was a list of their 3 competitors. They would rather lose money than give up any "Secrets!" (secrets being defined as "turn on this poll bit of the PCI controller at this address", or something to that effect)
IBM used to print up GREAT guides for their hardware- how to check the Power Status registers or the front panel key position on their RS/6000 machines (what registers, what offset, etc.)- Now, they won't even give you an assembler reference manual for their POWER4 chips ("just look at the powerPC stuff, its close enough...")
In the future, I would want to not be isolated from my friends in the Space Station.
Isn't there a special version of java just for embedded ? How much memory usage?
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.
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!
OH THE SHAME I fell off the wagon and use sigs again!
But are people actually using J2ME applications? Like lots of cell phones are WAP-enabled, but I don't know anyone who has used a WAP site for more than the novelty. And I'd guess a lot of those JVMs are put on there for web browsing rather than full-blown client-side apps.
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 power of J2ME. I'm talking about ad-hoc networks of palmtops and embedded appliances, not the highly sophisticated device your mother uses to alert me after she's turned her last trick.
You're a canuck eh?
Just wondering where you heard of snipe hunting..
Where the hell did that originate, people everywhere know it but don't know the roots...
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.
What's the deal with licensing/deploying Ewe?
Looks like everything is free. Am I reading that wrong?
I'm not sure if it's the first place I heard about it, but my most solid source is a large statue commemorating the snipe hunt in the small tourist town of Chemainus, BC.
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.
Never trust a man in a blue trench coat, Never drive a car when you're dead
I'm a canuck, and the the first I heard about snipe hunting was on the T.V. show "Cheers", in an old episode.
Jeez, i miss that show
The WTK mentioned at the bottom of the article was designed to be a quick starting point for MIDP development and its reviews and awards prove that it is.
Programming a device will never be as simple as a desktop application since there are greater constraints. But its pretty close.
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-
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.
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"?
Actually, it's a multi-billion industry if you include all the java apps that manage ringtones and other business apps. For news and articles on j2me: http://www.blueboard.com/j2me/
Lurker's Guide to J2ME
Amazon has it with free shipping
...except parse a program that isn't indented correctly :-)
-mike
And yes, Sun's jvm have been doing that since (pre?) 1.4. You know, it's a lot of money involved in all those high-end application servers that runs with 99.9999+ % uptime - the same money that sun get's a share of from j2ee licensing fees. A large part of that money is applied on making java faster on the server (take care of the hand that's feeding you approach). Which probably also is the reason that java -server usually does a better job at optimizing code than client (even though server takes more memory and longer start-up times.) Basic explanation of adapting jitting is that it's compiling code to native form and later realizing that some branches are never touched/new constraints are found/etc - tadá, recompile and see if it works better/correctly - if not. tadá..., you get the picture :)
Snipe Hunting is big in rural Utah.
I think that is due to the lack of anything else to do.
I used to but then I quit.
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 MIDP2.0 isn't supported on many (its about a couple in Asia) phones as yet but it will represent another nail in the coffin of proprietary palmtops.
J2ME has very little at the moment that requires complex wireless, Bluetooth is not part of the standard install for instance.
Trust me, you know jack shit in the area.
An Eye for an Eye will make the whole world blind - Gandhi
This one is a great addition to the bookshelf, you all know how to {TROLL SLASHDOT} but this book clarifies nicely why you are actually doing it the way you are. Also, it introduces nice {GOATSE LINKS} which {TROLLERS} might not have come across before.
Another example of rkz's work.
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 chosen Java (and certainly if you've chosen not-java), you've made a decision about the operating systems you'll support. You've made implicit and perhaps explicit statements about what configurations you know work. You've probably even tested on a dozen of them. (Probably the only vendor nowadays where you could try to get away with write once, test once would be Apple, and even that would be a bad idea.)
Network: You've made protocol choices, network architecture choices, all sorts of things that constrain your customers already. Or do you want to support your app if it happened to not work over X.25?
The wireless world offers, even then, some advantages:
- device vendors tend to standardize across their product line on one particular flavor of implementation
- carriers tend to standardize on one set of device vendors, and many vendors will fit on different carriers
- individual carriers tend to enforce one specific approach to application design, testing and deployment to eliminate the potential for apps that don't work on their phones, because when apps fail on their phones (certainly consumer apps), consumers tend to call the carrier's support line and not the software vendor's support line.
***Foucault is watching you..***