IE User Agent String in Windows Phone 8.1 Developer Preview

I think Microsoft is seriously worried about Windows Phone being not considered as a mainstream device as many websites are still not detecting (or interested in) it and thus rendering only the desktop version of the websites for IE on Windows Phone. But, if you have been noticing lately, Internet Explorer on Windows Phone 8.1 Dev Preview of GDR1/Update1 appears to have addressed this problem via a quirky trick. The user-agent (UA) string of IE on this update has changed to an interesting one; the new UA includes identifiers for Android and iOS devices too and so device-aware sites render properly as if they would on an iOS device or Android one depending the browser detection logic used by those sites. From my Lumia 1520 running WP 8.1 GDR1 DP, the UA looks like this:

Mozilla/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 1520) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537

But at the same time the new UA causes some interesting problems too. An example is below, as recognized by a popular browser detection website:



For instance, if a website has mobile platform specific UI rendering logic (say, one that renders pages for native UX, visual cues, etc.), the new UA could cause confusion and make the browser detection logic become even more complex. Not only that, it could also skew the web analytics aspects of websites by accounting Windows Phone as either iOS or Android unless the analytics engines takes care of the new UA. So, if someone heavily relies on user-agent any important logic, be prepared to tweak your logic.

Dynamic Item Templates for LongListSelector

For one of the Windows Phone 8 pet projects I am working on, there was a need to list/enumerate available theme resources (see http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769552(v=vs.105).aspx for the list) and show a preview of each of them on the screen. While it sounded very simple when I started off, it all became too tricky because I wanted this feature to be dynamic. In other words, I was looking for a Windows Phone API sort of thing that would get me the list of all inbuilt theme resources so that any new ones that might be added in future phone versions would automatically be picked up by the app and I do not have to make changes to the app code. After a desperate search everywhere, I came to the conclusion no such API is available in Windows Phone 8 SDK (if you know of any such API, please drop a comment below) and this left me to the only option of hard-coding resource names in my preview app. Well, that was a bit of a compromise!


The second part of the feature is showing a preview of available theme resources (colors, font sizes, font families, text styles, etc.). I decided to stick with a simple ListBox (or a LongListSelector) and “templatize” the list items dynamically so that each item in the list control will have a theme resource applied to it and thus a preview. A couple of screenshots of it below:




 


Here comes another challenge: change list item template constituents (controls) based on the resource type and apply the resource to that template. For example, I would have a TextBlock for font names, text block styles, font sizes and alike. However, I thought a text block may not be the right choice for brush and color resources; may be a filled rectangle shape could be a better one. So, I went with a Border element so that I can have a TextBlock inside it to display the resource name (Rectangle cannot have child elements). Since there is no support for dynamic item template selection in Windows Phone yet, I have seen people following different (yet similar) strategies to get the dynamic template behavior. One way, for instance, is to have your view model expose multiple DataTemplate properties and define a binding converter that would check the bound data and return an appropriate data template property. Another approach is to define multiple data templates as static resources instead of view model properties. The binding converter would then map the bound data to the appropriate static resource and return it. Of course, there are different ways by which you can implement it.


For the resource preview feature, I went with a slightly different logic. While the fundamental approach of mapping data to item templates remains the same, I decided to construct the data templates dynamically at runtime instead of declaring as static resources because I wanted control over the data template at runtime.


This is how my LongListSelector looks like:



 


The LongListSelector binds to a simple list of strings representing theme resource names. As you know, since I am not binding to any specific property of my data object, the entire object is passed to my binding converter. For this app, it is just a string representing the resource name that I can use to look up the application’s resource dictionary.








 


As you can see, the binding value converter constructs the data template using either UI elements directly or XAML markup parsing (I have shown both just for the demo), sets the properties and returns it. The returned content will be the child element of the ContentControl declared in the list item’s data template in XAML.


Hope this helps someone.


UPDATE: I had to disable commenting due to heavy spam comments. Sorry about it.


 

Passing Metadata to Exports in MEF

Perhaps this post should have been out before my previous one the topic. Anyway, continuing the journey on Managed Extensibility Framework (MEF) in .NET, let us see how we can attach metadata to an exported type and how it can be retrieved on the importing side, all in short steps (I am not going to spend much time and dig deep in to each of the available options; this objective here is simply to highlight the available options). I cannot stress enough the importance of metadata in MEF and discuss various scenarios where it proves useful. Nevertheless, there are four ways by which you can associate metadata to an export:


  1. Using an interface definition with properties representing the metadata
  2. Using a raw IDictionary <string, object>
  3. Using a helper class that receives an IDictionary<string, object> and provides a convenient wrapper
  4. Using a custom class for strongly-typed metadata

