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.
