As we (average developers :) ) still don’t have access to the Windows Phone 8 SDK I decided to write a post on the current MediaLibrary limitations for Windows Phone. I only hope that someone from the team will read this post and maybe there is still time to improve some aspects in the new version. Everything here is my personal opinion.
So what is missing from the MediaLibrary?
The most important for me. Why? Let’s open Internet Explorer on the emulator and go on a webpage that has a picture in it, tap-n-hold and save it twice. If we use Windows Phone commands to launch the Pictures hub in the emulator and go to the Saved pictures album we will see both pictures (same picture but different items). Now let’s create a new project and see what we can get using the MediaLibrary class. I will use this simple code to debug and stop on the pictures to watch its properties:
MediaLibrary ml = new MediaLibrary();
var albums = ml.RootPictureAlbum.Albums;
foreach (var album in albums)
foreach(Picture pct in album.Pictures)
bool stophere = true;
We can see both pictures but the BIG problem is that the only way to differentiate between the two of them is the Date property (not very elegant, Handle is not public property). The Token property makes a lot of sense to tell which picture is which (maybe also a Path member could be added but Token is way better as we already have the method to open a picture from its Token and you won't have to iterate all the MediaLibrary just to get the picture we want).
This property should be fairly easy to add as it already exists internally (when we use the PhotoChooser we will get the token associated with the selected picture and we will be able to open the picture) .
The token could be extended also to the PictureAlbum class. It doesn’t make much sense to iterate the MediaLibrary to find a specific album if I already know what PictureAlbum I want.
In this moment the Pictures Hub already has built-in albums but it is not possible to create new albums directly from the phone. It is possible to do it from Zune (which will not be used anymore) but it is not a trivial task (at least till you understand how it works). So we are mainly stuck with two “containers”: Camera Roll and Saved Pictures which is not enough for a device that theoretically could hold up more than 1GB of photos. From here the need to have tools to organize your photos better by creating new albums and copying/moving photos between albums. Maybe it is a little late to implement it in the "standard" WP8 UI as we are two months away from the official launch of the first phones on the market but maybe not too late to add the functionality in the development tools so the developers can implement it in their apps. This way a photo app could create its album and then the users will know in which album to look when they want to find pictures modified/created by a certain app.
Needed since the first version of windows phone but still no sign of it. Videos are an important part of the device media and developers need access to this part of the MediaLibrary to enable applications like video processing, video backup, video creation and more.
This functionality already exists in the Windows Phone Mango/Tango but it doesn’t work in the current version of the SDK. I’ve already posted a question on the forum with no answer till now. The count of the Favorites album is always 0.
Useful for applications that want to backup the pictures from the device automatically. If it’s a problem of security see 6 but if the user already agreed at some point (capabilities, ask permission) it doesn’t make sense to lock the access to the medialibrary from the background tasks.
I think the current ID_CAP_MEDIALIB is too generic. It would be better to have specific CAP for pictures, videos and songs. They are pretty distinctive and a photo editor wouldn't need access to the songs on the device? Also the user should be warned that his photos might contain GPS data in the EXIF header and he should agree to let the application access those informations.
P.S. Almost all of the features requested are already implemented in the iOS development tools.