The first three approaches evolve around IDcictionary<string, object> type and as such, metadata is limited to key-value pair. Let us see how the first one works: you define an interface with read-only properties that represent the metadata. Once that is done, you can straightaway go and use ExportMetadata on the export parts:



It is very important that the interface properties are read-only and theirs name matches with the string key specified in ExportMetadata attribute. Also, you do not have to create a class that implements the metadata view interface; the MEF automatically creates one which accessible via the Metadata property on the Lazy<ProviderBase, IMetaView> type.


The second does not require you to define an interface to wrap the metadata properties; rather, MEF exposes the raw metadata dictionary directly on the Lazy<ProviderBase, IMetaView> type. It is the export and import developers’ responsibility that they use pre-agreed keys (as an explicit contract) and values types for the metadata dictionary. A simple misspell of the key or an incorrect data value for example, might result in erroneous metadata processing.



The next option for providing metadata is sort of a blended version of the first and second ones. You need to create a concrete class with properties representing the metadata but that class should have a public constructor that accepts IDictionary<string, object> as the only parameter. It is up to you how that class should interpret and expose the dictionary of export metadata. It is also not necessary that the class’s property names should match the keys in the dictionary received by the constructor. The key-value pair is all at your disposal for how you want to make use of it.



Here is the metadata view class. Just to demonstrate that the class can interpret and expose the provided metadata values by its own logic, I am simply exposing Name and Version metadata values in a different name to the importing type.



The final option gives you a strongly typed way to declare, define and consume metadata. As a first step, as in option 1, define an interface with read-only properties that would act as the metadata view. Then, define an attribute (class derived from System.Attribute) and mark it with MetadataAttribute attribute. This custom attribute should implement the interface defined in the previous step. These properties can be populated via constructor parameters (shown below) or direct property assignment at the calling site (export types). The final step is to decorate the export types with this custom attribute and supply the metadata values:



The custom metadata class is here below. Please note that this class does not have to implement the above metadata view interface as long as it exposes read-only properties matching the names and types of the properties present in that interface (duck typing).



Hope you found this post useful.

Metadata Inheritance in Managed Extensibility Framework (MEF) in .NET 4.5

I have been playing around with Managed Extensibility Framework (MEF) of .NET 4.5 for a while now. Overall, it is a great framework for designing many plug-in/extensibility scenarios of .NET applications, web, desktop or even Windows Store (Metro). One area that got interesting in my MEF experiment was the way in which metadata worked in the case of inherited exports. As you know, in general, there are three ways to attach metadata to export parts (classes decorated with Export or InheritedExport attribute):


  1. Via ExportMetadata attribute
  2. Define a class deriving from ExportAttribute type, define one or more read-only properties representing the metadata and mark that class with MetadataAttribute type
  3. Define a class deriving from Attribute type, define one or more read-only properties representing the metadata and mark that class with MetadataAttribute type

In my experiment, the first two options were like breeze. The third turned out be a bit challenging to get it correct; I was not sure if the behavior I noticed was the intended one or a bug. Here is what I did:


  1. Define a class deriving from Attribute type and mark it with MetadataAttribute. This class will have read-only properties each representing the required export metadata. In fact, the metadata properties were wrapped in an interface and the custom attribute class implemented that interface.
  2. Define my base export class marked with InheritedExport attribute and also the custom metadata attribute I created in step 1

Here is the code:


 


Then, I went on to apply this custom attribute to my base export part that also has InheritedExport attribute on it. I defined two more classed deriving from the base export and applied metadata with the custom attribute. At this point, there are three export parts, each with its own metadata tagged via the custom attribute – CustomMetadata. Here is the code:


 


I setup a simple composition container to test out the metadata:


 


However, the output of the above took me for a surprise and I spent hours trying to fix this but later I inferred from various blog posts, Stack Overflow responses and the MEF CodePlex site that this behavior is “by design” in MEF! I was expecting the respective mask and symbol metadata values of each export part to be printed; rather I got the mask and symbol of the base export part printed for all three.


 


