Wednesday, January 11, 2012

Upcoming talk: Android App Development with Eclipse and the SDK

I went to the ENGRCS club meeting yesterday at Clark, and Izad asked if I could do a brief talk on Android development. I'm going to do that in 2 weeks, following the 24 Jan meeting. I'm planning to talk about the following:

  • creating a new project;
  • basic GUI layout/properties/etc.
  • where you write your code (onCreate()...);
  • how to find your objects (findViewById);
  • coding for events; and
  • compiling/debugging/executing.
I hope to go through some simple demos, including a basic Hello World app, some interactions with pushbuttons, and an example of reading sensors.

Things I may also get to include:
  • virtual devices (AVD) - so you can develop without an actual Android device;
  • adb (Android Debugging Bridge) - really useful and fun if you do have an Android device;
  • intents (e.g. receiving SMS messages);
  • application lifecycle;
  • string externalization; and
  • database interaction (e.g. reading your contacts).
If you're interested in working along during this discussion, you'll probably want to have pre-installed Eclipse, the Android ADT plugin, and the Android SDK. This can take a long time, and I'm not really planning to discuss the details of it; excellent instructions are available at   I followed the instructions blindly, with very little understanding of what I was doing, and it worked out fine :)

DISCLAIMER: I've got a lot of programming experience in general (more than I care to admit), but I am not an expert Android developer, nor am I the least bit proficient at using Eclipse. I've learned enough to develop some simple apps of my own, but I still take some things on faith; I'm still working somewhat at the cut-and-paste level for certain things; and I don't know anything about "best practices" and so on. But I have figured out enough to get started and to navigate the SDK documentation, and given enough time and good fast techno music, I can generally get things working, eventually. My goal is just to help others get to that point.

Monday, January 9, 2012

Android BASIC

This is cool - playing on a friend's Kindle last week, I found an app called "BASIC!" It's good old BASIC as we all know and love it, but with hooks for most of the good Android hardware like GPS, WiFi, camera, etc. It's pretty darn cool; doesn't teach you anything about Android per se, but if you want a simple/fast way to start interacting with Android hardware, it's about the quickest route I can imagine. For example:
gps.latitude i

will load your current latitude into i.

tts.speak "Hello there"

will invoke the speech synthesis subsystem and speak your text. Seems like a quick way to try out some HW-related ideas and see if they're worth pursuing; or to simply entice people that Android is cool :)


I've been programming for a long time - in C, assembly, Java, and a variety of other languages, under Unix/linux, VMS, RSTS, CMS, and of course Windows; but I'm very new to Android programming, and the experience has been different from what I expected. I'm far from an expert, so some of my perceptions may still be off the mark; this is just my current understanding of things...

As I've discussed elsewhere, I had never been fond of IDEs. But looking at documentation for the Android SDK was compelling enough to get me to stick with Eclipse, long enough to get over the first big bumps in the learning curve. I've since grown sort of fond of the whole integrated-environment approach :)

My first attempts at Android were based on a Hello World tutorial. It was fairly painless, the end-result worked as expected, and I could make minor changes to the code; but it wasn't very satisfying.

A while later, I tried Google App Inventor. I had read about this and downloaded the software, but not actually fired it up. Around the time I started playing with Lego Mindstorm, I finally tried App Inventor. It was fun! Pretty limited compared to the entire SDK (or so it seemed to me), but really fun nonetheless.

After clearing the Eclipse mental-hurdle (separate post), I was finally able to start using the SDK. Some things, like displaying text on the screen or responding to button presses, were straightforward to implement. Others required a but of a paradigm shift. For example, sending text messages. While I could create an object and invoke methods to send a message, I also needed to register to receive information about the success/failure of that operation. The keyword here is "intents." As far as I can tell, by registering an intent, you put yourself in line to receive (effectively) callbacks following certain actions. That's a mangled explanation I'm sure, but good enough for working purposes for now.

Intents are also used to receive incoming messages: you register a receiving intent, and when a message arrives, your code will be executed.

The debugging environment is pretty sweet: you can create virtual Android devices, and interact with them the way you would with an Android phone. This is where I began to notice that my Asus netbook is a bit slow for this kind of processing. It worked fine for writing a dissertation (and for doing the actual work on which that dissertation was based), but trying to start 2 virtual devices could take an hour or more. Starting the device from scratch, with no SAVE option, and very little else running seemed to help.

My first surprise came when I started downloading apps to my actual Android phone. Things worked great while the app was running, but after I exited, incoming texts would generate error messages. Moreover, if I rebooted, and never ran the application even once, incoming txxts would still generate error messages. This was a bit confusing to me at first, until I read up on the Android App Lifecycle.

