Confession time: I have never learnt to program in Java. Swoon, gasp.

It’s not that I haven’t wanted to. In particular, I’ve always loved the idea of creating my own mobile phone apps; but I’ve never seemed to find the time. So I was excited to discover at the weekend that Google has finally given me access to App Inventor — a visual development environment that lets you create Android applications via a drag-and-drop interface, with no Java skills required.

It certainly does simplify the process. The first sample application – which puts up a picture of a cat that miaows when you prod it – is embarrassingly easy to assemble. In the design stage, you simply drag a button onto your workspace (representing the phone screen), import the cat picture, assign the picture to the button and import the sound. Create a click event that plays the sound, and the job’s done.

So yes, the workflow is similar to Microsoft Visual Studio — not that there’s anything wrong with that. But there’s one big difference: in VB.NET, setting up an event handler for the button involves getting to grips with some daunting syntax, along the lines of: Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

In App Inventor you assemble an event handler by simply snapping colour-coded, jigsaw-piece-shaped “blocks” together. In fact, all “code” is constructed by combining blocks within the Java-based Blocks Editor. As Google freely acknowledges, it’s a system that owes a heavy debt to MIT’s Scratch project, an educational programming system which we’ve already produced a tutorial for in our Free Computing Lessons for Kids feature.

Childishly simple?

Does this indicate that App Inventor is similarly intended for kids? Yes and no. Google has said that App Inventor was designed from “an educational perspective”, and tested in “classrooms across the United States”, which sounds like a pretty clear hint. But then Google’s Mark Friedman has also described it as a broader tool, for “programmers and non-programmers, professionals and students” alike. Certainly it can support constructions as sophisticated as anything you’ll find in more grown-up languages:

So while App Inventor is aimed primarily at kids, it’s not just a classroom tool. In principle, it should be powerful enough to produce any application you can imagine.

Writers’ blocks

Sadly, as soon as I started using App Inventor, I discovered the catch. Dragging blocks about may be a fine first introduction to computing, but if you want to create anything more complex than “Pet the Kitty” it’s a slow and fiddly way to work. It doesn’t help that the blocks you need are split across two tabs of seven or more drawers, and as you build up functions the workspace becomes messier and harder to navigate (see the screenshot at the top of this post). Perhaps in time the Blocks Editor will improve, but right now it’s such a faff I can see it driving people away from programming altogether.

That’s a shame, because some of the functions on offer seem designed to appeal to experienced coders, and support some neat mobile-specific capabilities:

But if you ask me, this representation is actually harder to understand than a function written in plain text — and it was certainly harder to construct.

All of which leaves App Inventor looking like a missed opportunity. Yes, for the kids at whom it’s chiefly aimed, it’s a decent introduction to programming concepts. But it has potential far beyond that, and I fear that will never be usefully harnessed, because anyone with the programming nous to make full use of App Inventor’s abilities will surely prefer a language that doesn’t force you to pedantically assemble every function, procedure and event out of multicoloured blocks.

Rewriting the script

In fairness, it’s optimistic to think that any development environment could ever be perfect for both beginner projects and more complex designs. But, tantalisingly, I think App Inventor could get close with one single addition. What’s needed is a traditional script-based view that operates in parallel with the Blocks Editor. For beginners, this would show automatically-generated code (presumably using simple Java-type syntax) representing their block-based constructions, making App Inventor an even better introduction to programming.

Meanwhile, more advanced users could develop directly within the script editor, while still using App Inventor as a time-saving tool for designing interfaces and packaging completed projects. The blocks view, automatically generated from your code, would become a handy visual aid to debugging and program flow.

But in the absence of a script editor, I doubt I’ll be producing any mobile applications with App Inventor. Google certainly deserves credit for the excellent work it’s done in simplifying Android development, and abstracting it away from the nitty gritty of libraries and dependencies. But if the only way to take advantage of that is via drag-and-drop programming then personally I think I might be better off simply learning Java.

Having spent the past couple of days wilfully ignoring the Java update nagging away in my System Tray, I finally relented and installed the latest version, only to be confronted with the following screen:

Admittedly, Sun was only trying to force the OpenOffice installer on me, rather than automatically downloading the hundreds of megabytes that comprise the full suite. But after the furore caused when Apple automatically ticked the Safari installation with iTunes updates earlier this year, it’s amazing that companies are still resorting to such cheap tricks.

So anyway, get yourself into your time machine and set it for sometime around 1986. Once you get there, pop on your invisibility cloak, find someone who looks spoddy and follow them into the dining room. See that BBC Micro in the corner? Pop over and give the top a quick tug. Chances are it’s not screwed down.