As you can see, the metadata supplied at each inherited export type was completely ignored. Rather, the metadata specified at the base class was carried on to the inherited classes too (contradicting to what I read at http://mef.codeplex.com/discussions/82448/). One solution to this issue is to stay away from the InheritedExport and explicitly apply Export attribute on each export part specifying the base export type:


 


And the corresponding output is:


 


The other solution is to have the custom metadata attribute extend ExportAttribute (in addition to the metadata interface) as shown below:


 


Then apply this attribute on each export part (without explicit Export attribute, since the new custom attribute extends the ExportAttribute type):


 


The output remains the same: each export part correctly gets the metadata supplied via the new custom attribute.

Surface in Tablet

Microsoft now reassured its affection for tablets! Its earlier attempts on tablets with Windows XP Tablet PC editions and Windows 7 had only slim chance to make a successful entry into the market, as both lacked a sound hardware counterpart. This time now, inspired by its Surface platform, Microsoft gets ready for its Surface tablet featuring the latest Windows 8 operating system. But, most importantly the new tablet now stands a chance to be considered as a real competition for Apple’s iPad (Apple still enjoys a near-zero competition for its tablet business segment).



Affirming its love with ARM processor, the Surface tablet comes in two processor flavors, Intel and ARM with the former being little heavy physically. Here are the things I see that could potentially go in favor of Microsoft Surface table and pose as a real iPad challenger in the consumer market:


 


  • Most-widely adopted PC operating system vendor – both at enterprise and home consumer levels (how Windows 8 would the reap the benefits from the success of its predecessor is something yet to be seen since Windows 8 has a new user experience philosophy – Metro).
  • One vendor OS targeting data center to PCs, to tablets and mobile phones, Windows 8 could mean a seamless experience among all these platforms and build a unified application ecosystem.
  • Support for both Intel (high-end usage, costlier) &amp; ARM processors (casual users, cheaper compared to Intel’s)
  • Support for extensible memory storage – micro SD slot (iPad offers this option but via an accessory you have to buy separately)
  • Standard USB slot – while what devices would be supported with USB on Surface is unknown, many iPad users crave for this on iPad for peripheral connectivity!
  • In addition to touch and stylus inputs, two types of unique screen covers each doubling up as keyboard &amp; mouse on their own – All out-of-the-box

 


It would be a huge win if this tablet can run existing desktop Windows applications (if not all, may be) without modifications and support developing applications targeting both PC and tablet with a single deployable package.


There are no words about Surface tablet supporting 3G/4G cellular connectivity but if the device lacks it, that would be my biggest disappointment.

Zip Archive Gets Native Support in .NET 4.5

With v4.5, zip archival handling comes natively to .NET. No longer do you have to rely on 3rd party components to create, manage and extract zip files, though most of them are free.


The types you require to manage zip archives reside in System.IO.Compression namespace, in the System.IO.Compression.dll assembly and those types are ZipArchive and ZipArchiveEntry. The first one represents the zip file as a single entity while the latter represents an individual file in that zip. Note that ZipArchive acts like a pass-through stream, which means you should have a backing store (storage stream) such as a file on the disk.


ZipArchive & ZipArchiveEntry


Creating a zip file and packaging one or more files into it is relatively straight-forward. The following code creates a new zip file, Summary.zip, containing a single content file CS Summary.ppt.


Code Snippet


You may provide a relative path in CreateEntry if you would like to keep files in hierarchical way in the archive. The following code iterates a zip file’s contents and gets few basic details about each file in it:


Code Snippet


Extracting a file from the zip archive is as easy as packaging one into the archive but just in opposite direction:


Code Snippet


If you notice the above code listings for reading and writing zip files, we are dealing with multiple stream objects, even to create/read a single archive and write/extract a single entry into/from that archive. To ease the whole thing, .NET 4.5 has few convenient types with which you can create and read zip files with fewer lines of code. Basically, these types add extension methods to ZipArchive and ZipArchiveEntry types. Note that you have to add reference to the System.IO.Compression.FileSystem.dll assembly. The following code creates a new zip with a single file in it:


Code Snippet


Of course, you can add as many files as you want to the archive by calling CreateEntryFromFile multiple times. As of this writing, this method doesn’t support adding an entire folder to the zip just by specifying the folder name for the first parameter (or by any other means).


Extracting a file from zip is as easy the following code which extracts the first available file in the archive (assuming it is not a folder) and saves it to the file system:


Code Snippet


MSDN Reference: System.IO.Compression Namespace

Thoughts around Microsoft .NET, architecture, design, gadgets.