You could download some free open sourced sample site, or can even hammer out a simple catalogue and ordering system via code if you’re capable of doing so.

But the thing is that after the customer has paid for their order then comes the REAL WORK, it needs to get the PHYSICAL item to be delivered to the customer and that’s not something the website can actually do!

“How hard can it be to package something up and send it to the post office?” You might ask? The answer to this question is determined by the scale of operation. If it was just a housewife trying to sell some things through a blog, then yes it’s a simple matter of her logging on to check on pending orders, pick all the orders HERSELF, pack all the orders into boxes HERSELF, send it to the post office HERSELF, and then update the order status with tracking number HERSELF. Then yes, it’s not complicated at all since it’s all done by ONE person, and only ONE person needs to know about the state of the order.

Now imagine if it’s an online store of a public company, when an order comes in, the Order Processing department would verify the orders, send it to the Storage Warehouse to pick the items in the order deliver it over to the Delivery department for actual packing and delivery then update the delivery status of the order. All this while that this is happening, the Customer Service department must have enough visibility of the process to be able to answer any customer enquiries that pop up.

Different companies and organizations would have different workflows and auditing requirements than the simplified scenario which I listed above, the most important thing to understand is that the work required to build an Online Store Website ISN’T limited to just making a website which the customer can buy stuff from. Depending on who’s running the online store, the backoffice to support the entire process might turn out to be just as complicated as the online store website itself!

If you’re a web developer, and you’ve been making web sites for mobile devices you’ve no doubt come across using this META tag to control the width of the browser’s view window.

<meta name="viewport" content="width=800" />

Given the snippet above, the window would be constrained to a pixel width of 800 pixels. If you don’t know how this works, basically it’s like resizing your desktop browser window to 800 pixels, since the user can’t do such a thing on a mobile phone browser you as the content provider would need to do it.

In any case, pretty much all modern mobile web browsers would support the use of this to control the viewport window width. And of course, so does Internet Explorer 10 for Windows Phone 8. Kind of…

It’s not that IE10 doesn’t support the use of the viewport meta tag. But rather it’s limited in what can be supported. From my testing you are able to set the viewport width to these values using the viewport meta tag:- 240 (Will be resized to 320), 320 and 480.

Setting the width to any value other than those mentioned would result in the default width of 1024 to be used, and that’s not what you want!

So? Is all hope lost if you need to set a arbitrary width value for your viewport in IE10? Is it time to add to the #iesux hash tag archive?!

Nope.

While we can’t have full control over the viewport width using the META tag, we can use another method which is through the use of the CSS device adaptation features. Basically you just need to include in your css file somewhere a directive like this.

<style type="text/css">        
    @-ms-viewport {
        width: 550px;
    }
</style>

No no no, put your pitch forks back down this is not a Microsoft only feature, the MS prefix is just to indicator that it’s still a vendor specific extension like how box-shadow and border-radius used to have it. See.. here’re the W3C specifications for this.

Anyway, with this you will be able to set the viewport to any value which you want. Therefore when you want to set a viewport width and make sure it works with all mobile browsers you would make your page contains something like this.

<meta name="viewport" content="width=550" />
<style type="text/css">
@-ms-viewport { width: 550px; }
</style>

Anyway here are a few more notes regarding this viewport setting.

When doing testing on your Windows Phone with different viewport values, don’t just REFRESH the page whenever you update the viewport value. Usually the phone doesn’t respect the new viewport value when you just do a refresh, best to close the tab and open the URL from a new tab.

Internet Explorer 10 on Windows 8 (not phone, the actual PC version) in both Metro and Desktop modes will actually respect the @viewport value. Just remember that the Metro IE has it’s zoom level turned up a bit by default. The fact that a PC browser actually respects the @viewport directive could lead to some interesting applications.

Finally I find it funny that the compatibility repository Can I Use doesn’t seem to have an entry for @viewport wonder if it’s because it’d bad to show MS actually being ahead of everyone else in supporting something.

Learnt of this 2D map editor tool called Ogom Editor, saved me a ton of time of coming up with something of my own design! Highly recommended

There was a grid of blocks, a purple square and an orange square.

Today's post starts off with an interactive exercise, first download the sample project file and run the program in there. The program looks like this.

When you've run the program, perform a simple exercise, move your mouse in and out of the extra large buttons and note what happens.

The buttons are essentially a ViewBox control containing the XAML which makes up the buttons. The viewbox is then contained inside a grid and scaled to the grid's size.

