Android Scripting

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

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.

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.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());
} catch (HeclException 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:

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.

Android is out!

As most people probably know by now, the Android source code is available, as promised:

The next part is the interesting part, though, in my opinion. Source code is wonderful, and a huge gift from Google, but the real “secret sauce” for the most successful open source projects is the community. It will be interesting to see how Google manages this aspect of their project. It could be a situation where they create, and the public consumes, and it’s fairly one way, with the odd patch here and there going back. Or it could be that they’ll really let people get involved. Running a community for something this big, with this much code, and this much interest to the world at large is a daunting task, but Google certainly has the open source expertise to figure it out, so what we end up seeing will depend on exactly how Google wants to manage things.

All in all though, a big step for open source – congratulations to all the people at Google who made it happen!

Android Phone – I want one!

Early details:

  • Coming out in October.
  • UK in early November, Europe by first quarter 2009.
  • Simlocked to T-Mobile.
  • Source code! When the phone comes out. Hopefully someone will use it to unlock the thing.
  • 179$ – not bad.
  • MP3’s from Amazon.
  • Market app built in.
  • Neat use of Google Maps street view.

I’m sold, I want one. It might not be quite as flashy as the iPhone, but I want something open.

Android marches on

This was unexpected, but very welcome: a new Android SDK, with a bunch of updates, and a “roadmap”.

It also looks as if we may see some phones right when they were supposed to be available:

Of course, there is no source code, yet, but it’s still good to see things kicked into gear and running again.


Well, to be charitable, it was a bit late and so perhaps what I said came out wrong, but in this article:

I’m quoted as saying the problem is with “upper management”, which I don’t really believe to be the case, going by snippets of conversations and things I’ve read. Frankly, at this point in time, I have no idea why Google can’t talk about Android.

Also, I had several other positive things to say to the reporter, but I guess the ‘focus’ of the piece was about the problems that Android is currently experiencing. Notwithstanding the recent weirdness, I’m quite happy that someone with a lot of money and muscle is going to be backing an open source mobile phone system, and hope that the current troubles are merely a small speed bump.