Detecting BlackBerry JDE Version

Recently, I went back and added some preprocessor code (it’s pretty much necessary in the world of J2ME) to ensure that Hecl would compile with older versions of the BlackBerry JDE. However, I also faced a problem: how to figure out what version of the JDE we’re using. It could be my latest cold clouding my mind, but I couldn’t find a simple way to do this. It never seems to be simple with the BlackBerry platform, unfortunately.

I did, however, finally find a nice way to obtain this information programmatically: the bin/rapc.jar file, which ships with the JDE, contains a file called app.version, which, indeed, contains the version of the JDE in use. I hacked up this code to read it and print it out:

File Selector for Java ME

I recently did some work to make Hecl read files, which also means that it can execute Hecl scripts from the phone’s memory. This is especially important for environments like Blackberry, where we will be distributing a signed version of the Hecl application. To create your own Hecl applications, instead of simply replacing the script in the .jar file, you can point to a script on the device’s file system. This is also available for normal Java ME phones, but unfortunately, for an open source project, the cost of a code signing certificate are prohibitive (on Blackberry, it’s only $20, so I bought one with my own money).

In any case, as part of this effort, I developed a very simple ‘file browser’, which is used in Hecl to select a script to execute.

The results are, like all of Hecl, available under an Apache license, which means that you can use it pretty much wherever you want:

http://github.com/davidw/hecl/blob/master/files/org/hecl/files/FileFinder.java

http://github.com/davidw/hecl/blob/master/files/org/hecl/files/FileFinderCallback.java

Of course, if you spot any ways to improve it or fix problems with it, I’d appreciate it if you sent patches back.

Open Source Infrastructure?

What’s your opinion?

I’m considering moving the Hecl project to something a bit more modern in terms of infrastructure.

My rough idea is:

  • The web site stays at http://www.hecl.org

  • github for version control

  • Google Groups for the mailing list.

  • Google Code for the bug tracker. Or is github’s up to snuff at this point?

I don’t need much – Hecl isn’t a huge project in terms of code or number of committers, but SF is starting to feel a bit… “creaky”, so I have started thinking about alternatives, even if we’re in no hurry to jump.

Attracting talent to work on the project is definitely one of my biggest concerns. I think that Groups and Github definitely make that easier than SourceForge, but on the other hand, git is fairly new, and I’m not sure how widely it’s used outside of that geeky core that jumps on anything new.

What do you think? Is it going to be more disruptive to switch infrastructure than the gains from slightly more modern systems? Is it worth switching at all? Is it worth trying to use something like Google Code that at least groups most of the bits and pieces together? If you found it worthwhile to move away from SF, what was the “breaking point” for you?

Android Scripting

This is cool to see, even though it will doubtless take away some market share from Hecl:

http://google-opensource.blogspot.com/2009/06/introducing-android-scripting.html

Importantly, I think it helps to establish that Android is the phone OS for those who want to be able to hack on stuff. With the Apple phones, you’re not supposed to even run interpreters on them. Yuck.

In any case, I think that it still leaves some space for Hecl:

  • Their system uses natively compiled languages that use a JSON RPC system to talk. This makes managing them a bit trickier – Hecl is written entirely in Java and compiled as a ‘native’ Android application.

  • Hecl is very easy to embed, and doesn’t carry around a lot of baggage.

  • Hecl is small – apparently this system clocks in at something like 12 megs! Hecl is something like 500K.

Another cool thing is that this is, like most everything that Google has done with Android, open source under the Apache license (the same one as Hecl), which means that if I get a free moment, I’ll try grabbing some of their console code and integrating it to make a nice Hecl console for Android.

Hecl – for Quilting!

Looking through the logs for HeclBuilder.com, I found this site:

http://www.patchwork-quilt-forum.de/dreieck-aus-quadrat-t2457-s20.html

Which, according to the translation is a discussion on a German site dedicated to patchwork quilting about calculating the right lengths to cut triangles of cloth.

I thought it was really cool to see – not because I’m interested in quilting, or the program is anything brilliant (it’s simple and functional), but because enabling stuff like this is part of what I built Hecl for: to make mobile phone applications easier, quicker, and simpler to create. Someone went and typed in the code on Heclbuilder, got the program running, and now a number of people have a handy tool to do some calculations for their hobby, which is a heck of a lot easier than fooling around with SDK’s, Eclipse or Netbeans, and so on and so forth.

I hope to see more of that sort of thing in the future.

