I wanted to build a music player for Android, but before I could start I realized that I had no idea where the music files were stored on the device, let alone how to actually grab them.
So I took a step back and made something simpler: an Android documents browser.
It works as you'd expect - it's a list based directory. Click on each item to navigate down through directories until you get to a file. Click on the file to view basic File info. To navigate back, use the Back button on your device or Cmd-B (OSX) to go back.
A few discoveries in doing the project:
Can't access the SD card while in USB debugging mode. My Droid USB connection needed to be set to "USB Mass Storage" to transfer files and debug, but that also turned off access to the SD card from the app. This means I couldn't debug and view my device's documents at the same time. It was also a little confusing at first to detect if my app worked or not because it took several seconds to switch back to SD card access. Basically, I had to unplug the USB cable, wait for the SD card to reload (which has two short phases: preparing SD card and "sd card w/ gear icon in top menu" phase), and then hit the app's refresh button to see anything.
Views don't retain data, so moving from one view to another in the stack I needed a way to remember my paths. I solved this by passing a Paths array to each view after pushing the next directory's name into the array . For the return trip, I popped the last directory name and used the createReturnObject override to pass the updated Array back down the stack.
Reusing FileSystemList. Initially I just refreshed the same view with update paths, but there was no fancy iPhone-like visual transition between the lists. The solution was to create a new FileSystemList view for each step through the directory.
Back button will automatically call popView(). This is fundamentally different from the createReturnObject example mentioned before. Calling navigator.popView() myself caused the viewStack to drop two views.
The Flex Builder emulator behaves differently than my device. Speaking of the Back button... the keycode was different in the emulator. On your device the keycode is Keyboard.BACK, but in the emulator, Cmd-B's keycode is 16777238 (for OSX). Also, my Music folders are in different locations. On my Mac it's in File.userDirectory, while on my device it's in File.documentsDirectory.
Android files don't have icons. In the emulator, the app will show the file's icon in FileView since desktop files have icons. But in the Android device, this is skipped and just the info is shown.
I took a few liberties in throwing this together. Nothing is optimized, there's no fancy MVC structure. It's a quick and dirty test aka "It works on my machine."
If you're curious, I've also completed a rough music app. It's built like this one which means all sorts of problems. First - Sound is played within PlayerView (i.e. FileView). The problem occurs if Sound is playing and I click Back: the view is destroyed but the music is still going strong. Worse, since the view is gone, there's no interface to turn it off - a new view makes a new Sound.
I'll need to build the next music app differently. I'm looking into RobotLegs for an uncoupled framework to separate the (self-destructive) views from core functionality. Also, I'm looking into crucial shut-down and clean-up solutions to make sure it's easy to stop the app. Finally, I'm curious about bridging between the AIR-based music player and Android's native mediaPlayer. This last one is pretty important: as far as I know Flash's Sound() player can't respond to important things like phone calls and other music players. I'll dig a lot deeper to know for sure.