Windows Portable Devices

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.

Posted on 5/24/2008 2:25:21 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Brains-On-A-Stick Progress Report

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.

image

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

Posted on 5/17/2008 11:32:00 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags: , , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

WPF - Should I?

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:

image

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.

Posted on 5/12/2008 10:37:00 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags: , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Persisting Data and Settings To Mesh Without The Developer API

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.

del.icio.us Tags: ,,

Posted on 5/1/2008 2:25:00 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags: , , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Windows Live Mesh

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...

Posted on 5/1/2008 1:14:00 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags: ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

New Project, New BlogProcessor?

This weekend I've begun a new project to both scratch an itch I have and to learn some of the new bits of the 3.5 .Net Framework. More on that in a bit.

As a side note, this is my first post from Microsoft's Windows Live Writer. W00t! First post!

I think Live Writer is a step in the write direction (ba-dump-bump). It is a very small program (less than 3 MB) and it doesn't do very much. But what it does do, it does very well. It is a word processor for blogs. It is also free. That is free-as-in-beer for the FOSS crowd, and free-as-in-you-don't-pay-money-for-it for everyone else.

I could use Word 2007 to write my blog entries. I could also buy an RV to cruise around town and pick up my dry cleaning. The point is that 99.93% of the features of Word 2007 are unnecessary for writing this blog post. I don't plan to mail-merge and print envelopes nor do I need fancy macros. Nope, I just want to write, insert links and the occasional picture and have spell check watch my back for crap like spelling occasional as "occassional " or "ocassional " (not that that would ever happen to me).

The web is all around us and that is a good thing, but for some things HTML makes for a poor interface even with AJAX, Achilles, Odysseus or any of the other warriors of the Trojan war. For some things you just need a good old fashioned application running on your computer. The trick is for that application to interact with the mighty Internet and its hordes of servers.

Live Writer is a very good example of doing this and doing it well (he said confidently having never actually tried that big, beautiful "Publish" button).

Enough of that for now, on to the Project. Hmm. I guess I need to give it a secret Code Name to use to speak about it until I decide to release it to the world with a boring name that doesn't mean much (Revolution becomes Wii?). How about this: Brains-On-A-Stick. Since it's a temporary working name, who cares, right? No chance that name could stick. With brains. Man, that was bad.

Here's the annoying-problem-I-want-to-solve: my son, daughter and I all have MP3 players (neither iPods nor Zunes) and we all like podcasts. Keeping up with syncing all those devices with podcasts is a pain in the 'cast. Oh, and I want to try out all the neat new stuff in the 3.5 Framework...

My first thought was to use one of the various podcast feed-readers to pull down the shows and write an app to sync them up. After reading about Microsoft's new MESH and its RSS/Atom use, I decided that it was time to bone up on using .Net to work with syndication feeds. I found several good blogs that talked about syndication and started hacking around with it.

I now have  a rudimentary feed reader that uses the following new bits:

1) WPF (Windows Presentation Foundation). Uses XAML (Extensible Application Markup Language) to describe the presentation. This XML file is parsed and the UI is built on the fly both at design time and runtime. We've all talked about separating presentation from behavior for a long time, and this is one swell way to do it. Why do I find it exciting? You can FINALLY rely on DirectX and your 3D processing video card to handle the graphics (good-bye, GDI, well, mostly). This means your windows (and elements inside the windows) can be 3D and not 2D, even though they look 2D most of the time. This means you can spin a window around and stack them up. More about WPF and XAML in future posts.

2) Expression Blend. If you have the ability to separate presentation from code, then why not make a tool for designers so they can make really cool looking graphics? I'm not a designer, so I'm not going for cool looks yet, but as I get things working, I'll spend more time tinkering with the looks.

3) JSON. JavaScript Object Notation. I'm using this to serialize objects to disk. XML would work just as well, but JSON is all hip and trendy. All the cool kids are using it.

4) LINQ. Language Integrated Query. I'm using this to query the objects in memory. Much more on this later.

5) Syndication. RSS and Atom feeds are how you get your podcasts. The System.ServiceModel.Syndication namespace objects help you work with them.

I'll write about all the little bits as I work through the project.

Posted on 4/27/2008 9:50:00 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags: , , , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

ASP.NET and Godaddy, part 3

Sweet! Got everything working.

As I mentioned in the last post, I dropped back to square one and rebuilt the app one piece at a time to see where the problem was.

I got the login and register pages working first, then went to the data entry page.

Once I built my Linq objects, but before I referenced them, I uploaded everything one more time. I did a diff on the old and new web.config files to see what had changed. There were only two changes: 1) added new connection string and 2) added assembly info for Linq.

A quick check that everything worked well, then I added the code-behind to use the Linq objects to write the data to the database. 

Once everything was deployed, I hit the page and... 500 Internal Server Error.

This time I thought about the new App_Code directory where the Linq objects live. Since I did a website instead of a webapp, everything has to compile on the fly when it runs the first time... hmm. Think maybe that directory needs write permissions?

Added write permissions and, hey presto! Now the Linq data entry page works!

It was literally five more minutes to get the data view page working using a Grid View that uses a Linq object as its source.

One thing I did differently this time was change the name of the Linq datasource to something other than the default.

Now I move on to making things pretty. I'll also write up a more detailed set of instructions and post them. 

 

Posted on 4/22/2008 10:48:00 AM by jeffa

Permalink | Comments (1) | Post RSSRSS comment feed |

Categories: .Net

Tags: , , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

ASP.NET and Godaddy, part 2