On most operating systems I've worked with, installing a program basically meant copying an executable file into a path where it could later be invoked; but if you didn't invoke it, it was simply a file on disk. In Android, things seem quite different. When you install an app, it seems like it actually becomes part of the OS. In particular, in my case, its intents were registered as soon as the phone booted, and when a text message arrived, the OS tried to instantiate a method on a non-existent object, which generated the errors I was seeing. The key to working with this is to understand that Apps are, in some sense, always "running" (not really); you specify in different pieces of code what to do when the app is visible, when it's backgrounded, when it becomes invisible, and so on. Working with all this helped explain a few mysteries to me, such as why some apps don't seem to have an Exit option.

There's obviously a lot more to Android than I've explored so far. One of the really cool features is that you can invoke parts of other apps inside your own app, so, for example, if you want to let someone browse and select a contact from your address book, you don't need to write your own code for this; you can use intents to leverage pre-existing code to do this.

"adb" is a great tool for debugging when you're working with actual hardware. You can say "adb -d shell" to start an interactive shell running on the (USB-connected) device; "adb logcat" will do something like a "tail -f " on the device's logfile, which gives you a handy way to monitor device activity from the host computer; or to grep for specific tags to pick out your own debug/status messages as your app executes.

Still a lot to learn; next task is to play with some Bluetooth behavior.


vi and cc - for a long time, those were the two tools I used for most of my programming. Maybe a linker once in a while, though I usually just let “cc” invoke it. I debugged by embedding printf() statements, and the closest I got to using a Makefile would be a script (usually named “doit” or “go”) that listed a cc command for each program to be compiled, and a final one to link together the .o files. IDES? Pffft! or so I once thought…
I did use Visual Basic back in the early 90s. That was fun! It was so different from the programming I usually did, that it didn’t feel like I was using something different from what I would normally use. It just felt like VB meant a big graphical environment where you drag and drop objects, click on them to get to their action code, and so on. I was using an IDE, but it didn’t feel wrong.
Then I pushed my luck: I decided to learn MFC, using Visual C++. The experience was horrifying! I wanted to write a simple “Hello World” program. I followed the first few steps of the tutorial, and then BAM! I had what felt like dozens of pieces of code, each requiring me to fill in certain sections, none of it having any meaning to me, and apparently having nothing directly to do with writing “Hello World” to the screen. I followed the steps in the tutorial, feeling a bit like a circus animal. In the end, the program did what it was supposed to, but I had no idea why it worked, or what I had just done. I returned a few times to repeat this exercise, but always felt like instead of programming, I was being enslaved by the IDE: tasked to do its bidding.
That was my last experience with an IDE for something like 17 years.
Last year (2011) I took one shot at developing for Android - again with a Hello World tutorial. Not as bad as my Visual C++ experience, but it didn’t leave me feeling warm and fuzzy.
I bought a TI EZ430-Chronos watch a few years ago, and around the same time I tried developing some code for that. Again, following a tutorial, not sure why I was doing all the things I was doing.
In Fall 2011, I bought some Arduino microprocessor boards. These boards required me to use an IDE, but it was completely painless: really just an editor window, a Compile button, and a Download button. It had some annoying auto-indent, but I mostly just ignored that. Somehow, that seemed to get me over a mental hurdle as far as IDEs.
A bit later, I was looking at the Android SDK, realizing that if I knew how to call these different methods, I could do some really cool programming. I think that planted the seed for really wanting to learn how to program on an Android OS.
While playing with the Arduinos, I developed an application that required a GUI on the connected PC. Here again, I had always done GUI development with pretty low-level tools. For Java, this meant using AWT. “It works, that’s good enough.” But now, the thought of creating my own widgets, writing all that even-handling code for routine events, and so on, felt overwhelming. I started looking for a better way.
I Googled, and found someone who had effectively ported Visual Basic’s look and feel to Linux. I downloaded that (feeling slightly embarrassed), and tried to install it, but it needed a lot of additional software to be installed as well. Combined with my embarrassment, I gave up quickly and kept Googling.
The 3rd or 4th time Netbeans came up, I decided to look at it more closely. I had heard the term over the years, but never knew what it meant. I assumed it was some sort of package/set of libraries/some annoying add-on. But I dug into it, and…wow! Suddenly I understood :)
Netbeans changed my life over a span of 12 hours. Suddenly, I could develop Java GUIs as easily as I had one used Visual Basic. As advertised, it let me concentrate on writing the code itself, without worrying about the display and management of the widgets. Suddenly, creating GUIs was fun again. If I wanted a text box and some push buttons to go with my code, it was easy to add them.
More significantly for me, Netbeans got me over my phobia of IDEs. Maybe it was just my mood, or maybe the time was just right, but for whatever reason, I embraced what the IDE offered, and found it not bad at all. After a few days, I began to actually enjoy certain parts of the experience.
From there, I went to Eclipse, and finally found peace working with the Android SDK. My Hello World was an application to allow me to type SMS messages on my laptop and have them sent by the phone. I didn’t feel like messing with sockets just then, so I used tag-files on the SD card to pass requests and status between the phone and host PC. Old-school, but it worked. From there, I added the ability to monitor incoming text messages and pass those to the PC for display. This was a nice mix of Eclipse for Android development and Netbeans for the PC GUI. Doing this was a blast!
  • automatic syntax/semantic checking, as soon as you make a typo etc.;
  • automatic dropdown boxes showing available methods for a just-typed object;
  • suggestions on how to correct mistakes, often with the option to auto-correct (add an “import” statement, etc.);
  • ability to re-format all code with a single command;
  • externalization of strings. Seemed goofy to me at first, but it really makes a lot of sense, and I can see taking advantage of this a number of ways;
  • “refactoring” - for example, changing the name of a variable or object and having the IDE change all references accordingly.
  • automatic syntax/semantic checking, as soon as you make a typo etc. Because while I’m typing “longvariablename” it’s flashing red and underlining and warning me that “longv” is not a defined name…”longva” is not a defined name…”longvar” is not a defined name…you get the idea. How about waiting till I stop typing, or hit a delimiter like a space or “.”
  • auto-fill-in of text. I think I’ve got this disabled, and things work great, but once in a while, I find a generated closing parenthesis at the end of a line while I’m still typing. Usually it disappears once I type my own “)” but once in a while it stays there. Similarly, sometimes the method that appears after an object is nothing like what I typed, but was a automatically filled-in suggestion that took precedence over what I typed. Sometimes these take a while to find, because I’ve learned to ignore most of the reported errors and warnings, because
  • there are a lot of reported errors and warnings. If I have a debug var I’m not using, it generates a warning. If I am using an object I haven’t yet defined, I get a bunch of warnings. It’s disconcerting. I want to know about these when I compile, not while I’m typing. The worst of all may be when you begin a definition with a “{” and the entire rest of your program is underlined/red/flagged as an error because there’s a brace mismatch now. And if you correct an error, it won’t necessarily correct errors in other files until you save your changes. Makes sense, but kind of changes programming from a nice relaxed encounter to a tense ERROR! ERROR! one.
  • automatic indenting/formatting. It’s useful after the fact, but not so much while typing. I’ve tried the options for tailoring this, but the space between too-much and too-little seems pretty wide. And in fact I enjoy indenting, I like balancing braces. It helps me keep things organized in my mind, helps me know where I am in the code and what I’m doing. When that’s removed, I tend to more-quickly lose track of where I am.
Just my initial experiences :)


