I know I’m late to the game but I received my Lumia only yesterday. I’ve had a Windows Phone 7 LG E900 a.k.a LG Optimus 7 for 16 months now and I’ve generally been very happy with it. Even though the Lumia is so much newer, spec-wise it does not add much to my old LG: slightly faster HSPA network, faster processor, and some Nokia software, that’s all. Below I’ve listed some pros and cons of Lumia over LG.

Pros

  • Design and the looks are better. I wish I could have had a red phone but my employer had only the (boring) black ones listed.
  • Construction is excellent. LG wasn’t bad and felt solid, but Lumia tops the scale. The plastic back plate feels better than the metal one on LG.
  • Screen: while the screen is too small – in fact 0.1 inches smaller than LG had – it has better contrast and the blacks are really blacks.
  • Automatic screen brightness setting works well. The levels are good for my use.
  • Nokia drive and Nokia maps work very well in Finland. I must test them more, but they are a welcome addition to WP7.

Cons

  • Capacitive buttons are a pain. Luckily there is a vibration feedback when touching the buttons, but still they do not feel buttons. And you hit them accidentally all the time.
  • Touch is not as responsive as in LG; every now and then your touch is not detected. Especially annoying when playing Fruit ninja.
  • Still no Wi-Fi tethering. This is unacceptable on a modern smart phone.
  • No DLNA support. With LG I could stream media from my phone to my TV, which is useful to easily show some videos or pictures shot with the device.

Comparison aside overall I would like to see larger screen and better battery on Lumia. There is the Lumia 900 series upcoming, but it will take months before that device is sold in Finland (if ever). I’m confident Nokia has some new devices on drawing board, I just hope they are released before general interest on Lumia fades.

A while ago I blogged about forcing site rendering to be done with Internet Explorer’s latest engine. This feature is very well documented by Microsoft. Not that well documented is that adding the X-UA-Compatible header with value “IE=edge” does only half of the job: it overrides document mode, but not browser mode, and therefore you might end with situation like below - even if you carefully tried to avoid it by placing the meta tag (I know, I just did).

IE drops into compatibility view with now good reason

This is especially problem in an intranet environment, since there is a very stupid default in IE: “Display intranet sites in compatibility view”.

IE's very conservative default intranet settings
IE's very conservative default intranet settings

As you see, by default this is checked and causes all kinds of funky problems in your web pages. Not good. After reading lots of Stackoverflow questions I found that the only way to override browser mode on intranet is to use IE=9 instead IE=edge. I would have liked to live on the edge but there is nothing you can do. Here is the IIS configuration to add the correct header:

<system.webserver>
  <httpProtocol>
    <customHeaders>
      <!-- No need to expose the platform -->
      <remove 
        name="X-Powered-By" />
      <!-- Do not show IE compatibility view -->
      <remove 
        name="X-UA-Compatible"/>
      <add 
        name="X-UA-Compatible" 
        value="IE=9"/>
    </customHeaders>
  </httpProtocol>
</system.webserver>

Update 4.2.2014

Check my newer post for better solution that covers more IE versions.

I guess this is a common problem: you need to have different web site layout for unauthenticated users. In simple cases this is very easy: just use masterPageFile attribute on views. But it gets more complex when you have views that are used in both authenticated and unauthenticated context. Luckily MVC lets you plug into almost anything, and this can be solved with an action filter like this:

using System.Web.Mvc;
/// <summary>
/// A globally registered attribute to change view master 
/// page based on whether user is authenticated or not. 
/// Uses magic strings for the file names, could 
/// be changed to something more elegant.
/// </summary>
public sealed class SwitchMasterPageFilter : IActionFilter
{
    public void OnActionExecuting(
        ActionExecutingContext filterContext)
    {
    }
    public void OnActionExecuted(
        ActionExecutedContext filterContext)
    {
        var result = filterContext.Result as ViewResult;
        if (result != null)
        {
            bool authenticated = filterContext.HttpContext
                             .User.Identity.IsAuthenticated;
            result.MasterName = authenticated ? 
                "~/Views/Shared/Site.master" 
              : "~/Views/Shared/SiteUnauthenticated.master";
        }
    }
}

