In At The Depend

  • Article

Which is the best way to prevent intrusion attacks on your server from the network? What is the largest size of application XAP file you can deploy to a Windows Phone 7 device? When should you cache the data used by your application in memory? How many magicians does it take to change a rabbit? Obviously the correct answers are "Unplug the network cable", "400 MB", "Always", and "None, it's just a trick".

Or are they technically "correct"? Can you equate "best" with "basically, the server's not working any more"? Certainly it's the most positive and reliable way to protect your server, but it's somewhat lacking in practicality in terms of a non-broken network. And what about Windows Phone 7 users who rely solely on their phone supplier for connectivity? The maximum size of a XAP file you can download without using Wi-Fi or a USB cable is 20 MB. And, of course, caching a 3 GB collection of data transfer objects when your computer has only 2 GB of memory may not provide better performance...

All this comes about because we decided to include the now highly fashionable "Check Your Understanding" section in all of the chapters of our new Windows Phone 7 Developer Guide. I can't say I'm a huge fan of these sections as they add to the effort of creating the guidance - though I do agree they are useful. I used the ones in our recent Parallel Programming with Microsoft .NET guide to figure out if I actually did understand any of the topics in each chapter. Mostly I patently didn't, but that's a different issue for which I can't blame the authors.

So, anyway, having agreed to include them in our latest tome I had to figure out the appropriate style and content. I started by watching some TV programs that supplement their income by offering cash prizes for answering a simple question. Based on this, we'll be including a knowledge check such as:

Which of the following is a well-known computer operating system?

  1. Portholes
  2. Skylights
  3. Windows
  4. Double glazing

OK, maybe more research is required. So I check out the program for people who want to be millionaires. How about:

What does the computing abbreviation "AMLCD" stand for?

  1. American Music Lovers Compact Disk
  2. Anti-static Mat for Laying Computers Down
  3. Active Matrix Liquid Crystal Display
  4. All Men Like Counting Ducks

So, you see, it's not as easy as it might seem. And how many questions should there be? How difficult should I make the questions? Will they actually help people to understand the content of the chapters? Can I include one or two stupid answers to liven it up? Will all this asking questions about questions finally result in a stack overflow error?

In the end we decided on six questions per chapter, multiple choice from four possible answers, and medium-level in terms of difficulty or obscurity. Such as:

Which of the following programming techniques are permitted in a Windows Phone 7 application?

  1. The application can terminate if the phone does not have extended memory installed.
  2. The code can use PInvoke or COM interop to execute native code.
  3. The application can use code that is not type safe if this is absolutely necessary.
  4. The application can use reflection to discover and invoke types that require security permissions.

The next step is to provide the answers. Annoyingly, I haven't found a way to display them upside down at the foot of page 97 using HTML - but that's the production department's problem, not mine. All I need to do is supply the text for the answer. And it's obvious that the answer to the previous question is "None of the above". Easy! And I've reinforced the reader's understanding by checking that they will remember these limitations when they start designing their Windows Phone 7 applications.

But, unfortunately, the dreaded cyclic dependency factor now comes into play. One of the major things I learned from working on the Microsoft Application Architecture Guide guide a year or so ago was that, for any question you ask an architect, the answer will always be "it depends". And the same applies, it seems, to most other computing-related stuff.

Looking back at the question above, you would have to agree that "a" is not permitted. The requirements for Windows Marketplace certification clearly state that your application must work on any device that meets the Windows Phone 7 specification, and extended memory is an optional feature of the phone. Except, elsewhere, it says that the maximum memory usage for a WP7 application is 90 MB unless the device has more than 256 MB of memory installed. But then it says that the application must run anyway, and only take advantage of extended memory when it is available. So, in a round-about way, it seems that "a" actually is not permitted.

What about "b" and "c"? These are both definitely not permitted, so we're OK there. Except that I was told that OEMs developing Windows Phone 7 devices can use C++ and native (so technically unsafe) code. So if you were feeling picky, you could dispute that part of the answer we provide. But, in general, we're still OK I reckon.

And so, finally, is "d" permitted or not? Well, it seems the issue is that the Marketplace submission process unpacks the XAP file you provide, scans the code to determine the security permissions it requires (for things like using the microphone, camera, location service, etc.), and then recreates the manifest file in the XAP so that it lists only those actually used by the application. This means that Marketplace can list the phone features the application uses with confidence that only these can be used in the code.

But the Marketplace code scan does not find types that are discovered and instantiated using reflection. Therefore, if you use this approach to locate and instantiate a type that requires security permission, and the application manifest does not include that permission, your application will fail with a security permission error. However, if you have already referenced the type using the normal approach the manifest will contain the required permission, and so the app will run. Technically, the programming technique described in "d" is not "not permitted", but rather it's "discouraged" because it is likely to cause the application to fail in most cases.

So, even though I wrote the question, I actually got the answer wrong. I told you this was harder than it looked...