You may have seen my prior post on this topic: Streaming Media with Android.  The title is slightly innacurate as it’s less about generic ‘media’ streaming and instead focused on .mp3 audio.  The basic streaming function described in the post is still valid for Android however that post was written when Android was still v1.0.  Android’s media handling has improved substantially since then but is still unstable with respect to many media formats.  In my experience, it’s best to stick to .mp3 for audio and .3gp for video.  The best tool I’ve found for generating .3gp video is Quicktime Pro.  Yes…oddly Apple makes the easiest tool for generating video for Android.

Scroll to the bottom to see a few tutorials I’ve found on Live Streaming with Android.

Streaming Media…As In Live Radio

My prior streaming media post has recieved many questions about streaming live audio/video.  That type of streaming is completely different from what I previously discussed, but since there’s so much interest, I though I would write a brief post that I can refer people to.  To start, here’s the list of Android’s supported media formats.  As you can see, Android now supports streaming of these live media formats:

• RTSP (RTP, SDP)
• HTTP/HTTPS progressive streaming
• HTTP/HTTPS live streaming draft protocol:
  • MPEG-2 TS media files only
  • Protocol version 3 (Android 4.0 and above)
  • Protocol version 2 (Android 3.x)
  • Not supported before Android 3.0
  • Note: HTTPS is not supported before Android 3.1.

Progressive versus Live Streaming

This distinction is important and may or may not be under your control.  If you are streaming your own media, then research the strengths and weaknesses of these two options to determine what’s right for you.  If your app will play somebody elses content, then you’ll need to determine which format they are using.  In general though, if the media to stream is self-contained in a file, then progressive streaming is the easiest solution.  If the media is of indeterminate length because it’s being generated or created live (e.g. radio or live video blog), then you’ll need ‘live’ streaming.

Progressive Streaming

File delivery via HTTP is referred to as ‘progressive or http streaming’.  This isn’t really file streaming as much as complete download of a media file to the user’s computer but with playback initiated as soon as sufficient content has been downloaded. The media file is buffered onto the user’s computer so it can be viewed/listened to. In technical terms, the initially downloaded file bytes must contain a header describing the media file format, encoding quality (e.g. 128 kbps) and such.  The server doesn’t care about the file’s content though, it simply sends data to the app as fast as it can.  Because the file is downloaded from in its entirety, the ability to skipping to parts of the file that have not yet been downloaded is not possible…the user must wait for the server to stream all the prior content before playing the selected section.

Code: Progressing Streaming

Go here for the code from my progressive streaming post.

Live Streaming

Live streaming requires the overhead of a streaming server – special software that handles the media requests.  This is different from progressive streaming in which a standard web server can simply deliver a media file via HTTP.  Live streaming requires a more intelligent conversation between the streaming server and the local app performing media playback.  The user’s app must provide ‘control handling’ between itself and the server. These control messages include ‘play’, ‘pause’, and ‘seek’ but also details about the quality of the media to be delivered.  E.g. if the app is on a slower network, then it should request lower quality (i.e. kbps) media and if the device has a smaller screen, it would request video for that size to reduce unnecessary bandwidth usage.

The advantages of Live Streaming are the ability to begin playback at any point, skip through the media, more efficiently use bandwidth, and to avoid storing media file on the device (the data is played and discarded immediatley – e.g. the difference between Apple’s 1st and 2nd generation Apple TV).

When selecting your streaming servers, you’ll need to determine  the appropriate streaming protocols: RTSP(Real time streaming protocol), RTMP(Real time messaging protocol) and MMS (Microsoft media services). These streaming protocols deliver video well by being more focussed on continuous delivery than 100% accuracy. The assumption is that it’s better to have a momentary glitch rather than stopping media playback altogether.

Code & Tutorials: Live Streaming

CatDaaaady repurposed my progressive streaming code and wrote code to listen to NPR’s streaming broadcast.  In his words, “I used Biosopher’s code and modified it to support a continuous stream of audio instead of a file. It downloads X number of seconds and save that audio segment. Then it starts playing that audio clip while it downloads the next sections of audio in the background. Then queuing up the audio segments for playing next. It is not perfect though.  I get a slight playback pause between audio segments though. Hopefully I will prefect it or find another way around.”

