First, http://m.youtube.com is worth staying away from if you have a smartphone on a 3G network, Wifi, or even better, Wimax. It works, but only delivers QCIF (176 x 144) video at ridiculous low data rates (tops out around 80 kbps). What's worse, is someone has been writing custom youtube apps to play this bad video at double the size. This makes blocky video look even worse. Nice move. Maybe the newly announce youtube premium music video site will get it right (but only if they read on...)

Now some youtube apps on smartphones have a 'high quality' mode. I tried that over Wifi on an HTC device and found the quality was worse than the dumbed-down mode described above. How can that be? Someone seems to have forgot that downloading video uses the CPU. In short, trying to playback video while downloading it (which is exactly how youtube and any progressive video site work) causes such trauma to the CPU that the video is jerky, drops lots of frames, and the audio completely loses sync. Any basic testing should have caught this, so shame on you for failing to test properly.

I had a hunch about the cause of the problem, so I started a video in high quality mode, hit pause, and waited for it to complete downloading to the phone. Then I played it back and it was beautiful. Perfect, smooth, full-screen video with audio in-sync. So why doesn't the app warn people about this problem and suggest downloading the video first for optimal playback? How hard is it to read the CPU usage? Why don't these players cache the video?

This is just another example that many developers are just plain bad at developing for mobile devices and definitely not ready to handle 4G devices. People seem to have forgotten about device constraints. Or worse, they fully embrace them and put out video chat clients that use 70kbps up and down for video for that rich, 3 frame per second experience with bad audio you are dying for. Yes, these nightmare products exist and are completely unusable.

The moral of the story is that 4G is coming and you better be prepared to handle a new breed of device if you want to suceed. Location based services, context aware applications, apps that know your wireless radio conditions and how to adjust themselves properly (all topics I write about)- these are the new tools required in the holistic programmers toolkit.

You will also find that video, even when downloaded, is not cached. That is up to you.

I have played mp3 music files by including them as a 'raw' resource as part of my android test application. I have not been able to play video this way, though.

Here's the basic java code to run (just change the url to your video):

        setContentView(R.layout.videoview);
        controller = new MediaController(this);
        viewer = (VideoView)findViewById(R.id.layout_viewer);
        viewer.setMediaController(controller);
        viewer.requestFocus();
       

