[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]

“AllowDomainPicturePassword”=dword:00000001

“AllowDomainPINLogon”=dword:00000001

If you don’t know how to make this change, it might be a good idea to skip this tip!

Related posts:

1. BUILD Keynote Day 1 – Windows 8 Experience

Related posts:

1. Fix for Expression Blend 4 crashing on startup
2. Visual Studio 2008 SP1 hotfixes for WPF

It doesn’t seem like a great idea to go into a series of posts talking about Metro-style apps without briefly defining the core components that they are built on.  The most fundamental piece of the puzzle for these apps is Windows Runtime, or WinRT for short.  WinRT is probably best described as an unmanaged, native API that can be leveraged from many different languages via a mechanism called language projection.  Read more to find out some more details about how WinRT works.

How does this thing work? (in a nutshell)

Metadata

Since WinRT is designed to be a native API, it can’t contain metadata directly in its code.  To get around this limitation, WinRT stores its metadata in .winmd files that are encoded using the ECMA 335 metadata format (CLI).  You might recognize this strategy if you’re a .NET developer since this is what .NET does.  This enables things like reflection to be possible in WinRT.

object-oriented type system

Built on the metadata system is an object-oriented type system.  In this type system can be found a lot of things that could be found in the .NET framework.  There are also some new additions.  I won’t go into details of what is or isn’t in the WinRT APIs in this post as a) there are a lot and b) I’ll be going into a lot of them in more detail as the series progresses.

Components

Any class that is built to target WinRT is called a WinRT component.  Any WinRT supported language can be used to write a WinRT component.  Since it is built upon the metadata structure, a WinRT component written in one language can be easily used from another language.

What languages are supported?

Currently, the languages that are supported are C++(WRL and C++/CX), C#, VB.NET and JavaScript.  Technically, any .NET language can be used for WinRT development but only C# and VB.NET are supported for now.  Language projections can be created to expose the WinRT API to other languages in the future.

Give it a try

If you haven’t tried it out yet, head over to the Windows Dev Center and download the Windows 8 Developer Preview.  Then, get started with Metro style app development. You’ll need to choose whether to use XAML or HTML5 to build it.  I’ve got some tips to help you decide.

Related posts:

1. Metro Snack #1: Choosing XAML or HTML5 for Windows Developer Preview apps
2. Metro WebView Source and HTML workarounds

SOPA and PIPA are very dangerous laws that inherently break the way the Internet works. Please join the cause by signing the petition or calling your Congressmen.

No related posts.

Which should you choose?

XAML and HTML5 applications in Windows 8 both use WinRT as a foundation and by virtue of this offer an almost identical set of features to the developer. However, if you are developing your Windows 8 user interface during the Developer Preview there are some important things to consider. Ultimately, the decision is yours and you should choose what you are comfortable with given the current limitations. The point of this post is to help you make an informed decision given what we have available to us now.

Language Familiarity

This one seems fairly obvious but there’s going to be a learning curve if you currently do not know XAML or HTML5. This is mitigated somewhat by the fact that you are going to be learning a lot of new things (WinRT, Windows 8 Metro Style App flow, etc.). I would treat language familiarity as a starting point for your decision if your application is fairly simple in nature. However, if you are building a new app that does not leverage an existing codebase I would strongly consider basing this decision based on all of the factors described in this post.

Excellent Expression Blend Support for HTML5 Apps

The version of Expression Blend that is included with the Developer Preview has wonderful support for creating Metro apps using HTML5. As you build your user interface, the changes will be reflected immediately using a live DOM. There is also an interactive mode that will allow you to test your application without even running it. The CSS editing features in Blend are also top-notch. From a UI design perspective, this makes HTML5 Metro development very attractive.

No Expression Blend Support for XAML Apps

While the Expression Blend support for HTML5 apps is fantastic, it is nonexistent for XAML. The Blend team spent a lot of time making this version of Blend work with HTML5 but unfortunately it appears that did not leave enough time for XAML support. XAML developers/designers that want to use Blend to create animations, brushes, etc. will have to use Blend 4 until this support is added.

Visual Studio Designer for XAML has major bugs

For me, this has been the biggest reason to potentially avoid XAML during the developer preview. I am not sure exactly what causes it, but every project I have attempted to work on so far has gotten into a state where the Visual Studio Designer will no longer load my XAML files. This is a fairly significant problem since there is no Expression Blend support for Metro apps using XAML in the Developer Preview. This leaves designers and developers with very limited tooling support for the UI. For a platform with a strong focus on design, this is not an ideal situation to be in.

My personal conclusion