Adding callbacks to Android Hecl

Since I recently added sensor callback support to Android Hecl, I thought I’d write about the process of doing so. It’s really pretty easy.

Ideally, it would not be necessary to write and compile any Java code to create callbacks in Hecl – you could do it all inline. However, I don’t think this is possible at the current time with Android’s bytecode engine, although I could be mistaken. It would be necessary to generate a class, or hang some new methods on an existing class. So, for the time being, we do it the old fashioned way whenever anyone wants a new callback to utilize:

The heart of the matter is this class:

public class HeclCallback implements
          android.app.DatePickerDialog.OnDateSetListener,
          android.app.TimePickerDialog.OnTimeSetListener,
          android.hardware.SensorListener,
          android.widget.AdapterView.OnItemClickListener,
          android.widget.AdapterView.OnItemSelectedListener,
          android.widget.CompoundButton.OnCheckedChangeListener,
          android.widget.DatePicker.OnDateChangedListener,
          android.widget.TimePicker.OnTimeChangedListener,
          android.view.View.OnClickListener {

Which as you can see, implements the various Java listener classes. Each of these requires one or more methods to be implemented in order to receive the actual callbacks. Generally, they are done like so:

public void onItemSelected(AdapterView parent, View v, int position, long id) {
try {
    Vector vec = ListThing.get(script.deepcopy());
    vec.add(ObjectThing.create(parent));
    vec.add(ObjectThing.create(v));
    vec.add(IntThing.create(position));
    vec.add(LongThing.create(id));
    interp.eval(ListThing.create(vec));
} catch (HeclException he) {
    Hecl.logStacktrace(he);
    Log.v("hecl onitemselected callback", he.toString());
}
}

Which is pretty simple as well: the objects that are passed in are wrapped up as Hecl Things, and then the command is run.

The command to use is set from Hecl like so, when we create a new instance of the HeclCallback class:

set callback [callback -new [list [list SelectDemo]]]
$lview setonitemclicklistener $callback

So, the steps are:

  1. Add an “implements” to HeclCallback.
  2. Define the methods that need defining, copying one of the existing methods.
  3. Recompile
  4. Use the ‘callback’ command to instantiate a new HeclCallback class with the command of your choice as the handler for callbacks.

Hecl on the G1

Thanks to Neal McBurnett, Hecl for Android finally got to run wild and free on a real phone. There were some glitches, but by and large, things seem to work, which is always exciting, and something of a relief. Neil says it runs fairly quickly, and looks good. Once again, a big thanks to Neil, and now on to fixing the bugs!

Android itself continues to evolve:

http://fredstechblog.blogspot.com/2008/12/big-updates-ahead-for-android.html

Now, if only I could get ahold of one of those dev phones! Although, truth be told, I think the “G2” or whatever it is, will probably be a significant improvement in terms of fixing up some of what needs improvement over the first generation, so I’ll probably wait until sometime next year and get one of those.

Nokia 6120

I finally got around to getting myself a new mobile phone, as it looks like the Android phones may take a while to arrive here in Europe, unlocked, and my old phone was fading.

I ended up selecting a Nokia 6120 in order to get something that runs Symbian, which has a decent amount of apps above and beyond the Java ME stuff.

So far, I’m fairly happy with the phone. Here are some notes:

  • It’s small and light. Nice!

  • It runs Java ME (J2ME) applications surprisingly slowly. I’m non-plussed by this. And no, it’s not just Hecl, even ShopList, which is quite simple and small (~ 6K), takes several seconds to start up. This is not appreciably faster than on my cheap phone from several years ago.

  • My old, cruddy phone was able to recharge (slowly) via USB. This one doesn’t, as far as I can tell.

  • I bought it from Amazon.de, and the bozos who were the ‘real’ sellers sold me a phone intended for the polish market, meaning the dictionary languages installed are all eastern European – no Italian, which I need. Not the phone’s fault though, and I guess it’s probably possible to replace that stuff.

  • The camera has some weird issues where it leaves streaks. I realize that it’s only a phone camera, but it ought to be able to do better. Here’s an image from my recent trip to Oslo, by way of example:

Oslo Fjord

  • Creating videos wors pretty well though.

  • Playing video is just a bit jerky – it mostly keeps up, but not 100% of the time, when you lose a few frames.

  • Nokia ought to do a better job making sure that it’s integrated with Linux (Ubuntu in my case). That said, things work quite well, by and large, and I was able to get things done with relatively little fiddling.

  • The amount of progress over a few years is very impressive. This phone completely blows my old phone out of the water. Sure, it’s a bit pricier, but it’s way more capable.

All in all, I’m happy with it, but I think that my next phone will be some kind of Android-based device, as that system is way more hackable than Java ME, and the people developing it seem to ‘get it’ a bit more.

That said, I’m glad I got it – I needed something modern to play with Hecl on, and hopefully I will be able to work on using some of the fancier bits of the phone from Hecl.

Oh, and by the way, I’m always on the lookout for phones to try Hecl with – even if they’re old and worn out, the only thing that matters is that they are able to run Java ME applications. Contact me for shipping information:-)