Call this code from a separate method activated by a button or menu (why? It won't play when all in the same method).       

        viewer.setVideoURI(Uri.parse("http://172.20.18.78:8080/venus-h264.mp4"));
        viewer.start();

Here's a layout element:

<VideoView android:id="@+id/layout_viewer"
        android:layout_width="fill_parent"
    android:layout_height="fill_parent"    />

Now how do you fix this problem? Simple. The camera eye should hang down on to the front of your laptop screen. It's OK to cover part of the screen, since you are only looking at a relatively small video chat window. The goal is to get the camera eye as close as possible to the eyes of who you are talking to and this design achieves that. This way you can make eye contact properly and not look as if your eyes are half-closed or you are just looking down all the time. Trust me, eye contact is much better. Anyone see a camera that works this way? let me know.

valid POST request to the above provider URL (these are the mandatory request parameters)
{"version": "1.0.1","host": "maps.google.com"}

valid response from provider
{"location":{"latitude":38.95937,"longitude":-77.35455,"horizontal_accuracy":43 000.0}}

News Flash-
Since I posted this, Google changed the API (but didn't update their documents- shame on you!). 'accuracy' is now a required field, although it doesn't appear to be used at all based on my testing. horizontal_accuracy and vertical_accuracy fields no longer exist. How do you know what Gears is doing and what it really expects? The best test is to use Wireshark (formerly Ethereal- http://www.wireshark.org/ ) and look at the actual JSON response from the google default provider. You can also see what Gears is sending to the google default provider. Stick with what they are doing, if not what the docs always say and you will save yourself some frustration.


For more details on the API, see http://code.google.com/apis/gears/api_geolocation.html


What I find most interesting is that you can create your own location provider. Your provider could use GPS, Wimax location services, or a combination of providers. You just have to follow the API for providers located at http://code.google.com/p/gears/wiki/GeolocationAPI

Here's the full example code for how to use your own provider, except for the provider itself. You can just dummy that up with a web page, though. This is taken from http://code.google.com/apis/gears/api_geolocation.html and modified to show how to use a different provider(s). And yes, you really can create a provider that runs at localhost and Gears can talk to it and hand off the location information to the web browser. Try that with AJAX (don't bother- it won't work)!

enclose this code in script tags and call the init() function when the page loads. You must also have a tag to load the gears_init.js file from google.

var geo = google.gears.factory.create('beta.geolocation');

function updatePosition(p) {
alert('Current lat/lon is: ' + p.latitude + ',' + p.longitude );
}

function handleError(positionError) {
alert('Attempt to get location failed: ' + positionError.message);
}

function init()
{
//since this is an array, multiple providers can be used. Gears returns the most accurate location results.
//for example, you could have: var providers = ["http://localhost:8080/json.jsp", "http://www.google.com/loc/json", "http://localhost/mygpsinterface"];

var providers = ["http://localhost:8080/json.jsp"];
var options = ;
geo.getCurrentPosition(updatePosition, handleError, options);
}

That's only $2/year more than any schmuck pays who just gets the blow in from the current issue.  Are your marketeers that stupid? No, they just don't care, they know you will keep reading, and they are clever enough to know the value of lies and flattery (sounds like any sales person). They know most people won't pay any attention so they are fair game to be screwed out of a few bucks. That adds up over the whole subscriber base. Bravo!

Now on to some services ideas.

You know those emergency radios with the hand crank for power, the light, siren, AM/FM/TV tuner? The TV tuner is analog so you can kiss that goodbye in Feb 2009 when TV goes digital. Every TV tuning radio for the US market must be redesigned with a digital TV tuner- so don't buy the wrong model at a cheap sale this year! During Hurricane Katrina, local radio was shutdown since people evacuated and had no power anyway. Wouldn't a satellite radio with emergency power be great? The radio stays on, the big TV news stations stay on. People could get news and comforting distraction. The satellite providers have already proved that they can turn on a dime and change programming (they created Client 9 Radio in a day). This should be something the FCC wants as a merger pre-condition. A platform for a useful public service, not just more lobbying dollars spent on the FCC as they drag it out. Just take an XM boom box and add a power crank to it- voila!

More video services. Sirius has 3 channels (cartoons, since low data rate works well with them- QVGA, 250kbps, 15fps is all you need to keep kids happy. QVGA looks fine blown up on a high pixel-density 7" screen). With the merger, the extra bandwidth from elimination of redundant channels will enable many more video channels. More than they need, frankly. Hopefully they built the video player to be able to handle more than 3 channels out of the box (I'm sure they did) when more become available.

Data file broadcast service. This is where it gets interesting. Satellite broadcast can deliver music, video, or any type of data, in either real or non-real time. Imagine a satellite radio that not only could store music (like the Pioneer Inno), but that could download a city guide and have it all cached. Maps, events schedules, digital coupons, city business phone book, etc. The major metros could each have a channel on the merged entity, and the file broadcast would keep it up to date through differential data downloads. Public service plus web-like information. I don't think you can program the Inno like a VCR, but that would be a nice add, too. There are many great shows on XM that my commute schedule just does not mesh with.

The data broadcast service could also broadcast audio/music and video non-real time (such as overnight) so that you have it available for playback the next day. Like PODCasts, but only mass-market since you are broadcast to many. This would take a fraction of the bandwidth of a regular channel, allowing for multiple low-bit rate services. How about an audio book channel?

Would it be possible for Sirius XM to provide some special data services for the government? The answer is yes. Amber alerts for satellite radio plus other formats, like the CAP alert (see http://www.incident.com/cookbook/index.php/CAP_Fact_Sheet ). I'm familiar with these since I wrote the software to parse the CAP alerts coming over UHF into text messages that I relayed over SMS to Nextel cell phones. Converting it to a feed for satellite that is 'read' using text-to-speech is simple.

I see great things for satellite radio. Even slumping cars sales could be spun right (listen up, Sirius XM marketing department). If you can't buy a new car, just upgrade your old one- Duh! For less than the monthly payment on the average new car, you could have a satellite receiver, new speakers, and about a year's worth of service. That's a bargain.

http://pipes.yahoo.com/erich/wildfires

If you have a good RSS news source, let me know. 

I love Adobe AIR and am writing a desktop application using AIR that works with Facebook. One of the challenges of working with Facebook is authenticating your requests to their REST server. Below is some actionscript code that produces an MD5 hash of a Facebook API request. 

Here is the algorithm to be implemented:
 args = array of args to the request, not counting sig, formatted in non-urlencoded arg=val pairs (these are CGI parameters)
 sorted_array = alphabetically_sort_array_by_keys(args);
 request_str = concatenate_in_order(sorted_array);
 signature = md5(concatenate(request_str, secret))

Note that secret is not the Facebook application secret, but the session secret Facebook returns after proper authentication of the user!! There is an actionscript MD5 library (com.gsolo.encryption.MD5) from http://gsolofp.blogspot.com/2006/01/actionscript-3-md5-and-sha1.html that I use. Works great.

public static function signRequest(params:Object, secret:String):String
{
   
var hashInput:String = "";
    
//get the keys from the params associative array and add them to a new array
var keys:Array = new Array();
var index:int;

for (var item:String in params)
{
keys[index++] = item;
}
    
//sort the keys
var sorter:Sort = new Sort();
sorter.sort(keys);
 
for (var i:int; i < keys.length; i++)
{
//iterate the sorted keys and concatenate into one big string
trace(keys[i] + "=" + params[keys[i]]);
hashInput += keys[i] + "=" + params[keys[i]];
}

hashInput += secret;

return MD5.encrypt(hashInput);
}

This is not the hard part of signing a request. The bigger challenge is knowing exactly what parameters need to be sent, and that if you are using some special class or library, knowing what it might be sendiing, as well. The Facebook error messages help, but they are undocumented. That's where this blog comes in.

Below is an error response to trying to do a photo upload to Facebook using the built-in upload() method of the File class in AIR. (I did change a few values in it so the signature won't compute.)

Details:
<error_response xsi:schemaLocation="http://api.facebook.com/1.0/ http://api.facebook.com/1.0/facebook.xsd" xmlns="http://api.facebook.com/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <error_code>104</error_code>
  <error_msg>Incorrect signature</error_msg>
  <request_args list="true">
    <arg>
      <key>Filename</key>
      <value>kids.jpg</value>
    </arg>
    <arg>
      <key>call_id</key>
      <value>1215090174125</value>
    </arg>
    <arg>
      <key>method</key>
      <value>facebook.photos.upload</value>
    </arg>
    <arg>
      <key>api_key</key>
      <value>281b9cd2f09c077b2bb100707de</value>
    </arg>
    <arg>
      <key>session_key</key>
      <value>f6bec46c8aa0647b3f377b4440679</value>
    </arg>
    <arg>
      <key>v</key>
      <value>1.0</value>
    </arg>
    <arg>
      <key>sig</key>
      <value>6949810fb9aff86b103520760ff8</value>
    </arg>
    <arg>
      <key>Upload</key>
      <value>Submit Query</value>
    </arg>
  </request_args>
</error_response>

What's significant about this message is that it actually is telling you everything that Facebook is using to compute the signature for the request it received. The keys and values are what it recevied from your computer. Put them into the method above (except for sig, of course), and you get the signature that Facebook computed when it attempted to authenticate your request. This looks straight forward, except that the Filename and Upload arguments are not provided directly by you- they are actually being put into the request by File.upload(). Nor are they mentioned as being required parts of the request in the Facebook API, and in fact, neither Filename nor Upload are used by Facebook. But since they are sent, they are part of the request that Facebook uses to compute the signature and if the signature you send does not match theirs, your request fails.

The moral of the story is you need to know what you are really sending when doing any type of hash of CGI parameters. this affects Facebook, Amazon, and others.

Information should be pushed to me…automatically

The widget should let me get more…and help me discover

The same widget must run on many devices…so I always have it

My widgets need to share…with each other

Widgets should enable custom devices…and will as technology advances

Widgets should enlighten, assist, entertain…and be a joy to use

We can't send aid and people will die every day. The military government does not care. Why? Probably some dissidents are dying, certainly poor peasants. These are pople worth nothing to the junta and losing them might even make their job easier. Aid will flow in, eventually, and lots of it will not go where it is supposed to. The junta will rejoice, make some extra cash selling aid products on the black market, and the next cyclone will be no different.

How does the junta survive since 1962? Selling natural resources to China, getting military aid from China allowing their army to grow, and selling heroin. They also get weapons from North Korea and India. China's actions are disgusting and their support of the 'governments' of Myanmar and Sudan (aloing with the suppression of Tibet) are criminal. Imagine how things would be different without Chinese intervention. But the peasants know nothing of this. I wonder, is it easier to die hoping for help but knowing none will come, or hoping for help knowing it might come?

More information on just how sad Myanmar is: http://fas.org/sgp/crs/row/RL33479.pdf

By the way, the official name of the junta is the "State Peace and Development Council." This situation is just another example of evil being called good and good being called evil.

Here's a challenge for you: apply context to your applications. What's that, you say? I'll tell you.

Let's start with something hot: Location. It is a lot more complicated than you might think. The parameters of interest that I see are:

Latitude and longitude
Speed
Heading
Route
Zip code
Metro Area
Country

Here are some examples to help you see why these are useful. First of all, not everyone using your service is sitting at a desk. Think wimax. Think more users in more places means more money.

Lat and long are the low hanging fruit, but the user really does not want to see them, they just want them used behind the scenes. You can plug them into google maps through the javascript API and make mapping apps know where you are when they first start up. That's handy.

Speed- hmm. I could use this to infer if you are in a car or on a train or walking or sitting still. These differences could be important to your service. For example, if you are driving, maybe you want to find gas or a place with a drive-through.

Heading. Which way are you going? Are you driving home or going to the office? Perhaps you have a to-do (or ta-da!) list that changes based on where you are driving to. I doubt you are going to go by groceries on the way to the office.

Route. What I mean by this is where have you been lately? Are you out of town- let's get you some traveler's info. Are you driving in circles- maybe you are lost. What road are you following and what is on that road that could be of interest.

Zip code is the old standby and I hope to never enter it again. Due to current limitations of how location is usually determined, zip code is the dominant player and is used in nearly ever location-related service on the web, so no example is needed.

Metro Area is a good one. Craigslist makes you pick this. Other metro area services are TV and radio stations/programming, weather, airport info, etc.

Country is used by many international sites and also has other uses (then getting the language right). It can matter because some activities may be legal in one country (or state, for that matter) and not in another. Your service may simply not be allowed to work in some places. I recall Pandora could not be used in Britain, though this was unenforceable. Now we will see.

So there you have it. Context matters. If you want your apps used from other than behind a desk you should start using it. Otherwise, your apps may just not fit with what the user is doing and also will fail to get as much use as possible.

I will be covering several more areas of context and how to use it over the coming weeks.

1.	a small mechanical device, as a knob or switch, esp. one whose name is not known or cannot be recalled; gadget: a row of widgets on the instrument panel.

2.	something considered typical or representative, as of a manufacturer's products: the widgets coming off the assembly line.

Then in the 80's  is about when you had widget kits for software development. they were screen elements, but still like definition 1 above- part of the instrument panel. Today, we still have widgets in that sense, but now a new concept: the little software utility application.

I love them and the tools (Adobe AIR and Flex) for building them. This is like java in 1996. but enough history. On with the real topic.

I believe widgets are going to move off your computer screen and back into being a small mechanical (or rather electro-mechanical) device. Some already have. I count bluetooth earpieces in this category of widget. Those little widgets in Nike shoes. Dive computers. I think we will have many more, without gong to sci-fi, and they will be cheap and connected to the internet (IP V6 no doubt) or at least your wireless internet relay widget (from XOHM) that all your devices share.

Email direct from your brain. A weather widget on your wrist watch. William Gibson's microsoft. A flickr slide show on your sunglasses. Flexible, electronic ink screen on your forearm (or sub-cutaneous- even better!). A zippo-lighter sized movie projector.

Who needs a desktop. I want widgets the way the used to be.