jeffaBlog

The Windows Portable Devices API is to talking to media devices what DirectX is to gaming. It is an attempt to make a secure, standard method of communicating with devices ranging from Media Players to cameras to temperature sensors...

There are things I like about it and things I really, really don't like. For an MP3 player manufacturer one big reason to use this API instead of making the device work like a USB drive is DRM.

But, it looks at this point like DRM (Digital Rights Management) for music files is a dying beast. The recording industry seems to be accepting the fact that their customers HATE DRM. There are now several ways to LEGALLY purchase songs in unencumbered MP3 format. Arguably the only people inconvenienced by DRM were the legal users. The pirates never had a problem circumventing the so called protection.

What does this mean to you (and me)? Well, when I work with my son's Transcend player (which could never play DRM music), it looks just like a USB drive. Easy, peasy. When I work with my Creative Zen or my daughter's Creative Zen V, I have to use the Windows Portable Devices API.

The lack of a .Net version of the API is a bummer, but not insurmountable. You get to take a fun and exciting trip through the world of ILDASM and ILASM, then you get to read the C++ examples and do a bit of mental gymnastics, but you can get there.

So far I have gotten as far as enumerating the connected devices, getting their friendly names, descriptions and manufacturer info. Next I'll be diving into how to get the file info and move files around. Not as straightforward as working with the file system, but always remember, "No matter where you go, there you are."

Here are some links that are helpful with working with the Windows Portable Devices API.

API documentation in MSDN

http://msdn.microsoft.com/en-us/library/ms740786(VS.85).aspx

Windows Portable Device Team Blog

http://blogs.msdn.com/wpdblog/

The team put up an example of using the API to talk to a temperature sensor using c#:

http://blogs.msdn.com/wpdblog/archive/2007/11/26/creating-a-temperature-sensor-gadget-for-windows-sidebar.aspx

Darene Lewis' Blog

http://blogs.msdn.com/dimeby8/default.aspx

I'm not really sure exactly who Drene is, but I'm guessing Microsoft Employee based on the blog address...

In any event there is much good info here regarding the Windows Portable Device API and how to use it with .Net.

Just wanted to post a quick update on my progress.

At this point I have the following working, or mostly working:

1. Subscribe to a podcast
2. Download the episodes to the hard drive
3. Add devices, specifying their root directory for podcasts
4. Walk the directories under the root and show a list of all files and their paths
5. Persist library and device data to the hard drive using JSON serialization
6. Query objects using Linq to Objects

Here's what's NOT finished:

1. Synchronize podcasts to the device
2. Connect to a device that doesn't appear as a drive

That last one is a big sticking point right now. I have two devices from Creative and one from Transcend. The Transcend shows up as a drive. That's nice. The Creative devices show up as Windows Media Devices. That's not nice.

To communicate with such devices (mp3 players, cameras, etc.) you have to use the Windows Media Device Manager APIs. Unfortunately they are NOT implemented in .Net. That means you got some pInvoking to do.

This is the bit I'm working on now. I've never worked with this particular API before (I didn't know there was such a thing before yesterday...), so it may take a bit of fiddling to get moving forward again.

It is a pain in the posterior, but once I get a handle on the API, I'll be back in business.

In the meantime here's a screenshot of the UI. Not pretty, but not entirely WinForms like. Not all super-de-duper WPFy, but functional.

Eventually I'll try to make it look a bit more like that famous fruit inspired music site...

Windows Presentation Foundation (WPF) offers Windows developers a new style of development.

Instead of firing up Visual Studio and putting together a standard Windows Forms UI, you can split the development between a designer (or team of designers) using Expression Blend and a programmer (or team of programmers) using Visual Studio.

The design team can use a tool that is familiar to them to design the UI and the programming team can use a tool that is familiar to them. Their common currency is XAML. XAML (Extensible Application Markup Language) is an XML file that describes how the screen should look.

Here's a screenshot from Expression Blend:

Wow. That sure isn't Visual Studio.

Timelines? Storyboards? Animations? Oh, my!

So should I use WPF or not?

Here's my decision process:

1) Is this a consumer app or an internal business app?

In other words, will people pick my app because it looks good or will they use it no matter how it looks because it can help them make money (or they are mandated to use it by the people who hope to make money)?

If I begin a consumer oriented app that will live on the desktop, I will pick WPF and Expression Blend without a doubt. You simply cannot make a Windows Forms app looks as good as you can a WPF app.

If I am making an app that ISN'T a consumer app, then I have to ask another question.

2) Do I want to use tried and true Windows Forms or prepare for the future with WPF?

