Nothing, however simple, goes without saying

My girlfriend borrowed a couple of cables from her office today, so I finally managed to wire the E61 to my netbook. As a first best, I hoped, Eclipse Pulsar would recognize my device. As a second best, I was thinking using the new and shiny Ovi suite to install my test app. To the average noob, Pulsar is the usual rhizomy mess of menus and panels, so after toying with the spider awhile I decided to try my luck online, indeed landing a nice Wiki page Entitled “How to install Java ME application in mobile phone“. Among numerous equally-unattractive-to-a-developer ways to install java apps on a nokia phone, I quote:

“If the device has a serial cable port and connectivity software for a PC, the MIDlet can be installed on the device over a serial cable”

Which I edited to:

To install the MIDlet, double-click on either the *.jar or *.jad file and follow on-screen instructions. On a PC, if jar/jad files are not associated with PC suite or Ovi suite by default, you can right click and select “open with” then choose “Ovi suite” or “PC suite” as applicable.

I always thought that PC suite associating jar files to itself in this way is somehow of a pre-emptive way to suggest that java doesn’t have a life beyond Nokia phones. Now I will modify my file associations, as I happen to have tens of thousands of lines of code on my PC that are nothing MIDlet.

I don’t care whether this goes without saying or not. I wasted another hour on this. I’m in a bad mood.

If it doesn’t work, downgrade CLDC and/or MIDP

In Pulsar, open the M folder labeled Application Descriptor. Then select create package to actually get a deployable jar/jad file. Since my device is 5 years old, I had a friendly ‘can’t run application’ or such message when I tried installing. By default, Pulsar is configuring to MIDP 2.1 (at the time of writing this, using the latest SDK). Until I find a reason not to, I’ll just downgrade CLDC and MIDP (in the ‘M panel’) to the oldest version that I can run something against.

Pingoo goes live

After I downgraded MIDP to 2.0, (note the advice on Nokia wiki if it doesn’t work for you), the Pingoo displayed at a decent FPS on my E61. I really need to come up with something chunkier, right?

So I used fractal subdivision in Blender to bump the poly count to ~10,000. This slows down the M3G exporter to a crawl because it spits out console output for every face. The M3G file inflated from 21kb to 565kb. FPS dropped to 2-3 frames per second, flat shaded, with 2 point lights enabled (no textures).

My first attempt at loading my sample 3D scene on an actual device didn’t work out too well.

I have two smartphones handy and one connection cable. Bluetooth died on my netbook long ago anyway. Both devices are 5 years old. Although my E61 is listed as Ovi compatible (the other isn’t), it doesn’t connect. Maybe I just need the right cable :)

Now that I have the Ovi suite installed, I had a quick look and… the prospect isn’t great. I hope they will understand someday that a web browser (versus native software) is just a let-down way to buy apps. So you open the Ovi suite, click on an app and expect pressing a download or buy button. Instead they fire up the default web browser. The UI and store presentation feel unpolished, like they didn’t have UI designers, or CSS enabled coders. Maybe it looks better on-device…

The Ovi suite itself seems like a half baked flash app made by a high school kid. They didn’t even manage a decent scroll bar.

I’m losing interest. And this may be the right time to explain why I’m interested after all. So why should an iPhone dev studio consider other devices?

1. Workflow and release schedule. There are tons (literally tons) of devices out there that have nothing like the screen definition or horse power of an iPod 2nd gen. Meaning you simply can’t put as much content or smart code. Meaning low end devices are a good market for an early release. So with de-spec-ed devices available, you can release a ‘lite’ version earlier, thus abiding to ‘release early, release often’. Meaning that finally you can release a better app (benefiting early feedback etc…) on higher spec devices.
   Just from a technical point of view, java code is safer than compiled code, so even targeting comparable devices, the release cycle is bound to be shorter (that is, unless you mean to release on all and every Java enabled device at once)
2. Not everybody will ever have an iDevice. In my company many people are carrying HTCs running Android. A (happy) few are carrying an iPhone. In the ‘real world’ around us, iPhones are visible exceptions, nothing like the norm. Now don’t tell me everybody will finally get an iPhone. Even taking aside pricing considerations, just imagine what it would be like? A mobile phone is something users carry with them. Consciously or not, their choice of a device reflects their personality as much as their means. One size fits all may be good for OSes – well that’s because an OS is something people don’t care about, as long as it works (and the more it’s like anybody else’s, the more ‘it works’).
3. Anybody can enjoy a nice app. A quick look at the Ovi store shows that people didn’t wait for the iPhone to make mobile games (!). No matter what the store(s) may look like, there is an app market beyond iTunes, and I’m confident this market will grow, part because people see iPhone users enjoy apps on the go, part because manufacturers are making efforts to catch up.

Personally I think plurality is all good, and everybody enjoying the same thing on the same device at the same time is… terrifying. So the sooner competitors put their act together, the happier I’ll be.

But if you stay away from this s**t, I won’t blame you.

I happen  to have an aging Nokia E61 in my top drawer. The E61 is the first mobile I ever used as I proudly held back until 2005. I had simple criteria for getting a phone back in the days:

