Via Freshmeat, RSS Reader MIDlet allows you to read RSS feeds on your MIDP1+ J2ME device. The UI seems to make a little more sense than Peek and Pick. P900 and 6600 users should also take a look at FeedBurner Mobile Feed Reader.
Welcome back from Radio silence. While I wasn’t uploading to the world, I wrote a few entries that are definitely worth looking at, even if they were written a few days ago:
- Java Location API: Where are the Phones? Phones with GPS that implement the location API could be a huge thing. So far, they’re just not out there. I’m not up on Asian phones, which I’m sure are light years ahead, but I don’t really see anything in the US or European markets to speak of. Moto’s i730 does not implement an API to the JSR spec, but at least it has GPS and we can get to the data. That’s the important part.
- How Much Does JSR-179 Rock? My ode to simple and effective API calls. Of course it takes a lot more than those few lines to “do it right” but it makes a ton of sense. Moto’s location API isn’t half bad either. Like I said, I just want the data.
- J2ME Link Roundup was a linkdump of a lot of the pages that I had been looking at while groking location and messaging in J2ME.
Here is a collection of links that summarizes what has piqued my interest in the J2ME arena in the past few weeks.
- Location Based Services
- Wireless Messaing API
- The Legion of the Bouncy Castle is a lightweight crypto library that they have shaved down to fit with MIDP development. If you obfusticate before loading your app, you can considerably whack the size of the bouncy castle files needed.
- Encrypt data within mobile apps is a tutorial at IBM developerWorks.
- Securing wireless J2ME is an article at developerWorks. It’s older, but a lot of concepts still apply.
- Programming Wireless Devices with the Java 2 Platform, Micro Edition (Second Edition): Don’t judge a book by its cover. Inside this boring facade is a lot of information. The book tears apart and analyzes the Smart Ticket app, gives lots of good advice, and shows advanced examples of the Mobile Messaging API and in general just rocks.
- Wireless Java: Developing with J2ME (Second Edition): Very useful but it spends a good chunk of space talking about game development, which is very important in MIDP 2.0, but not my cup of tea.
- Enterprise J2ME: Developing Mobile Java Applications: this one is light on general MIDP 2.0 hacking, but deals extensively with hooking J2ME apps into the corporate backend. If that’s what you want to do, this book is for you.
- Bluetooth for Java: if you want to play with Bluetooth and you have a mobile phone that supports JSR-82, you want this book. The source code for it is very useful.
Location Based Services are the next big thing in wireless development (or are they the current big thing?). Everybody is working on it or has a friend that is. Unfortunately get the data to do LBS right, you’ve got to be pretty cozy with carriers. In the US, carriers are rolling out plans to make all cell phones locatable by one means or another in compliance with E911 laws. With all of the momentum tha LBS have, where are phones that support JSR-179, the Location API for J2ME? They’re just not out. And they’re not in the specs of any phones that I see on the horizon.
Motorola gets two gold stars for including a proprietary but working location API in their i730. It may not comply with the JSR, but who cares? At least we can use an API to figure out where the hell we are. I would love to just hop on the Moto bandwagon and develop LBS for the i730, but it’s an iDEN phone. iDEN rocks, don’t get me wrong, it’s just the opposite of developer friendly. See my rant from last week if you’d like to know more. The long and short of it is that there’s no way for me to distribute apps without going through their RIAA-like development and distribution model and only getting 20% of the profits.
There’s no way to give apps away for free either. You can’t download apps OTA like you can on other platforms.
What the world (and J2ME developers in particular) need are more phones on more open platforms that support any kind of location API, but preferably conforming to JSR-179. I’ll take anything at this point though. Nokia are you listening? What about Sony Ericsson? What about the Moto GSM division? Hell, I’d even write apps for Sprint phones if I could have access to a location API and let users download OTA.
Let this be a message to cel phone makers and MIDP implementors: give us a location API and we can write some killer apps that will sell you more phones.
Via Fred by way of Erik, Sparta is an open source XML parser for J2ME recently released as open source by HP Labs. It implements a DOM and is not written for J2ME in particular. However, using Sparta in a J2ME environment should present no problems. Sparta implements XPath, and I’m excited about the possibility of XPath in my pocket.
I didn’t even realize that there was anything left of Strangeberry beyond a splash screen at a dot com address. Needless to say, expect Rendezvous support and other fun stuff in TiVos down the road. TiVo announced that they were working on rendezvous support last year at CES, though not owning a TiVo, I’m not sure if the tech has wandered in to production yet.
The electronic version of Java Developer’s Journal showed up in my inbox today. I must say that overall I love the redesign, except for the lack of a J2ME section. With the redesign comes four sections: Home (introductory and departments), Enterprise, Core, and Desktop. The previous organization of the magazine included a J2ME section.
So why did JDJ drop J2ME from its lineup? There simply were not enough articles to fill the section. There always seem to be enough J2EE or J2SE articles, but never enough J2ME. It is not as if everything there is to say about J2ME has been said. Quite the opposite. J2ME may no longer be in its infancy, but it is still quite young. New JSRs are constantly coming out that pertain to J2ME. Just check out Sun’s J2ME page and look at all of them.
J2ME continues to evolve, and at the same time many people use and develop for J2ME on a daily basis. There have already been two major releases on the CLDC/MIDP side with things seeming to stagnate a bit on the CDC side. And then there’s the EOLing of PersonalJava, but that’s another story.
There continue to be excellent articles at java.com, many J2ME articles at IBM DeveloperWorks, and Erik also keeps track of a lot of J2ME articles and blog entries. This is great, however I am still dissapointed at the lack of J2ME articles appearing in print. I have also noticed that J2ME has been around long enough to have a fair amount of outdated material and stagnant software. If we are not careful, stagnation and a lack of publications could cause major problems for J2ME
I must have blinked, because a new blojsom release is out.
The JabberWookie Library for Jabber is intended to be a complete, extensible, simple to use, Java implementation of the Jabber protocol (aka XMPP). I have personaly used it for both client-server and component-server connections with much success.
Three libraries from SSTR are the only external dependencies.
It is amazing what one can learn via IRC and a Jim Hughes proxy about a new phone. Someone from Sendo showed up at the All About Symbian/Mobitopia pub meet this evening in the UK. I learned quite a lot.
They’re not using MIDP 2.0. They don’t think that it’s stable enough. That’s pretty big thing considering that the Sendo X is a brand new phone. Sendo seems to be making a lot of interesting decisions like this, and I’m inclined to believe that they are making the correct ones. Luckily for J2ME developers, Sendo has included many JSR’s to their MIDP implementation, which brings the usefulness of J2ME on the Sendo X well beyond a stock Series 60 device. Yes, I’m told that our good buddy JSR-82 (Bluetooth) is among the bunch.
So from a programmer/platform, the Sendo is in a unique position. It is a spanking new Series 60 phone to the market. It comes from a company known for their solid lower end phones. It has MIDP 1.0 but lots of extra goodies. It has that XML-based Now! screen. It can accept an SD card! (praise be to the engineer(s) who is/are repsonsible for that one!)
All of this is coming from a relatively small company (read: agile) that has what it takes but lacks brand recognition. These are interesting times for Series 60.
It is also quite interesting to see the definition of Series 60 broaden and broaden. We’ve got Series 60 running on multiple versions of Symbian OS, with varying levels of capability (7650 to 6600 to the forthcoming SX-1), and various stages of product lifecycle.
I still keep coming back to their decision to use MIDP 1.0 rather than the up-and-coming MIDP 2.0. Is MIDP 2.0 really that unstable? As long as Sendo includes a few critical JSRs, they should be just fine (and pretty much equivalent to MIDP 2.0). I’m sure this is unrelated, but Russ is having a helluva time getting Java stuff to run on his 6600.
J2EE is as powerful as any developer could ever dream. But with power comes complexity. All the J2EE specifications put side by side easily take a yard of shelf space. While I have a hard time visualizing enterprise technology becoming “easy” in my lifetime, it can–and should–be easier. If J2EE is to achieve mass adoption while maintaining what makes J2EE powerful, it must become easier.
Overall Nielsen seems pretty sure that J2EE will rock if issues of complexity and changing standards.
For example, a JBoss plugin would let you declare all the system requirements -memory options, system requirements, and the plugin would get the hypervisor to alloc the appropriate system, then we’d generate jboss boot scripts that would set up the JVM right, run the system, etc, etc. The cool thing is its dynamicity -you can deploy to new machines in a snap.
Sounds whacky cool.
8. Ask users to prove their loyalty and dedication to your cause by demanding they add jar files to ANT_HOME/lib. For extra points, do not tell them what these jar files are. It can be a test of the true faithful to see if they can figure it out from an ant stacktrace and find out what jar to download from where.
I was curious how much it would take to get a Hello World style app running on a Series 90 (the platform that the Nokia 7700 is based on) emulator. The answer is just the following three downloads:
- Developer Platform 2.0 for Series 90 MIDP Concept SDKs
- Nokia Developer’s Suite 2.0 for J2ME
- J2ME Wireless Toolkit
I took the code from Getting Started with MIDlet Development, built it, packaged it, and ran the emulator with
emulator -classpath HelloSuite.jar HelloMIDlet. Once everything was downloaded and installed, the Hello World process took just a minute or two. It was well below the 5 minute threshold that Russ has deemed neccesary for wireless development.
You’ll note that on the emulator, the thumb buttons and keypad are reversed from those on the 7700. The emulator/SDK release is versioned 0.1, so beware. I’m sure that some things will change before the official release of the 7700.
I have a feeling that we are going to see a ton of apps written for Series 90 and the 7700 in particular. My guess is that we will see lots of J2ME apps, but the killer apps will be built using C++. In skimming the docs, it looks like I have at least limited access to the camera, wireless messaging, mobile media, and bluetooth. This is much different than the super sandbox that is MIDP 1.0.
I’m checking out Memoranda, a java-based diary and scheduling program. I’m not used to is WYSIWIG editor, but it’s pretty cool. It looks like it can also export notes to HTML. It is definitely pretty, but not fully functional. It’s an alpha, so that’s okay.
Software development company Borland Software on Tuesday introduced an overhauled edition of its Java programming tool designed to simplify creation of Web applications.
So far I see support for JBoss and a visual Struts designer as big plusses. It looks like we’ll be seeing a JBuilder X Foundation with more liberal licensing terms. This is good.
More information can be gleaned from Borland’s JBuilder site.