Remember to register the filter on your site bootstrapper and you are good to go.

Recently I encountered a bug that only some users saw, and which did not reproduce locally on development environment. The setup was:

  • An intranet page has an IFrame
  • …that is dynamically changed to point to an attachment
  • …which is served from MVC action returning FileContentResult

This is a pretty common pattern to open files on browser without leaving the current page. And it worked like charm in all browsers, except on Internet Explorer 8 on testing environment, where IE just showed an error message that the address cannot be opened. IE 7 might be affected too, but I did not test on that.

First suspect was the way IFrame src attribute was changed with JavaScript. For some reason even that simple task is very hard to do in a cross browser manner… anyway, after hours of frustration that did not fix the issue. Fiddler to the rescue (as IE8 does not have internal network listening tool). And to my surprise the PDF document being loaded to the browser actually loaded to the last bit, and only after that IE said that it cannot open the web address. The reason turned out to be pretty logical: when IE is on top of SSL connection and web server sends very strict cache headers, IE removes the document before external program (the PDF reader in this case) can get handle of the file. Actually this is a known issue documented e.g. on Microsoft KB196505 and KB316431, and on []Drupal issue tracker](http://drupal.org/node/163298). Luckily this is fixed in IE 9, and even fixed when running IE 8 mode on top of IE 9 (another proof that the browser modes on IE 9 are not 100 % compatible with the actual old browsers).

Fix

To prevent caching pages I had a hand made MVC no cache action filter attribute (NoBrowserCacheAttribute) which is registered globally and did this:

// Set all the various headers that control caching
var cache = filterContext.HttpContext.Response.Cache;
cache.SetExpires(DateTime.UtcNow.AddDays(-1));
cache.SetValidUntilExpires(false);
cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
cache.SetCacheability(HttpCacheability.NoCache);
cache.SetNoStore();

But IE does not like the Pragma: no-cache header or the Expires: -1 header that yield from the above settings. Here are the settings that fixed the IE issue for me (used these instead of the above settings):

var response = filterContext.HttpContext.Response;
response.Cache.SetExpires(DateTime.UtcNow);
response.CacheControl = "private";

There are a couple of ways to use these less offensive cache settings per action method basis:

  • Allow multiple declarations of the NoBrowserCacheAttribute, and declare it again with some different properties on the file outputting action methods
  • Create a new action filter that is used only on file outputting action methods
  • Create new file content class that changes HTTP headers
  • Signal the no cache attribute that it should be less offensive

The last one was what I ended up doing: I created a static method SetSafeAttachmentCache() to the attribute, and called that from affected action methods; not very pedant but easy and works. The information (bit) was then stored in HttpContext.Items collection, and read from there at the time of writing HTTP headers.

New Internet Explorers have a necessary (?) but annoying feature called “Compatibility view”. I do not need that in my sites since I try to keep my HTML in good shape. Therefore on all projects I want to disable the feature since usually it breaks the layout. Disabling compatibility view can be done by adding a meta tag to HTML head:

<meta http-equiv="X-UA-Compatible" content="IE=edge" >

…or, as it turns out, by adding a custom HTTP header with the same content. This HTTP-header-way is much better for me as I can include it in my default web.config changes I use on almost every web project.

<system.webserver>
  <httpProtocol>
    <customHeaders>
      <!-- No need to expose the platform -->
      <remove 
        name="X-Powered-By" />
      <!-- Do not show IE compatibility view -->
      <remove 
        name="X-UA-Compatible"/>
      <add 
        name="X-UA-Compatible" 
        value="IE=edge"/>
    </customHeaders>
  </httpProtocol>

Update 4.2.2014

Check my newer post for better solution that covers more IE versions.