Rant: Ubuntu, Google, J2ME

Long day, lots of broken stuff. Rant time:

  • Ubuntu’s Intrepid Ibex has way too many regressions. I’ve mentioned this before talking about wireless, but also on the sidelines are bluetooth and my laptop’s multimedia keys. Other things are probably slipping my mind, but that’s what’s bugging me today. I’ve use Linux for a while, and am used to not always having everything working just right, but “it’s never worked” is less annoying than “it used to work but this release broke it”. Also, I bought this computer from Dell because it shipped with Ubuntu. I would have expected the Ubuntu guys to have a few around themselves to test on prior to release.

  • J2ME marketing: http://blogs.sun.com/hinkmond/entry/getjar_3rd_annual_mobile_awards GetJar is a nice service, and I put my own ShopList app there, but you can’t seriously compare it to the Apple or Android stores without insulting my intelligence. What percentage of people with J2ME capable phones actually use GetJar? Is it on their phone when they turn it on? Can developers actually sell stuff there?

  • Google has started dumping lots of my mail in the spam folder since I switched the domain over to a new server. I can’t believe they’re dumping so much non spam mail, and yet can’t figure out that I have never, not once, received an email written in Chinese characters that I actually wanted to read.

Add in some bugs and broken stuff of my own, and it’s made for a frustrating day.

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.