View iPod Nano songs without iTunes, C# Express, Part 5

In the last post, we created the ITunesDBLib class library which allows us to retrieve information from the iTunesDB file and organize that information into useable objects. In this post we'll create the IPodBrowserExampleUI windows forms application, which will use the ITunesDBLib to display it's information to the user.

As with the last post, I won't go through each step to create and add the project to the solution. Instead we'll look at a screen shot of the project and it's classes, and discuss each class and key methods within it. Once again you are free to download the entire source here if you need more information.

Here is a screenshot of the solution with the IPodBrowserExampleUI project selected...

You'll notice that I expanded the References folder so we can see that we have a project reference to the ITunesDBLib. I also expanded the Resources folder since we are using some special icons I downloaded as part of registering my copy of C# Express.

The project itself really only contains two classes: Program and MainDisplay. MainDisplay is actually a partial class and it's two parts are defined in MainDisplay.cs and MainDisplay.Designer.cs. We'll go over these two partial classes in more detail in the next sections. If you are unfamiliar with partial classes however, you may want to check out this article for some background information first.

Program: This is the standard static starting class for a windows forms application. It contains the typical static Main() method that the application looks for when starting.

View Program Code (View)

There's nothing special to note here other than the fact that we are starting the MainDisplay form on the main thread.

MainDisplay (partial class located in the MainDisplay.Designer.cs file): This is the section of the MainDisplay partial class that defines the layout and display of controls on the form - basically the visual logic. Most of this code is autogenerated when you are working in the forms designer, so you should rarely need to come in here. However, I always like to see what Microsoft is doing behind the scenes. It's kind of like looking at your bank statement at the end of the month and saying "my wife spent $50 on what?".

View MainDisplay Code [partial] (View)

MainDisplay (public partial class located in the MainDisplay.cs file): This is the section of the partial class that contains the event logic for the form, and where the real code we need to implement resides.

View MainDisplay Code [public partial] (View)

There are several areas of note in this class, since this is where all the real code is placed. So lets start at the top.

One of the first things we do is declare an instance of the ITunesDBManager...

ITunesDBManager im = new ITunesDBManager();

The im variable can then be used throughout the class to retrieve data from it's underlying objects where necessary.

In the contructor of the class, you'll notice that after we initialize the components, we then run a conditional method called UseDebugPathToIPod. Basically, the purpose of this method is to find out if we are running this code in debug mode (determined by the [Conditional] attribute at run time. If we are, then this method will switch the drive letter of where the iPod is currently residing (typically F: drive). You'll recall that this application is designed to be deployed and run ON the iPod, so in a release version, this method will not be run, and we will use the Environment.CurrentDirectory instead. But during development, you should be testing your code locally (notice I said SHOULD be!).

Also in the constructor, you'll notice that we tie an event handler to the progressEvent event of the ITunesDBManager variable. This is so we can capture it's progress events and display them in a progress bar (I should note that the actual loading of data is so fast this event is not really needed atm, but if the lib were extended, load times could increase and this event might prove more valuable).

MainDisplay_Load: After the constructor, this is the next key method we need to look at. You'll notice that within it we call the LoadITunesDatabase method of the im variable, and pass in the path to the iTunesDB file. All we need to do from this side is figure out where the iTunesDB file is, and the im object will do the rest. Once the im variable has loaded the data and created it's internal objects, we can then get the entire collection of MHIT objects (aka tracks) using the im's TrackList method. We then pass this collection to the LoadTrackList method, which is discussed next.

LoadTrackList: This method is responsible for loading the songs into our grid. It accepts a collection of MHIT objects, and adds the song information to the grid using ListViewItems and their ListViewSubItems. We call the MHIT objects various Get methods (GetAlbum, GetTitle, etc...) to get information from it's underlying MHODString objects, and use those values to populate the list items. Note that the location to the song file is also stored in the tag property (this location does not include the drive letter!).

So that's pretty much all that happens when the form loads. The ITunesDBManager loads the data we need, and we populate our list of songs using the collection of MHIT objects within it. Now that we have our list displayed, we can cover the playing and extracting of song methods.

PlaySongMenuButton_Click: In this event method we allow the user to play a song currently selected in the grid. Basically we get the song subfolder location using the tag property, and then prepend the drive letter to where the subfolder is located on the iPod. Once we have this complete path, we create an instance of the Process object, and tell it to run the file. The Process object basically asks windows to look at the file and use whatever default program it has associated with that file type to open it.

ExtractSongMenuButton_Click: In this event handler method we allow the user to extract the currently selected song(s) from the list to a target folder they specify. Since several files could be selected and this could be a lengthy operation, we make the button itself checkable, and can therefore allow users to cancel a copy operation by unchecking this button.

The first thing we do is check the checkstate of the button. If it is checked, the user wants to start a copy operation on the selected files, otherwise they are cancelling. After this check we then prompt the user for the destination folder using the GetDestinationDir method. If the user actually specifies a target folder, then we go ahead and copy the files selected using the CopySong method, and give a progress update while we do so. You'll note that in the copy loop, we continually check if the user unchecked the button in case they want to cancel the operation.

CopySong: This method is used to copy songs from the iPod to the users machine. The real value of this method is that is converts the song from it's F0#\XXXX.mp# directory path\name storage structure on the iPod to an organized Artist\Album\Song (using title) format on the target machine. I wont describe too much in this method since much of it is self explainatory. Basically we create the directories needed and copy the song over with the new name.

And that's it! As you can see the UI is fairly small and straight forward. It could definitely use some more robust error handling, and the user could really mess things up if they wanted to, but this is just an example after all.

Final Thoughts

So that's it for the article. I hope you got an idea of what the ITunesDB file is all about, and how you can create objects that represent it's elements and retrieve song information. Though this is just an example built for fun, I hope it provided enough structured and readable code to help you design your own applications. Let me know if you have any questions and comments.