http://justdevelopment.blogspot.com/2009/10/video-streaming-with-android-phone.html

http://stackoverflow.com/questions/3595491/is-android-2-2-http-progressive-streaming-http-live-streaming

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 this directory:

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.

After spending the last year game programming on the iPhone, I’ve finally returned to Android.  My six prior tutorials were outdated (Android v1.0) so I took the time to update them to v1.5 (Cupcake).  The most popular of those tutorials was the Streaming MediaPlayer tutorial so that’s the primary focus of this post.

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)

Demo video here

I thought I already knew everything about Android’s app lifecycle, but this visual refresher and sample application were a great refresher. Understanding the application lifecycle is crucial to writing good Android apps so this video shoud be useful to pros and newbies alike.

Sleepy Droid says they’ll be creating more videos if the response is positive so visit Sleepy Droid to see if new videos have been posted.

Thanks Sleepy Droid!

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

Luckily I was pointed to the solution myself by an experienced Android programmer in Guatemala by the username of cadlg (thanks again!). If you want to see the official Google Android example though, look at Android’s APIDemos’ custom LabelView example.

So here we go. We’ll use the same code as Tutorial 4.1 to keep this simple.

Setting Up Your Custom Class’s XML Resource Files

We’ll only review the code for the TextOnlyButton as it’s identical in concept to the ImageOnlyButton.

First we’ll create a new file in /res/values called attrs.xml

<?xml version=”1.0″ encoding=”utf-8″?>
<resources>

<declare-styleable name=”TextOnlyButton”>

<attr name=”textColorNotFocused” format=”integer”/>
<attr name=”textColorFocused” format=”integer”/>

</declare-styleable>

</resources>

As you see, we first declared a ‘styleable’ with the name of our custom Class. Two attributes were then added to contain the values of our focused & unfocused text colors. By default, attributes have values of String, but in our case, we needed integers to represent the resource id’s we’ll declare in our colors.xml file. You can also declare formats such as “boolean” & others if that suits the requirements of your own project.

Next, we declare values for these custom attributes in our layout’s XML file: tutorial4.xml

<LinearLayout xmlns:android=”http://schemas.android.com/apk/res/android”

xmlns:pj= “http://schemas.android.com/apk/res/com.pocketjourney.tutorials”
android:orientation=”vertical”
android:layout_width=”fill_parent”
android:layout_height=”fill_parent”
android:padding=”10px”>

<com.pocketjourney.view.TextOnlyButton

android:id=”@+id/text_only_button”
android:layout_width=”wrap_content”
android:layout_height=”wrap_content”
android:layout_marginTop=”5px”
style=”?android:attr/buttonStyleSmall”
android:text=”Text Button”
pj:textColorNotFocused=”@drawable/white”
pj:textColorFocused=”@drawable/android_orange”/>

</LinearLayout>

Referring to our new attributes is actually a two step process. First we declared a new namespace (in our case called ‘pj’ as short for PocketJourney) in the parent layout of our custom class:

xmlns:pj= “http://schemas.android.com/apk/res/com.pocketjourney.tutorials”

Next we specified the values of our new attributes in the XML usage of our TextOnlyButton:

pj:textColorNotFocused=”@drawable/white”
pj:textColorFocused=”@drawable/android_orange”

Now you can see why we specified our format=”integer”. Our custom attributes point to the resource id’s of colors specified in our colors.xml file.

Retrieving Custom Attributes During Class Instantiation

Since our Activity has many constructors, we delegate the attribute parsing to an init() method to keep our code clean.

int notFocusedTextColor, focusedTextColor;

private void init(AttributeSet attrs) {

Resources.StyledAttributes a = getContext().obtainStyledAttributes(attrs,R.styleable.TextOnlyButton);
notFocusedTextColor = a.getColor(R.styleable.TextOnlyButton_textColorNotFocused, 0xFF000000);
focusedTextColor = a.getColor(R.styleable.TextOnlyButton_textColorFocused, 0xFF000000);

}