The conclusion I’ve reached at this point is that learning HTML5 and WinJS is probably a good investment. The tooling story for XAML Metro apps right now is somewhat frustrating and leads to more headaches than seem necessary at this point. I am much more familiar with XAML-based user interface coding than HTML-based so this is a difficult pill for me to swallow. I am hopeful that the beta in February will bridge a lot of these gaps but, just in case, I’ve decided that any applications I develop during the Developer Preview will be developed using HTML5.

Related posts:

1. Metro WebView Source and HTML workarounds
2. HTML5+CSS3+jQuery: Learn with me

In the process of writing my first Windows 8 Metro style app using C# and XAML, I came across some limitations of the current WebView control’s implementation.  The flow for the feature I was working on is fairly simple:

1. Content for a webpage is displayed in a WebView (using the WebView’s Source property).
2. User browses the page until they find something they want to save.
3. User clicks a save button and the app parses the information into a readable format for saving in the app’s storage.

This is a pretty straightforward concept and I thought the implementation would be just as intuitive. Judging by the similarity of the WebView control to the Silverlight WebBrowser control, I went about implementing this functionality as I would have for Silverlight.  I set the WebView’s Source property to the initial Uri where I wanted the browsing to begin.  I wired up a test button that I thought would kick off the parsing process.  That’s when I started to run into problems.

The first problem – No SaveToString()

My initial attempt at the parser was based on the premise that I would have direct access to the HTML that was being rendered in the WebView control.  Initially, I thought the WebView would support something similar to WebBrowser’s SaveToString() method which returns the HTML being displayed currently as a string.  It doesn’t.

The second problem – Source doesn’t update

Since I didn’t have direct access to the HTML directly, my next attempt was going to be to pass the Uri for the content that’s currently being displayed.  Again, in the Silverlight WebBrowser control this would be as simple as using the Source property which updates as the user browses inside the WebBrowser control.  Unfortunately, the Metro WebView’s Source property does not update as the user browses and instead locks itself to whatever it was initially set to.  Stymied again.

Workaround #1 – Retrieving the HTML using InvokeScript

Thankfully, the WebView does support a handy method called InvokeScript which allows you to run a script on the page that is being displayed.  Combining that with the JavaScript eval function, we can call arbitrary JavaScript code on the content.  This JavaScript snippet will allow us to get the HTML that’s being rendered:

document.documentElement.outerHTML;

All we need to do is call that script on the page using InvokeScript() and it will return the HTML in a string:

string html = webview.InvokeScript("eval", new string[] {"document.documentElement.outerHTML;"});
Parse(html);

Workaround #2 – Keeping track of the Source

I still needed to solve the second problem because the image links in the HTML were relative.  I still needed access to the Source Uri.  It turns out there’s a slightly non-intuitive way to keep track of this by wiring up the WebView’s LoadCompleted event which fires when top-level navigation completes and the content loads into the WebView control.  The NavigationEventArgs in the LoadCompleted event handler contains a Uri property which represents the Uri that was just loaded in the WebView.  The following snippet will fetch the Uri:

Uri source = null;

webview.LoadCompleted += (s,e) => {
     source = e.Uri;
}

Conclusion

We are still in the very early days of Windows 8 Metro style app development and there are a lot of rough edges in the SDK and documentation (more in the XAML side than the HTML5 side but more on that later…).  Some things will simply not work the way we expect them to and we will have to adapt and work around them until they are hopefully fixed in future releases.

No related posts.

From the post:

I am sitting here thinking about that end-user-programmer-guy. I guess this holy API should seek to provide exactly what this guy wants. The trick is knowing what he wants.

While I don’t agree with the entire blog post (in particular, there’s way more to API design than just naming), I do believe James has partially nailed the essence of what makes API design difficult.

At Infragistics, we have a design tenet that states we will optimize for the 80% case while still remaining flexible enough to accommodate the other 20%.  What this means is, in 80% of the use cases for what we are designing the developer should be able to use it without consulting product guidance.  This requires a lot of research to determine what the 80% case is, but in the end the result is a product that is easy to use most of the time.

That’s not to say that we don’t care about the other 20%.  We just don’t design for that first. The basic idea is: the more common it is, the easier it should be.  On the flip side: the less common it is, the more difficult it can be.

No related posts.

So, if you have something productive to add to the conversation, tweet at me (@brentschooley) or find me on any of the social networks listed at the top right of this site.

No related posts.

If you’re in the market for a new reporting tool or just feel like your current one could be better, you should definitely check out NetAdvantage Reporting.

No related posts.

No related posts.