So I'm working on an internal app that will be used by people within my company whether they like it or not. Should it be WPF? That is a tough question. It is possible to make an app with WPF that looks remarkably like a Windows Forms app. Problem is that many of the standard controls available to a Windows Forms app are not available to WPF.

The not so simple answer is that if I use WPF it will be possible to redo the UI at a later date with lots of spiffy new shiny pieces, BUT it will take me longer to produce than a Windows Forms app. If I use Windows Forms, I will finish sooner, but when I'm done, I'm done. To move to WPF at that point will require re-writing the app.

For Brains-On-A-Stick (my podcast agregating app), I'm using WPF and initially creating a very pedestrian UI. Once all the plumbing works, I'll re-do the UI in a variety of ways using WPF and XAML.

If you want to see a WPF podcast player check out Podder. I haven't looked at it much since my app is fairly similar and I don't want to be influenced by their app. The screenshots look great. They took an approach similar to mine by creating a very basic looking app then handing it over to a designer. They are even having a skinning contest.

The big difference in their app and mine is that they are a player whereas I'm more concerned with maintaining libraries and synching them with multiple devices.

Once I get the first whack at mine complete, I plan to look closely at theirs and see how they implemented skinning, etc.

This sounds like a big topic, but it really isn't.

I'll stall and BS a bit to pad the post a little, but really you can sum the topic up in one sentence...

Save your settings and data into a text file or files that live inside one of the folders you have set up to sync with Mesh.

Now wasn't that better than the local news who have a tendency to say things like "Which local neighborhood should be evacuating right now? Tune in at 11 to find out!"

Of course you have to be careful when you do this. You don't want to use large files or files that are updated at a high frequency. I haven't tried it, but common sense tells me that it would be a certifiably bad idea...

Using the example of Brains-On-A-Stick (my podcast organizer) I save my settings file and data files (with meta-data about the podcasts) into a local directory that is set to sync with Mesh. Automagically any changes are synced with Mesh and then my other computers.

This is NOT the smart way to do this, but it is the way that works now withOUT the developers APIs.

One of the things I like about Mesh is the architecture. Behind the scenes all the syncing is carried out using syndication ala RSS or Atom. More or less all these devices are subscribing to each others' feeds and the Mesh server is their conduit and referee. NO WAY! Microsoft building on open standards? Cool.

Quite a bit of info exists on the web already from MS about Mesh. Here are some links:

Mesh itself

Windows Live Dev Blog

Channel9 video: Ori Amiga: Programming The Mesh

Channel9 Video: Abolade Gbadegesin: Live Mesh Architecture

Generic Press Releases etc.

Scobleizer Take On Mesh

Good stuff out there. Lots of us waiting for a chance to use the actual dev APIs.

OK, let me start by saying this isn't really an objective review of Mesh. That would be like asking your buddy about his new girlfriend. As far as he's concerned she's perfect and going to get better than perfect over time.

Caveat number two is that you won't find any amazing new revelations here about Mesh. Everything I'm going to say is shown in the demos on the Mesh.com page. You just have me saying it instead of Microsoft, and my only affiliation with MS is that I use their products. I run a user group dedicated to .Net development, but I am not beholden to them in any way.

Having given you those caveats, let me say that I'm very excited by the potential of Mesh.

I've been using it for a couple of days now and it has proven its worth to me. I have a project that I want to have available at home and at work. With Mesh I can simply go into the file explorer, right click on the folder and add it to Mesh.

When I get to the other computer, I go to File Explorer, My Computer and explore Live Mesh Folders. Once I see my folder, I can right click and tell it to download.

That's it. Now any changes I make on either computer are synced via the Mesh server and Live Desktop.

Kind of like a poor-man's source control but without versioning.

The coolest part is that it is transparent to me when I'm using it. I just fire up Visual Studio or Expression Blend and go nuts. When I go to the other computer the newest changes are there. Sweet.

You can also interact with the other computer via something akin to Remote Desktop. It is naturally slow via the net, but it works. You wouldn't want to rely heavily on this, but when you need something in a pinch, you can reach out and touch it. And copy it from remote to local.

What I'm waiting for is developer access. The ability to easily persist settings and data across devices is compelling.

To use my current project, Brains-On-A-Stick (podcast organizer) as an example; you could save your library data and preferences to Mesh and then have that info available on any machine you are using. Clearly you wouldn't want to put the podcasts themselves up there, but the information about the podcasts.

Coming in the next post: how to persist data and settings to Mesh without the developer APIs...

Just a quick blog entry to list some WPF related links. Why? So I can find them later...

Rob Relyea:

WPF Panels

Rob's main WPF page

Windows Client.net:

WindowsClient.net

Kirk Evans:

Outlook Clone using WPF

Tim Sneath:

Getting Started with WPF

I'll add more to this blog later.