Not your regular photo and video camera on Windows Phone 7

The default Windows Phone 7 doesn't exaclty come with support for custom camera viewers. Or at least this is not officially documented. It is well known that the GAC on the phone contains libraries that are not publicly accesible via Visual Studio - Microsoft.Phone.InteropServices and Microsoft.Phone.Media.Extended were floating around for quite a while. The initial approach taken to access those was through reflection, but it involved some more complex problems - with the capabilities available, some elements needed event handling and with limited Reflection capabilities on the phone, this is a real pain.

To help fellow developers out, Thomas Hounsell released the entire GAC dump - with all internal libraries out there, so it can be used in Windows Phone 7 applications for testing purposes. I am saying "testing purposes" because applications that are using unauthorized libraries will not be accepted in the Marketplace, even though the libraries are already on the phone.

Using a DLL is fairly easy, but I was curious whether I would be able to access the internal library without an additional reference. Here is what I came up with.

// Load the assembly that is not referenced anywhere.
// Additional data is required for proper detection.
Assembly extendedAssembly = Assembly.Load("Microsoft.Phone.Media.Extended, Version=7.0.0.0, Culture=neutral, PublicKeyToken=24eec0d8c86cda1e");

// The CameraSource defines the source of the image - can be either
// PrimaryCamera or SelfPortraitCamera.
// Here I need to get the enum and re-create it to pass it to a Photo/VideoCamera constructor.
Type cameraSource = extendedAssembly.GetType("Microsoft.Phone.CameraSource");
FieldInfo item1 = cameraSource.GetField("PrimaryCamera");
int typeOfSource = (int)item1.GetValue(cameraSource);
object _typeOfSource = Enum.ToObject(cameraSource, typeOfSource);

// Actually detecting and instantiating the camera object.
Type staticCamera = extendedAssembly.GetType("Microsoft.Phone.PhotoCamera");
ConstructorInfo cameraConst = staticCamera.GetConstructor(new Type[] { cameraSource });
object pCam = cameraConst.Invoke(new object[] { _typeOfSource });

// Camera visualizer will eventually display the image on the screen.
Type t = extendedAssembly.GetType("Microsoft.Phone.CameraVisualizer");

// SetSource is the method that will initalize the visualization from the viewfinder
// as soon as a proper Camera-based object is passed.
MethodInfo m = t.GetMethod("SetSource");

ConstructorInfo _cvConstructor = t.GetConstructor(Type.EmptyTypes);
object _cv = _cvConstructor.Invoke(null);

// I need to add the CameraVisualizer object to the main Grid. It has to be on the page.
// Otherwise it will not be shown.
LayoutRoot.Children.Add((UIElement)_cv);

// Show me the picture!
m.Invoke(_cv, new object[] { pCam });

A bit of work with enums, a bit more work with custom constructors and method invocation and everything was ready! Notice that I am explicitly passing a PrimaryCamera as a camera source. Generally, there are two options (as seen in Reflector):

Not a single Windows Phone 7 device comes with a built-in front facing camera, other than some prototype and developer devices. Since I have a Samsung Taylor, it has that SelfPortraitCamera, so I thought that it was worth a try using it. However, when I substituted the parameter string, I got this:

Not exactly what I expected to see, but that's fine - I guess Microsoft didn't hook the API to the actual hardware yet (hopefully this will happen in the near feature with new devices coming out). 

So the result of the code above (which might seem like a big mess) is this (in the emulator):

The translucent patch that you see is the actual CameraVisualizer - unlike PhotoCaptureTask, this one allows you to have the camera window right on your page. It is also safe to assume that you will have to do the camera management on your own inside the application, handling new images and such.

However, going through the camera functionality via Reflection is a bit long and creates quite a bit of additional code in the app. Instead, I added the GAC assembly - GAC_Microsoft.Phone.Media.Extended_v7_0_0_0_cneutral_1.dll, to the application. It is a managed assembly therefore you will not need the WMInteropManifest.xml presence (or <Capability Name="ID_CAP_INTEROPSERVICES"/> for that reason). Further on everything will be cleaner (compared to the Reflection way), I promise.

There are two main classes that you can use to access the camera:

• PhotoCamera - for static image capture.
• VideoCamera - for dynamic image capture.

Each of these classes has a superclass (aka an abstract class they inherit) - Camera:

The class initialization is facilitated by two constructors - one that doesn't have any parameters and the second one, that accepts a CameraSource type:

PhotoCamera pCam = new PhotoCamera();
VideoCamera vCam = new VideoCamera(CameraSource.PrimaryCamera);

As I mentioned above, CameraSource.SelfPortraitCamera isn't available so I won't touch it.

While both the photo and video cameras have a set of options that allow the developer to customize the general usage experience, these should be accessed after each instance is initialized. For that, there is the Initialized event handler:

vCam.Initialized += new EventHandler(vCam_Initialized);

That's where the fun begins.

void vCam_Initialized(object sender, EventArgs e)
{
    ((VideoCamera)sender).LampEnabled = true;
    ((VideoCamera)sender).StartRecording();
}

I can enable the lamp (LED on the back) and start recording right here. But if I run the code as it is now, nothing will happen. That's because the application has no idea where to display the captured data, and this is where the CameraVisualizer takes the stage - it is a standard UserControl that at the end inherits from UIElement, so it should be placed on the page. By itself it's not of much use.

So here goes:

CameraVisualizer vis = new CameraVisualizer();
LayoutRoot.Children.Add(vis);

vis.SetSource(vCam);

Right after initialization, I am adding it to the main grid (named LayoutRoot) and I am setting the capture source to be the VideoCamera instance I created above.

Once I run the code above in the emulator, I can see the same translucent square that shows the images from the viewfinder and I will also hear a click, meaning that the lamp (LED) was enabled - the behavior is the same on the phone, with the added image.

For the photo camera, you can set the flash mode (defined by the FlashMode property), but the LED won't stay on constantly and only during the picture taking process.

Talking about taking pictures, the shutter button also becomes absolutely controllable and is no longer tied to the system camera application (while your app is running). Therefore I need to make sure that it's behavior is tracked. This can be done via three event handlers:

• AutoFocusButtonPressed - occurs when the camera button is slightly pressed (to get focus)
• AutoFocusButtonReleased - occurs when the camera button is released from focusing mode.
• ShutterPressed - occurs when the camera button is fully pressed.

That being said, here is a code snippet that would be perfectly acceptable:

vCam.ShutterPressed += new EventHandler(vCam_ShutterPressed);

void vCam_ShutterPressed(object sender, EventArgs e)
{
    Dispatcher.BeginInvoke(new Action(() => { MessageBox.Show("Hello!"); }));
}

I need an invoke here because the shutter button click is tracked on a secondary thread (managed by the OS). I decided to have fun with the button and actually used it for zooming in:

((VideoCamera)sender).ZoomIn();

Zooming out is done by calling ZoomOut(). The interesting thing is that the image inside the CameraVisualizer is mirrored, therefore movement is not done in the same direction as the system application. Generally, I would say that a workaround like this is in order.

With these capabilities at hand, you can build your own camera application that can introduce many rich capabilities that otherwise cannot be achieved with PhotoCaptureTask.

I will be talking about the ways the photo and video camera instances record data in my next article.