Well that worked.

 I dropped back to a blank sheet and worked my way up one step at a time. Only way to eliminate variables that could be causing problems.

Here are the step by step directions to get to a bare page with functional login and registration pages:

1) Create local SQL Server database (Express will do)

2) Dig through C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 and run aspnet_regsql.exe. This will create all the aspnet tables, views, and stored procedures.

3) Fire up Visual Studio 2008 and create a web site.

4) Go to menubar: Website: ASP.NET Configuration. This will start a local web server and spawn a web page in the browser.

5) Modify web.config and put the connection string for the database you created in the connectionStrings section for the name "LocalSqlServer".

6) Close the web project and then reopen it. I didn't verify that this is a required step, but I did it anyway...

7) Re-launch the ASP.Net Configuation like you did in step 4.

8) Enable Roles management.

9) Create a few roles. I made admin and user.

10) Create a user.

11) Go back to Visual Studio and add your database under the Server Explorer tab.

12) Check the aspnet_Users table to be sure your user showed up.

13) Right click on the database and pick Publish To Provider.

14) Only export the table data.

Now we get to the GoDaddy portion of the operation. These steps will require some patience since you have to wait for them complete each step.

15)  Log in to your account and create a SQL Server 2005 database.

16)  Make sure you select to Create ASP Schema for the database.

17) Log in to your new database.

18) Use Query Analyzer to run the file you created back in step 13: Publish To Provider. This will ERASE any existing table data, so use caution on your SECOND AND SUBSEQUENT webapp! For those you will want to only append data, not delete first. You have been warned!

19) Use Godaddy's File Manager to create a new directory and upload your app to it.

20) Using their File Manager's Edit utility, modify your web.config so that the connection string points to the database you created there, not your local database.

21) Use their IIS Settings tool to create a new virtual directory/app. Be sure to select Set Application Root.

22) You should now be able to hit your page.

That was the hard part. Now for the easier stuff.

I'm not going to include these in the step by step instructions, just summarize them.

23) Create a Register.aspx page. 

24) Add a CreateUserWizard from the Login section of the tool box.

25) In properties, set the ContinueDestinationPageURL to the "~/Default.aspx".

26) Add a LoginView control to the Default.aspx page. In the Logged In Template, write something like "You are logged in".

27) In the Anonymous Template add a Login control.

28) Set the Login control's DestinationURL to "~/Default.aspx" .

29) Set the Login control's CreateUserURL to "~/Register.aspx" or whatever you named that page.

30) Test things locally to make sure they work.

31) Upload to Godaddy everything.

32) Make sure you change the connection string in the web.config file like you did in step 20.

At this point it works for me. I can add users and log in.

The key here is to step back, simplify what you are trying to do and build up one step at a time.

In Agile programming you try to break things into chunks that can be delivered early. In this case I tried to do too much with my first attempt. It didn't seem like much until something broke. Now that I have gone back and started much smaller, I have a working system that can register and authenticate users instead of a bigger system that can't do anything...

More details later.

Posted on 4/18/2008 7:56:00 AM by jeffa

Permalink | Comments (1) | Post RSSRSS comment feed |

Categories: .Net

Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

GoDaddy and ASP.NET apps

OK, so I'm finally working on some asp.net projects.

For several years now I've been working primarily on backend systems that do important work with NO visible interface... When we talk about our apps and people ask which part I did, I have to grimace and say, "The parts you can't see..." Without my part nothing would work, but people are only impressed by what they can SEE.

Any way, I'm working my way through the ASP.NET user management controls and made a simple app for tracking your health stats. I used Linq for the database access, and it seems pretty cool. I'll write in another post about what I think so far about Linq.

Got everything working well locally and uploaded it to GoDaddy.com. No go. I got the database populated with the roles, etc. But so far all I get is a big ole 500 Internal Server  Error. Since I'm working in a hosted environment, I can't a huge amount of info about what's happening.

I'm going to blog my efforts here and when I'm finished I'll write up a detailed set of directions.

For now I'm going back to step one and create a page with nothing but a login.

Film at 11.

Posted on 4/17/2008 10:04:00 PM by jeffa

Permalink | Comments (1) | Post RSSRSS comment feed |

Categories: .Net

Tags: , , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Fiddler - The Web Developer's BFF

I just found a really cool tool called Fiddler.

When I say I found it, what I mean is I read about it in a post on Kirk Evan's blog. He was talking about Creating Restful Services Using WCF

If you aren't doing web development, then just move along, there's nothing to see here.

If you ARE doing web development then you really need to see this.

When you run Fiddler on your system it sits as a proxy between your web browser and whatever web server you are connecting to. In simplest terms it lets you dig into the request and response objects to see what makes them tick. The cool part is that it goes far beyond that. It lets you change those objects on the fly to see what happens. It also lets you set break points in the process. The Fiddler website has a video that demonstrates setting a breakpoint on any CSS files that are downloaded. You ask for the webpage and it freezes at the point of pulling down the CSS file. You can inspect or modify the CSS file and then let it go on to the browser for rendering complete with any changes you made!

That's pretty cool when you are stuck on a bug and need all the info you can get. "Fiddle" around with the values and see what breaks. Or starts working.

You can also extend Fiddler using .Net. I hope someone makes a cool framework that Fiddler can use and calls it "The Roof". Then like the Ruby language using the Rails Framework is called "Ruby On Rails", we could have "Fiddler On The Roof".

Posted on 4/15/2008 3:42:00 PM by jeffa

Permalink | Comments (0) | Post RSSRSS comment feed |

Categories: .Net

Tags: , , , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5