Code is tied to the PointerEntered and PointerExited events of the Viewbox which basically just changes the background color of the Grid which contains it. If you haven't already run the program and then move the mouse in and out of all of the buttons, do so now.

After running the program and trying out what I mentioned you should have noticed the following problem, given that a button looks like this.

• Button 1 didn't seem to respond to mouse events in the green area
• Buttons 2 and 3 did.

So what's happening and why the difference in behavior? Let's take a look at Button 1's XAML construction. (Behold my l33t diagraming skills!)

Note that it is made up of two vector paths (the Stroke and the [Path])

Now let's take a look at Button 2's XAML construction.

Compared to Button 1, there's an extra Ellipse element (the green circle) called hitAssist which is sitting behind the blue circle and 'i' which makes up the button.

By now you should have figured out why Button 1's mouse events where behaving so weirdly, for Button 1 the only elements which have a physical appearance are the circle and the 'i' and that's exactly what triggers the mouse events.

Whereas Button 2 has an additional hitAssist element which fills up the empty gap between the circle and the 'i' and hence the mouse events are triggered as if they're one consecutive element.

"But what about the Grids that are containing the strokes? Wouldn't THEY trigger the mouse entry and exit events?" But they don't! In XAML you'll use a LOT of Grids, Panels and Canvas to layout your elements, you do NOT want every single container to simple fire mouse events!

So how DOES an element qualify for mouse interactivity? Well, I gave a hint just now already. It must have a PHYSICAL appearance. In more easy to understand terms... Make sure the element has a Background Brush assigned to it. The moment a background brush is assigned to an element it will start participating in mouse events because the mouse is able to know if it's running over an element's background brush or not.

So now we know that what we want to do is to fill up gaps in our interactive elements so it makes more sense when users are using them. "But I don't want my sleek outline buttons to have an ugly unadaptable background color!" you say. Well, that's why there's a Button 3 in the sample.

Construction wise it looks just like Button 2, except the Ellipse element that's covering the gap is called hitAssistClear and it's can't be seen. "But didn't you just say that only elements which have a physical appearance can have mouse events?" Because it IS still physically there, it just has an Opacity property value of 0%. It's like a really really really clear piece of glass, you can't see it but it's there! Just remember:-

Any element that has a Visibility property value of Visible will participate in mouse events even if Opacity is 0%. Setting Visibility to Collapsed will remove it from mouse events too. And just in case you didn't realize, there's a property on every element called IsHitTestVisible setting that to FALSE will remove it from mouse events too.

And that is what the name of this whole notion of seeing wheter the mouse is over an element or not : Hit Testing

It's something that I feel all XAML developers and designers should know about, yet I don't really see anyone talking about it much. If you think this is not important, what if the button was only this small?

Notice the hit area of 'i' is now merely a few pixels, do you want your users to have to pixel hunt in order to click a button? Would YOU like to pixel hunt in order to click a button? This experience gets WORSE if your user is using touch to navigate your app!

ps. The button icon you see was created using the TOTALLY EXCELLENT Metro Studio by SyncFusion. Hmm... I should submit a feature request where they insert a hit test element into their XAML output.

At some point when you're developing a Windows 8 App you probably realized that if the app is run on a tablet form factor device you'd want to freeze the app orientation in either landscape or portrait display modes like you'd do in a Windows Phone app. So what you do in Visual Studio 2012 is that you double click on the Package.appxmanifest file so you can start tweaking the manifest settings for your app, in particular is the Supported rotations section.

Since you want your app to only support landscape mode, you check both landscape modes. Then you decide to test if this works, so you fire up the simulator, and rotate it, but instead of being locked in landscape, your app still rotates to potrait mode.

This doesn't work because the simulator doesn't accurately simulate the hardware rotation, as mentioned in the documentation (look under the change device orientation section)

Since that doesn't work, you try to manually rotate your screen using Windows Mobility Center (Windows + X, then select Windows Mobility Center)

And STILL your app doesn't stick to landscape orientation!

So what exactly is wrong?

The problem here is that the rotation preference setting of the app is only enforced on a Windows 8 system with a supported HARDWARE ACCELEROMETER.

Which means unless Windows knows how the system is orientated through the means of a supported sensor, it'll never attempt to switch to the app's preferred orientation.

