Tutorial 1: Transparent Panel (Linear Layout) On MapView (Google Map)
Tutorial 2: “Hit” testing on a View (MapView)

The first challenge to using Google’s Maps in Android is simply informing Eclipse that you’ll need access to Google’s mapping API.  Instead of writing my own tutorial on this, I’ll simply point you to the same well-documented Android v1.5 MapActivity setup that I followed.

The second challenge as always is getting your Map API key to function properly. Google provides full details on installing your Google Map key.  I spent several hours trying to figure out why my API key wasn’t working though…my Google maps always displayed as empty white/gray tiles.  Eventually I tracked the problem down to the fact that Android had created multiple debug.keystore files on my computer.  I’m running Vista so my .keystores were located in both of these directories:

Incorrect: C:\Users\acopernicus\AppData\Local\Android\debug.keystore
Correct: C:\users\<username>\.android\debug.keystore

I wasted time by using the .keystore in my AppData folder as this was the original place where the .keystores were stored in Android v1.0.  However it now seems that Android now uses the .android directory instead.  If you have problems, figure out which directory Eclipse is pulling your .keystore from when signing your apps.
 

At the time of initially writing the streaming tutorial, Android’s media streaming function didn’t work well so I wrote my own.  As of v1.5 however, Android’s MediaPlayer streams very well.  That said, it’s still useful to know how to retrieve a media file from a server and store it on the device.  This would be useful to immediate replay of the file at a later date or for caching files for later playback ‘off the grid’.

Download the source files to get started immediately and then view the rest of the tutorial after the jump.

You may want to look at my old Android v1.0 streaming tutorial for additional details. I don’t want to rewrite that post completely so I’ll mostly focus here on the changes required for Android v1.5. That said, there is very little difference between my old tutorial and this new one.

The most important change is that MediaPlayer.setDataSource() now takes a FileDescriptor instead of a String path to the media File. It seems the reason to use FileDescriptors is for security/permission reasons. In either case though, passing a String path to our media File resulted in errors such as “PVMFErrNotSupported” and “Prepare failed.: status=0×1″. So until I learn otherwise, I recommend using FileDescriptor for the MediaPlayer.


FileInputStream fis = new FileInputStream(mediaFile);
mPlayer.setDataSource(fis.getFD());


The only other change is I can no longer find any File move functionality it Android so I wrote my own. It does exactly what it says, it moves data in one File to a new File location. This is used while streaming the media file so we can double buffer it. The double buffering allows us to simulaneously download to one File while playing from another File. We sync the downloaded data between the Files as more data is downloaded:

public void moveFile(File oldLocation, File newLocation) throws IOException

Download the source files for all the tutorials. The streaming media tutorial available by clicking button #3. Don’t forget to look at my old Android v1.0 streaming tutorial for additional details.

As soon as Google releases the next SDK, we’ll write up more tutorials based on the lessons we’ve learned over the past months.

Until then, we’re getting out to exercise and enjoy some sunshine away from our desks.

Cheers,

Anthony (Biosopher)

Second-gen iPhone: 3G, GPS, only slightly thicker

This is great news for mobile map-based application developers but don’t count on the API being as slick and open as Android’s. Given Apple’s approach so far, they’ll still withhold the vital functionality to get your app really humming.

Why do I say that?

Well for example, Apple’s SDK doesn’t allow applications to run in the background. That means death to any Pocket Journey app that would run on an iPhone as the audio/video would be killed along with your application as soon as someone called. Apple says this is for security reasons, but we know it’s due to Apple’s “control freakish” corporate nature. Happily for us, Android solved this challenge through their Service API.

Seems like Apple wants to step back to the dark ages of the Palm OS which can only handle single-threaded tasks as well

You’ll be shown screen shots in the video or you can view close ups on our main website

We’ve tried to capture what we view as the power of community and the interest we’ve heard around packaging high quality knowledge from a range of people and making it available through mobile phones.

As you can imagine, there will be a broad range of topics provided through Pocket Journey so it will be a major challenge to filter, pacakge, & deliver just the information you want.

Yes…this GREATLY simplifies the challenge but we wanted to give you a very very “rough” idea of where we’re headed. We plan to provide more details as the project matures.

But don’t just take these static images as the real message. Check out the Pocket Journey video to get a much clearer understanding and to actually “hear” what it’s all about. It will only take 4 minutes of your time.