Windows 7 slate PCs Part 1
I’ve been working on these things quite a bit …
We call them “slates” … specifically Windows 7 slate form factor PCs. They are pretty cool devices. I’ve worked on some projects and there are others on Product Scout. I’ve learned some tips and tricks architecting and developing for these devices, so I thought I’d share them here. This is not intended to be an exhaustive guide of how to design and build these applications. Instead, the intent is to give a set of considerations, hints and in some cases best practices that might not be immediately obvious, but should be planned for early in the design or development cycle of the project. (As you know, I’m not a designer, so I will not discuss anything regarding how your app. looks or how it functions from a UI perspective. That’s all up to you.)
NB: Code presented here is of example quality only. Please don’t cut and paste this code into your solution. Proper error handling, logging and graceful failures are not included.
Now for a definition … I write “slate”, I mean a touch enabled tablet or slate form factor Windows 7 PC like the Asus EP121 or the Del Inspiron Duo. In general, these devices are installed with Windows 7 Home Premium – I will assume that unless otherwise noted. I will also assume you are building a Silverlight 4 out of the browser, trusted application (SLOOB).
(Interjection here: I thought we would never get a better sounding acronym that GAC (“gack!”) which is not to be confused with Gach. But we did! Sloob takes the cake!)
If you have another scenario such as WPF or HTML5, the design notes may come in handy, the development notes less so. I am not trying to re-write articles from MSDN or provide in-depth detail on subjects. I will link relevant articles when more detail is required. I will call out “Gotchas” throughout. Gotchas can have an impact early in the project design, can easily be missed and may result in a great deal of rework.
I will cover the following topics in varying detail and in multiple parts. I will call out when a topic covers design as an alert.
Gestures and Multi-Touch (Design)
Signing Your XAP (Design)
OAuth (Design, Dev)
Dynamic (Dev)
HttpWebReqeust v.s. WebClient (Dev)
Remote Debugging (Dev)
Registry Access (Design, Dev)
Unique Device ID & Hiding Keys (Design)
Trust Me!
Silverlight applications generally run in a sandbox for security purposes (in or out of the browser). But sometimes, applications need access to more of the capabilities offered by the client. Silverlight 4 allows out of the browser applications to be configured the application to run in elevated trust. (Even more goodness is coming in Silverlight 5!) In general the projects I have done have made heavy use of native integration. Running in elevated trust gets you pretty close to the power of the client, but access is not compete. If you need more access to the client that a SLOOB offers, you have to look toward WPF or Silverlight 5.
Gestures and Multi-Touch (Design)
There is a difference between multi-touch and gestures. This will affect your design and development. Multi-touch is the ability for touch sensitive hardware to treat multiple, concurrent touches as a single unit (sometimes called a “frame”). A gesture is a series of touches and drags that are combined together into a logical action. Common gestures are Rotate, Zoom, Pan, Flick, Two Finger Tap, Press and Tap, Press and Hold.
More about multi-touch and Silverlight
Multi-Touch Silverlight Demo
Multi-Touch Samples
You must understand this difference! Multi-touch is supported natively in Silverlight 4, but gestures are not! If you want gestures, you have two choices: (1) you can create your own gesture library; or (2) you can use Native Extensions for Silverlight v2 (NESL).
(I have tried other gesture libraries, but did not have good success with them. If you are saying “hey what about _____”, put a comment on why you think _____ is a good gesture library for a SLOOB).
NESL exposes Windows 7 functionality via COM Automation. As such, only SL4 out of browser, elevated trust applications need apply. In addition to gestures, NESL exposes Sensors, Portable Devices, Speech, Taskbar and more. NESL must be deployed with your application. There is a deployment and installation discussion in the Dev Guide.
Gotcha: Installing COM components requires administrator level privileges. When the installer for NESL is run from your SL application, the user will be prompted by UAC to elevate their privileges. If the user is unable (not an admin) or unwilling (clicks cancel) to do so, the NESL install will fail. It is a design question whether or not you will allow the application to continue with reduced functionality after a NESL install failure.
Gotcha: Silverlight in full-screen mode does not support Multi-Touch. If you require multi-touch or gestures, you cannot use full-screen mode. Your design should be specific about the Windows 7 taskbar in this case. There is no way to hide it, cover it or manipulate it. The user can have their taskbar on the bottom, top, left or right. It can be between 0 and 12 units high. Do not try and battle Windows 7 and your users’ preferences, you will lose.
If you chose to create your own gesture library, Microsoft Surface Manipulations and Inertia Sample for Microsoft Silverlight is a good place to start. Make sure your project schedule has plenty of time for development and testing in this case. It will also be necessary to have a large sample of various devices as the digitizers on these devices tend to behave differently.
You will also need to understand how Windows 7 treats High DPI devices. To wit, the user can change the number of Dots Per Inch (DPI) shown on their screen. This is handled in the Display Control Panel. The goal is to have the user display their native resolution while still being able to make elements on the screen larger. A SLOOB can determine the user’s DPI setting by using the ZoomFactor property on the Content object. The user can also set a custom DPI size or choose to “Use Windows XP style DPI scaling”. SLOOBs are not marked as High DPI aware and I know of no way to do this. That means that if the chooses not to use Windows XP style DPI scaling, she will turn on full DPI scaling for your application. This needs to be dealt with in your UI design or your app will not look good and your gestures will not function properly. This tends to be a huge can of worms, so I recommend against writing your own gesture library at this time.
Signing Your XAP (Design)
The unit of deployment of a SLOOB is a XAP. XAPs can be deployed via a web site or via command line (docx link). When a user installs a SLOOB from a web site, she will be prompted with a Security Warning indicating that your application can potentially access their personal data and damage their computer. This is a typical Authenticode warning. If the XAP is signed with a certificate that can be verified by a Certificate Authority, the warning will indicate the name of the publisher. If the certificate cannot be verified, the user will be told that the publisher of the application is unverified.
A XAP can be self-signed (signed with a made up certificate) for development purposes, but should always be signed by a valid, verifiable, code-signing certificate for deployment. Code-signing certificates can be acquired through a certificate provider like VeriSign, Thwate, GoDaddy and others.
Gotcha: A code-signing certificate is not the same as an SSL certificate. It can take time to acquire a code-signing certificate. If you do not have a code-signing certificate, the process of acquiring one should start at the beginning of the project as it is not a completely automated (there is human interaction in the process to verify your identity).
Gotcha: In order to be automatically updated, an elevated trust SLOOB must be installed with a signed XAP. (Put another way, if you plan to use CheckAndDownloadUpdateAsync from an elevated trust SLOOB, the XAP must be signed).
Gotcha: If you deploy a self-signed XAP into production, be sure to understand the legal, corporate compliance, brand management and public relations impacts to that decision.
Next time we will talk about OAuth and HttpWebRequest.