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.

Google, Android, and the case of the missing communication

Like many people, I participated in the Google Android contest this spring, and like most of them, I didn’t win, but I did enjoy working with the platform, and am very excited about the idea of an open source mobile platform that’s relatively powerful.

From the outset, due to the lack of actual source code for a lot of the system, there have been “doubters” about what Google is really up to. I’m not one of them, and am largely ok with their reasons for holding back: I buy their reasoning that the long term benefits of a strong, properly QA’ed launch probably outweigh the possibility of failure that might come from the press and the public at large that doesn’t care much about software freedom seeing phones come out with half-baked, early implementations. I think most of us working with Android were ok with that strategy, and the ones who weren’t self-selected out of the platform, most likely.

However, lately Google has made something of a mess of their communications regarding Android. The problem stems from the fact that they gave an updated version of the SDK only to the winners of the competition, which for a lot of people felt like a bit of a slap in the face: they helped popularize the platform by participating in the contest and writing applications for it, and in return got excluded from the upgrade path. Personally, it’s not really any skin off my nose, as I’m sanguine about the Hecl port proceeding apace when the new SDK is public, but I can see that if you were, say, a company porting your app to the platform and now are left behind the competition winners, you might be a bit irritated.

The biggest mistake they’ve made though, is a big lack of communication regarding this business. As I said, I don’t really have that much skin in the game, and if they explained in a convincing way why they needed to do things that way, they would go a long ways to allaying the frustrations felt by many.

I’m not much of a believer in conspiracy theories and plots, especially where companies are concerned. Inept bumbling is a far more likely explanation in most cases, including this one. What is odd, though, is that Google has a lot of people who “get it”. I met Dan Morrill at the Munich Android event, and he definitely gets it. He writes about his frustrations as a developer advocate and all the crazy things people say. Well, one way to reduce the number of batty internet theories (eliminating them is clearly impossible due to the alien mind control rays) is to consistently communicate quality information about what’s really going on, something that has been lacking with regards to the SDK question. Here’s another Google employee who understands this need to communicate, and apparently does so despite being worried about being “slapped for talking publicy about all this”:

But the root of the problem is certainly not licensing but that there hasn’t
been a new public SDK release
since M5, while at the same time a small group of people received updated
versions privately.

I really don’t know precisely why this happened; but I’m sure it has more to
do with logistics and reducing
the burden of support while we shift priorities (to shipping real devices)
rather than politics or any will of our
part to “hurt the community” (come one guys, we are not that stupid… !)

While others in the team may disagree, I think it was very very unfortunate;
some of us are trying to
prepare a new SDK release, but it’s a lot harder than I can comment on here,
so don’t hold your breath
because it might not happen that soon.

This explains things in part, but still leaves us in the dark, and leaves me with the feeling that someone in power, somewhere at Google, despite his or her clued in colleagues, really doesn’t get it with regards to open source.

I’m still unconcerned about the Android source code: I think we’ll see it, but to be a true open source project, Android will need an open community as well, not one where decisions are taken exclusively at Google, and not even communicated to the development community at large. All in all, this mistake is more molehill than mountain, but however you look at it, in terms of open source, it is a step backwards.

Hecl Jacta Est

I don’t know if androids dream of electric sheep, but I’ve certainly been losing a lot of sleep over Google’s Android, and am glad that the Android Developer Challenge is winding up, as I’ve been doing all Android, all the time for the past month or so.

I have greatly enjoyed working with Android, as it’s much more capable than Java ME. It’s still very much a work in progress, and only time will tell if Google and their partners are able to best current mobile programming systems… or if the web will simply obviate the whole thing, as it’s doing in many other areas. Win or lose, I will continue to support Android as a platform that Hecl runs on, but in the meantime, I hope to go back and look at some less future-oriented code and get back to some Java ME work. More on that soon…

In any case, here’s hoping that the contest judges see the value in bringing a scripting language to mobile phones! I also hope to see actual hardware soon, as I’m really looking forward to getting my own Android phone.

Mass customization of Android applications

As I mentioned in an earlier article, one of the goals for the Android port of Hecl is to make it as easy as it is to create Java ME applications:

  1. Write the script.
  2. Wrap it up and send it to the phone.

No “compiling” (well, none that’s obvious or explicitly asked of the user, at least, as we’ll see) or fiddling with build files or writing new Java classes or any of that.

We’re still not there yet 100%, but I did managed to hack together a system that, from an original Hecl.apk, creates a new application that can be installed on the emulator. This is tricky, because Android looks at the uniqueness of the package and class utilized for the application, meaning you can’t just rename Hecl.apk to Foo.apk and install it as a separate app. The emulator will overwrite your old copy of Hecl.

Here’s what we go through to make this work. Be forewarned – big, ugly hacks that are not for the faint of heart follow. The command line isn’t exactly beautiful either, but it beats all the individual steps that it replaces, as we’ll see.

java -jar /home/davidw/workshop/hecl/jars/AndroidBuilder.jar -android 
    /opt/android-sdk_m5-rc15_linux-x86/ -class Example -label "Hecl Example" 
    -package my.example -permissions ACCESS_LOCATION,ACCESS_GPS
  1. The first thing that needs to be done is to replace the AndroidManifest.xml that is contained within our “template” application, that resides in Hecl.apk, a copy of which is contained within the AndroidBuilder jar file. Since the compiled version of the xml file is a binary format that hasn’t been reverse engineered or documented yet, the best way to do this was to simply:
  2. Write out a new AndroidManifest.xml in our temporary work directory that uses our provided package name, label and class.
  3. Using the aapt command in the SDK, create a new, empty apk file, specifying the newly created xml file as the manifest file to use.
  4. Now we can extract the compiled version of the xml file, for later use.
  5. At this point, we extract a version of Hecl.jar contained within AndroidBuilder.jar to the temp directory.
  6. Now we need to generate some Java classes that correspond to the new package and class names that we’ve passed to AndroidBuilder. Ideally, I would have done this with some tools to write the byte code out directly, since the classes are so simple: all they do is subclass the Hecl and SubHecl classes so that methods fall through to those.
  7. But instead, I just write out the .java code and compile it.
  8. The two new classes get stashed inside the copy of Hecl.jar that we’re working with.
  9. We now use the dx command to compile the entire jar into the classes.dex file that Android uses.
  10. Since Hecl.apk is just a zip file, we can replace the AndroidManifest.xml file and classes.dex file with the new files we have created.
  11. At this point, we rename the whole works, and move it out of the temporary working directory to the current directory.

Phew! That’s a lot of ugly work. It’s obvious that a lot of this should and could be handled in a less “brute force” way, but for now it gets the job done. The only thing left to do is replace the Hecl script, which is very easy:

zip -r Example.apk res/raw/script.hcl

This makes it possible to whip out new Android Hecl scripts without carrying around a lot of project infrastructure – all you really need is AndroidBuilder.jar and your script.

Naturally, all of this is very much a work in progress, so it may not work as advertised, and, given the mess that we go through, bugs are likely as well. Do report them if you find any, and have fun! In the future, it will be necessary to make it so that it’s possible to add resources to the apk file with zip, and have them be available to Hecl applications, which was actually the focus of the previous article.