So you shouldn't need to worry that your preferred orientation setting isn't working, it'll work on any hardware that is properly designed for Windows 8. How do you deal with people who manually rotate their screens using Windows Mobility Center then? Well... did you know you could rotate your screen using Windows Mobility Center? Did you even know that there was a Windows Mobility Center? It should be safe to assume that if someone knew enough to manually rotate their screen display, they'll know enough that not all apps run fine in both portrait and landscape orientations.

So there I was writing my first application for Windows 8, I had to call a web service sitting on a server which had to be connected through HTTPS, but because it wasn't a production server the certificate was self signed and thus is considered to be an invalid cert. No biggie I thought, with all my years of .Net experience I knew that all I had to do was fiddle with the System.Net.ServicePointManager.ServerCertificateValidationCallback method, as mentioned here.

Imagine my surprise when I realized that the class doesn't exists when you're writing a .Net app for the Windows Runtime!

Trying to look for other solutions also came up empty, it was then which I realized that what I needed to do was to allow the application to get a certificate which ISN'T invalid. What I needed was a web proxy which could give the impression that the remote certificate was actually valid.

What I needed... was Fiddler!

So first download Fiddler4 (Because Windows 8 comes with .Net 4.0) from the download page.

After installation and running the program enter Fiddler Options by selecting Tools->Fiddler Options from the menu bar.

After which head into the HTTPS tab and check Decrypt HTTPS Traffic

You'll be warned that you're about to install a wild card certificate on your system. Shown below is one of the many warning screens, you'll have to answer YES to ALL of them.

After the certificate is installed, look back at the options window and check Ignore Certificate Errors. This will make Fiddler not complain about any invalid certs.

Fiddler is a web proxy, which basically means it sits between your machine and the internet so you can monitor the web traffic your PC is making as long as the program is setup to use the system proxy. If you don't know what this implies then just keep Fiddler on only when you're doing development, and turn it off once you're done.

For more information about using Fiddler to assist in Windows 8 development out this post.

So here’s the scenario, you have 2 links below. In Internet Explorer 8 and above right click on both of them and check out the difference in behavior.

Link One

What you should see is that for Link One you’re able to see the options you expect to see when right clicking on a link, which is the usual Open In New Window, New Tab, etc. etc. options. But for Link Two you don’t see such options.

This bothered me for quite a while wondering what was causing this problem. Finally after some poking around I figured it out. The HTML for Link One looks like this.

<a href=”http://www.windowsphone.com”>Link One</a>

Nothing out of the ordinary there. Now let’s look at Link Two.

<a href=”http://www.windowsphone.com”><div>Link Two</div></a>

Notice that there’s a DIV tag enclosed in the A tag. And it seems like this causes IE to decide not to show the typical right click on link options. Any element that has a CSS display attribute of BLOCK or INLINE-BLOCK contained in an A tag will cause IE to NOT display the typical link context menus on right click.

Definetly a bug. Doesn’t seem to be anyway around it. So… just remember this behavior and not use BLOCK tags inside A tags. The only other fix for your page is to force compatibility mode I guess, since pressing the compatibility mode button in IE8 fixes the problem. But that just introduces other problems.

I was preparing my Silverlight XNA hybrid application in Windows Phone 7.5 Mango presentation demo project for TechInsights 2011 (Sign up now!) When I hit a problem, The ContentManager  threw an exception whenever it was time to load an asset. Specifically it was a KeyNotFoundException.

After some digging around it seems like there's a problem with the project template itself. (!) The gist of it is, in the App.xaml.vb file. Under the InitializeXNAApplication function. You'll find the line below :-

If obj Is GetType(IGraphicsDeviceService) Then

This line is supposed to find an obj that implements IGraphicsDevicesService and add it into a list of services. But the code is wrong, this line needs to be changed to:-

If TypeOf obj Is IGraphicsDeviceService Then

In order to work properly. This ONLY affects the Visual Basic Windows Phone Silverlight And XNA Application project template.

The main question I'd like to ask is how the heck did this error make it out to the release SDK? Since I do remember everything working during the CTP. Also, even Microsoft's own VB code samples for this project type uses the correct method call.

While working on my little XNA sample I bumped into a little problem. No matter how much time I spent on it, I can't draw for the heck of it. And not to mention, the total time it'd have taken me to draw a set of sample sprites might have allowed me to finished another code module on the sample.

In a suddden eureka moment I picked up the Asoblocks I bought a while back, put together some models and then took this photo.

The individual elements were then color keyed so I'd have a pretty nice template to work with.

Then it was a matter of resizing the image and adding some extra details and viola…

Definetly better than me trying to draw the whole thing!