Once upon a time, I wanted to be able to read electronic books on my cell phone. This sounds like a simple thing, especially when you consider that my LG Xenon supports Java midlets. All I should have to do is locate an ebook reader program on a site such as getjar.com, and download and install it on to my phone, right?
Sure. If it were that simple, I wouldn't have written a blog entry about it now, would I?
So, I go to getjar.com, and scan through the half dozen or so offerings of book readers and test drive one or two of the most promising. Although I'm able to install them, they do not seem to actually allow me to open any text files stored on my phone. The only ones that do work are the ones that embed a book/text file inside the actual .jar (java archive) file itself. I do some research, locate the stats on my phone, and sure enough, it is supposed to support a file system API that allows programs to access the phone's file system. That's JSR 75, if you want to know the Java programmer jargon for it.
The long and short of it is that AT&T does something to the firmware of the phones they provide which prevents third party programs from accessing the filesystem. I get it-- it's for "security purposes." You don't want just any old program being able to access the file system or the GPS interface, otherwise nefarious people might start using it to do bad things to your customers. The part that galls me is that if a third-party developer goes out and spends serious coin ($200/year) on a certificate from someone like Verisign or Thawte, to validate their work as legitimate and unmodified, AT&T still denies them access to JSR 75. You basically have to go through AT&T's internal verification process, which coincidentally will cost you more serious coin, and will not do anything towards making your "write once/run anywhere" program work with other cell phone vendors either.
It's sad, but my interest and enthusiasm in learning how to write Java midlets for cell phones just kinda died.
No comments:
Post a Comment