1. A phone should have a QWERTY keyboard.
2. A phone should be Java compatible
3. A phone should be free (-ly provided with an expensive monthly contract)

Think it over. If all phones followed these 3 laws, they’d probably comply with Asimov’s laws of Robotics as well. And there wouldn’t have been an iPhone either.

Wait, did I actually write that?

Yes, because I want to remind my readers – none the least Antistar players – that Antistar development continues on iPhone. Don’t go think I’m giving up or something. My main problem is that for reasons I’d rather gloss over, I don’t have my sweet Mac Mini handy all day long.

Eventually, I’d like to release our games on both iPhone and other mobile platforms. Experimenting with J2ME is probably slowing down development a little, but I think it will eventually prove helpful (I’ll explain sometimes).

Anyways. I thought it would make sense for me to try running stuff on the E61. That is what I thought when I got this phone. In fact we got two of these at home – bulky, ‘high-tech’ antiques. Good place to get started.

Yea of course the thing’s got PC suite installed. So now I have to download the Ovi suite too.

Polite notice

I have the regret to inform you that Eclipse Pulsar may be a choice solution for your J2ME development.

This is because several manufacturers decided to create a kind of eclipse plugin / flavor that would make it easy to access their simulators, and they chose Eclipse.

I didn’t choose Eclipse. It took two hours fiddling to ‘migrate’ my Pingoo experiment to an Eclipse project. It’s not the first time I used it either. Well, never mind. So Eclipse Pulsar has a way to detect various phone simulators, settings and other fantasies. You have to give it a kick ($foomenu$preferences$devices$crow$klingon$etc or check here for a minimally workable example) first, but it works.

Strictly speaking, the annoyances are owed to the proliferation of utterly mobile meta-data clouding mobile development. Having said that, this is what IDEs are meant to help us with. That and preventing me from renaming my source files.

I think the sample *.m3g files (and the methods used to load and display them) look neat. I also noticed that Blender has an exporter for *.m3g with support for textures, armatures and animation. Gerhard Völkl clearly put a lot of work in this exporter, topping 3000 lines of code in a single file (a couple dozen classes in there, it’s actually quite readable).

(note: on a PC you can find the source for blender py scripts under Documents and Settings\User\Application Data\Blender Foundation\Blender\.blender\scripts)

The linked page also provides samples files to help us understand how the exporter interprets blender files. There are two things I immediately want to know:

• How are animations exported? In Blender, bone animations are not directly connected to armatures. Export plugins typically use a kind of naming convention, and this one makes no exception, for example Talk#A1E10#2 is an action, where A1 refers the target armature, E10 means the animation ends at frame 10, and 2 appears to be the node ID (see below).
• How are node IDs selected? From sample M3G code, it’s fairly obvious that M3G files, for better and for worse, do not contain named entities. Unfortunately the blender M3G exporter uses a naming convention that requires the artist to insert IDs. Maybe this can be improved a little – for example, we could have a java source file with named constants remapping blender object names from arbitrary IDs.

The M3G exporter also allows direct export to java code (in other words, it can generate code which, when run, will produce a scenegraph).

Useful resources

• An informit M3G/JSR184 tutorial
• Wikipedia on JSR184
• A digest of the M3G file format

1. Where to start after downloading the SDKs?

Having a standalone project manager is a good way to invite developers in your mobile world.

So I downloaded the SDKs (see my previous article) and now I’m trying to find out how fast I can get ‘hello world’ working on a simulator. Here’s what I got so far.

• Nokia: there’s a getting-started section on the Nokia site. This is a step by step thing which would be great if I wanted to use NetBeans. I don’t know which IDE I’ll use. I guess I’ll download NetBeans to keep it simple, stupid. Over slow bandwidth, I’ll be waiting.
• Sony Ericsson – can’t find a getting started section online.
• Samsung… Here they have a getting started document that’s not really hard to find, and, apparently, a NetBeans/Eclipse free project wizard. Now, that seems easy enough.

After literally 10 minutes, I got HelloWorld running in a Samsung device simulator.

2. Hello 3D world?

It’s nice to show how to perform I/O operations. It’s even nicer when we know where to find the code samples.

So I decided to stay with the Samsung SDK for now, and try to get 3D stuff running in the simulator.

JSR184 Mobile 3D Graphics API is a tutorial with source code, explaining how to make a 3D app with JME.

It’s a pity the archive linked from the article only provides a .jad file, not the source (plus I run out of luck trying to run this directly.

Never mind, let’s see what we can do with this.

It turned out that the example fits in one file, with a bunch of inner classes. This failed gracefully, throwing a URI exception.

I uncommented a few lines just to get a clean run. Nice black screen. Then I poked around, and finally I got my hands on all code samples, neatly bundled with the SDK (yea, all the nice examples pop up when you choose, ‘Open Project’ in the Samsung SDK tool, but the tutorial doesn’t say that.

I kind of liked the so called Pogoroo example. It’s not very far from the kind of data I want to display, and blender has an .m3g exporter. So I guess I’ll need to slow down a bit and actually learn something.