That’s because, in the old days, computers were for hobbyists with soldering irons, and they were forever taking the tops off to install new circuit boards they’d made.

Doesn’t happen much anymore, of course – you might pop the side off once a year to install a new graphics card, but most people wouldn’t consider actually building new hardware to go inside their computer. And for very good reason: the insides of a modern PC are massively more complex and to build an add-on part yourself that would actually be any use is more or less impossible.

Thing is though, designing and connecting your own hardware to a PC, while unlikely to win you admiring glances from the opposite sex, is bloody good fun. Fact. I’ve been tinkering with the whole area again for the past year or so – for reasons I may document at some point – and it turns out that there’s a massive array of components that are relatively easy to interface to a PC and do interesting things with.

So here’s what I’ve done: I’ve interfaced a Microchip MCP3202-C analogue-to-digital converter IC to the parallel port of a PC. And voila, I can use the computer to directly measure any analogue voltage between 0 and 5 volts. In fact I can measure two lots of voltages since the 3202 is a dual-channel device.

Now, the ability to measure some voltage or other doesn’t sound terrifically interesting per se. But it is! Because there’s a vast array of sensors and transducers out there, which measure all sorts of fascinating things about the real world like temperature and pressure and position and humidity and everything. And guess what their output is? Yes! Very often these devices produce an analogue voltage, and very often it’s between 0 and 5V (since 5V is kind of a universal logic voltage).

It’s certainly not as easy as it used to be to connect your computer to the real world. The BBC Micro, for instance, was specifically designed for interfacing and you didn’t even need any external circuitry to measure analogue voltages – you just used the analogue input ports on the back and read the voltage directly from BASIC with the ADVAL statement.

To get my 3202 ADC chip talking to a PC, I first had to add a little bit more buffer circuitry, to get the anaemic voltage levels coming out of its parallel ports to look a bit cleaner. But that’s only a single logic chip, costing about 20p (the 3202 itself currently costs £2.25 from Farnell if you’re only buying one or two).

Next, I abandoned Windows and installed Fedora Linux. Why? Because Linux has the joy of a predictable, stable tool-chain for programming, and it comes with a C compiler and everything you need for programming. It’s a geek’s OS and it’s set up for geeks to tinker with straight away. And if everything you need isn’t there in your particular installation, chances are all you’ll need to do is issue a command something like this:

sudo apt-get install gcc

And off Linux will go, ferreting out the gcc C compiler and all the necessary extra components. Also, of course, it’s free. And I wouldn’t dream of installing Windows on a PC when I didn’t have the correct license.

With that done, I had to decide on a programming environment. Java is my language of choice – it’s the best language on the planet and those people who talk about its nightmarishly complex class libraries are all wrong, honest – so Sun’s brilliant (and free) Netbeans IDE was the only sensible choice.

You may be seeing the problem looming. Java is a high-level language deliberately abstracted from the hardware it runs on, meaning that getting the low-level access I needed to interface with my ADC chip wasn’t going to happen with Java alone. That meant one thing: JNI, the Java Native Interface, which allows you to write native C code and glue it to a Java method. That means fast, native access to the hardware combined with a lovely high-level language to write the graphical front-end for my app.

Only problem with JNI is that it’s hideous. I mean truly hideous. It’s badly implemented and appallingly documented and it took me a week of trial and error actually to mangle my C code for reading the ADC chip into a form that JNI could work with. But eventually I got there.

There’s nothing quite like getting really deeply into the binary operation of a chip. The 3202 IC uses a simple serial protocol called SPI to communicate with the outside world. So I had to sit down with the datasheet in hand and write a routine in C that would directly communicate with the chip in binary, by waggling the voltage level of three of the PC’s parallel-port pins between 0 and 5V. Fairly amazingly, once I’d sorted out the JNI thing it worked first time. My Java graphical front-end can get the voltage levels and display them any way I like, and the hardware can manage a sample rate of about 2,000 readings per second, if I happen to want to measure something that fast.

Not as easy as with a BBC Micro then, but here’s the thing: BBC Micros used to cost about a month’s wages, so the chances of dedicating one to measuring the temperature in the greenhouse were always going to be pretty slim. A little Mini-ITX motherboard – which is what I’m using for my project – is only about £100. That means you can use one as a hardware appliance and dedicate it to the task of measuring, well, whatever it is you want to measure. And it’s the matter of an evening or two’s work to configure a web server and write some code so that you can communicate with it from anywhere and see what it’s been getting up to.

All a little bit pointless? Well, maybe. Fun? Depends on your proclivities I suppose. But it makes me happy.

So, who wants a feature in PC Pro about how to do it?