New TinyG for Android app demo

I worked out a few kinks in the app so that it's more robust in the face of bad data, and published a new demo up on youtube.  This demo walks through all of the current features, including connecting through both the USB and network services and looking at the system configuration.

As I mentioned in an earlier post, I'm working on adding additional support for tablet-sized displays and file upload.  In the meantime however, you can go over to my github page to pull down the latest source, and you can get the main app from Google Play.

USB is working!

I spent some time digging through libftdi, and was able to get USB serial IO to work!  I had a problem sending gcode initially, but it turns out that I wasn't using the Message class correctly for inter-process IO.  Instead of handing the String to the Message directly, I needed to add it as a bundle:

public void send_gcode(String gcode) {
  if (messenger == null)
    return;
  Message msg = Message.obtain(null, TinyGDriver.GCODE, 0, 0, null);
  Bundle b = new Bundle();
  b.putString("gcode", gcode);
  msg.setData(b);
  try {
    messenger.send(msg);
  } catch (RemoteException e) {
    e.printStackTrace();
  }
}

So now all of the controls work via USB as well as through the network!  If you're interested in trying these out but don't have an Android development environment, I've placed packages for both the USB Service module and the TinyG for Android app up on my github site.

I'm working out a few kinks still, but the packages do seem to be useable.  The most important thing to note is that if you want to use the USB module, you need to select USB under Settings in the TinyG menu, but then exit the application.  I need to find a way to signal to main Activity when a preference has changed so that I can reset the Service binding, and I haven't found it yet.  Another point to be aware of is the USB permissions model on Android.  When you try to connect to USB, it will prompt you to make sure it's ok that the app does so.  It seems to be able to save this preference, but that doesn't seem to be reliable for me.

Now that the framework is all set, I can spend some time adding additional features, such as tablet-friendly layouts, and a gcode uploader.

More TinyG Android app work

I've been spending the past couple of weeks refactoring a lot of the existing code.  The network driver worked, but it relied on the bound Android service running in the same process so that it could access member functions.  While I can make that assumption for the network driver, my ultimate goal is to support USB host-connected devices, and that requires Android 3.1 or greater.  I didn't want to limit the use of the app for that one feature, and so I chose to isolate the USB code to a separate app.  The USB driver would have a service with the same API as the network driver, making it easy to change which was in use without a lot of code changes.

I needed to find a better way to have the activities communicate with the service (either USB or network) that was connected to the TinyG.  This communication needed to be bidirectional, and needed to work for multiple activities (screens).  What I settled on was using a Messenger to send commands to the service (asking for data, connect, disconnect, etc), and using broadcast intents to send messages from the service to one or more listening activities.  This seems to give the most flexibility without a lot of effort.  An alternative to the broadcasts would have been client messengers registered on the service end, but it seems like that's a lot of work for little gain.

To make more of the code reusable, I now have three projects on Github.  The main application is android-tinyg, and it contains most of the activities and preference code for the application.  android-tinyg-usb is a skeleton for the USB code, and requires API level 12 or higher.  Both of these rely on code in android-tinyg-support, which has the majority of the JSON parsing, messaging constants, and related items.  The TinyGDriver class is an abstraction for both the network and USB drivers, which subclass it.

I'm done with the refactoring, and it looks like the new code works as expected.  I hope to have a longer demo from my tablet up soon using the new code, and to have a prepackaged apk up on the site and Google Play soon after.