Making Applets Suck Less

With all the effort being poured into Javascript lately, it’s pretty evident that that’s the way forward. However, there are still some neat things you can do with applets that you can’t do with Javascript. For instance, I use the microemulator applet to let people play with a simulated phone on the Hecl web site.

Unfortunately, the user experience hasn’t that good. While playing around with the code for that site, Firefox crashed a number of times, and I’ve heard other browsers have trouble as well. No fun.

So it is with some satisfaction that I found this:

https://jdk6.dev.java.net/plugin2/

It’s an updated Java plugin that seems to work much, much better than the old one. Unfortunately it doesn’t appear as if it will be in the new Ubuntu, as it was released recently, but I’m quite happy to have something a bit more stable to develop with.

You can download that version of the Java SDK or JRE here:

http://download.java.net/jdk6/

It’s good to see this effort, even if it may be a bit late.

Hecl Syntax: A Survey

[ Taken and modified from a post to the hecl-devel mailing list ]

I’ve been talking with a company about a consulting job regarding a programming language for mobile apps. Sounds familiar, right?

There is, however, a bit of discussion regarding the syntax – my contact at said company maintains that Hecl‘s syntax is unfamiliar to many programmers, and I think on the face of it, I’d have to agree. Of course, Hecl’s syntax is like it is because when I started the project, being very small was a necessity, and a very simple syntax facilitated that goal nicely. Additionally, the syntax allows for extreme flexibility, letting you create new control commands, and “DSL’s” (domain specific languages) easily. Also, sticking with small/simple means that the interpreter and parser can both reside on the phone, instead of doing some kind of solution where the development/host computer compiles the scripting language to byte code, and the interpreter on the phone runs the byte code. That sort of strategy has some advantages, but has disadvantages too: if you don’t have an on-board parser, you don’t get “eval”.


A quick Hecl syntax refresher:

In Hecl, everything is a command, seperated by spaces, and grouped with {}:

if { ... } { ... }

Is a command that takes two arguments. It evaluates the first one, and if it’s true, evaluates the second one. This is different from languages like C, Python or Ruby, where ‘if’ is part of the language. For those unfamiliar with languages like Lisp, where this looks strangest is probably in conditions or other expressions:

if { = $foo 10 } { puts "foo is ten" }

Or

set foo [+ [* $bar 10] [- $beebop $doowah]]

Which is certainly a different take on things than most ‘mainstream’ languages. That radical simplification is, however, one of the ways that I used to save space in the interpreter.


Personally, I’m pretty happy with how Hecl looks, but I am sensitive to the ‘marketing’ argument: popularity helps, and this isn’t the first time I’ve heard complaints about Hecl looking “funny” to people.

What do you think?

A) “I like Hecl just the way it is and wouldn’t want to change it!”

B) “Hecl is quite useful, but I just want a mobile scripting language, the syntax doesn’t matter much.”

C) “I think the syntax is ugly, but I use it because I need an interpreter.”

Also related:

1) “I don’t care too much about code size. My current apps target N kb as an acceptable size.”

2) “Small is really important. The smaller the better.”

And:

I) “I don’t care about eval, or being able to run human readable code on the phone.”

II) “I really like the fact that you can download or even write code directly on the phone.”

And finally:

X) “I don’t care about midp1.0”

Y) “The fact that Hecl runs on midp1.0/cldc1.0 is important to me.”

Now, I am not going to run off and change Hecl! Code that currently runs ought to continue to run, modulo some tweaks here and there, api changes, and the normal stuff. If I do something ‘new’, it would probably be a clean break (although of course code that could be reused would be), and will be in addition to Hecl, rather than instead of Hecl, because I would be working on the ‘new’ language as a day job. I do that with Hecl too, but not all the time, as I often have consulting/contracting work.