By now you’ve undoubtedly seen the AttributeSet that is always passed into an Activity. Well now you get to use it. First we obtain the StyledAttributes instance by requesting just the StyledAttributes for our custom Class. Next, we call the getColor() and pass two variables: the name of the attribute we want along with a default value in case the user did not specify one.

Take note of our styled attribute’s name as it’s a combination of our custom class’s name and the attribute we specified in the attrs.xml file (e.g. TextOnlyButton_textColorNotFocused).

And That’s It

You can now readily pass your own custom attributes and keep your View variables cleanly enclosed in your XML files. You can download the source to see for yourself. Just look at Tutorial #4.

Prior Tutorials

Tutorial 1: Transparent Panel (Linear Layout) On MapView (Google Map)
Tutorial 2: “Hit” testing on a View (MapView)
Tutorial 3: Custom Media Streaming with MediaPlayer
Tutorial 4.1: Image and Text-Only Buttons

We will create these two new Button extensions as shown:

Step 1: Set Background to ‘null’ in XML or code

The recommended technique is to use the ‘empty’ drawable variable in your ImageButton or TextButton’s XML to set your background to null:

android:background=”@android:drawable/empty”

An optional technique is to extend ImageButton or TextButton and to set the background to null in the constuctor. As above, this is not the recommended approach but may be useful at times:

public YourButtonExtension() {

setBackground(null);

}

And that’s it, only your image or text will display but will have button functionality…except for visually displaying focus. Let’s address that next.

Step 2: Handle onFocus() by overriding onDraw()

We listen for the focus event and update the Button’s text color or button image that way as well. But we’ll do it this way for now.

public void onDraw(Canvas canvas) {

// Since this Button now has no background. We must set the text color to indicate focus.
if (isFocused()) {

// Set the focused text color. In the case of ImageOnlyButton we would .
// instead do setImageResource(imageResourceFocused);
setTextColor(focusedTextColor);

} else {

// Set the non-focused text color. In the case of ImageOnlyButton we would .
// instead do setImageResource(imageResourceNotFocused);
setTextColor(notFocusedTextColor);

}

super.onDraw(canvas);

}

You might be wondering where those text color and image variables come from. We will obtain these focused & not-focused images or text colors from variables passed in from the XML resource file as you’ll see by reading the source code. I won’t go into how that happens here. Instead, I’ll keep this tutorial simple and point you to my next tutorial where I will discuss how to create & pass such custom variables.

And That’s It

You can download the source to see for yourself.

Prior Tutorials

Tutorial 1: Transparent Panel (Linear Layout) On MapView (Google Map)
Tutorial 2: “Hit” testing on a View (MapView)
Tutorial 3: Custom Media Streaming with MediaPlayer

Yes…you read this post’s title correctly. The iPhone SDK lacks the basic mapping API required by applications developers hoping to tie the mobile experience to a geo-specific location (GPS). The only GPS mapping function provided by the iPhone SDK is to send a URL to the iPhone’s built-in Google map application and to let Google handle the rest.

Curiously the iPhone SDK does provide a basic location service API providing the user’s location using cell signal triangulation, but without a map, this information is all-but-useless.

At first glance you might say, “that makes sense as the iPhone doesn’t have GPS built-in because it would have raised the price of an already expensive phone.”

Point taken but all this leaves me to believe that Apple’s take on the iPhone is too media focused and lacks clear understanding of the power provided by location-awareness. That’s great news for the upcoming GPS-enabled Android phones. They’ll have time to widely proliferate before the soon-to-be almost 10M iPhones out there will be replaced with GPS-enabled iPhones.

Imagine if Android had lacked the MapActivity API…?!? From my count, 90% of the most interesting Android Challenge entries would never exist. Without Android’s MapActivity API, we would be left with a few accelerometer-based games and non-SMS messaging apps.

This is great news for Google and perhaps that’s the point. Google wrote the iPhone’s map application and was either not given incentive to make expose its iPhone map through an API or perhaps decided it was smart to keep the iPhone limited in this crucial manner. OK…maybe Apple has a bigger plan as it always does. Maybe Apple is preparing to launch its own mapping application or perhaps AT&T didn’t want Apple to expose such location-based apps because AT&T has its own GPS agenda.

Thoughts anyone?

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.