My friend Murali Raju has been telling me for years about various fun hardware toys: Gumstix Linux, PIC microprocessors, etc. They sounded fun to play with, but I never felt I had the time to dig into them. More-recently, he told me about Arduino boards: stand-alone Atmel-based microprocessor boards. Clever design, inexpensive, small form factor, and with a built-in LED :) When I started teaching at Clark College in Sept 2011, one of the professors showed me a small Arduino board he had gotten. Somehow, I was hooked - I had to have one.
I ordered two actually - the Nano and the Deumilanove. They’re fun boards! Easy hookup via a USB cable, which supplies power, can be used to program the board, and can be used to transfer serial data between the board and a host processor. Programming is usually done in C. The library of built-in functions is quite rich, including easy access to I/O pins, as well as analog outputs (PWM only) and analog inputs (10-bit A-D converters).
There are plenty of examples/sample code available, and a very active community of software and hardware developers. In addition to the main boards, you can buy a number of shields: add-on boards that connect directly on top of certain boards, adding additional functions such as WiFi, LCD displays, etc. They’re not mandatory - you can use a plain old breadboard and jumpers to connect whatever peripherals you want - but the shields are handy.
My early experiments included interfacing an SD card (which turned out to work fine, but had a painfully long seek time); a two-line LCD display; a small (128x128) LCD panel; an analog input/output pair to try digitizing/re-playing music (conversion rate is pretty slow, and PWM output took some learning); and of course a number of LEDs and potentiometers. Plenty of hardware for, say, an etch-a-sketch program, a small oscilloscope, or a garbled audio recorder/playback. For no particular reason, I made a small system that stored a copy of my doctoral dissertation, and scrolled it out to a two-line LCD panel (just for fun) lol.
The most straightforward way to interact with these boards is via a simple IDE. Having been an IDE-phobe, I was initially put off but this concept, but once I tried it I realized it was unobtrusive and quite painless :)


I’m a lazy engineer dinosaur:
  • engineer because I enjoy solving problems;
  • lazy because, once I know how to solve something, I don’t generally care to re-examine it; and
  • dinosaur because much of what I know I learned a long time ago.
I started teaching engineering and computer science in 2011. The experience was energizing to me: I picked up on the students’ enthusiasm, and it grew inside myself. Within a few months, I had bought severalArduino boards; used my first IDE; used my second IDE (Netbeans); ventured into the Android SDK; dusted off my soldering iron
and built some prototype analog interfaces; and was generally having a blast playing with “modern” hardware and software. Coming from an old-school perspective (“we don’t need no stinkin’ GUI!”), I’ve had some interesting experiences, and thought others may find them useful. Hence, this page…