I had to dig a little bit to find this. Since not all form factors support multiple windows and tablet mode generally discourages floating windows this is probably buried for a reason, but I wanted to do it anyway so here it is:
var viewId = 0;
var newView = CoreApplication.CreateNewView();
var frame = new Frame();
Window.Current.Content = frame;
viewId = ApplicationView.GetForCurrentView().Id;
ApplicationView.GetForCurrentView().Consolidated += App.ViewConsolidated;
var viewShown = await ApplicationViewSwitcher.TryShowAsStandaloneAsync(viewId);
Hopefully that will save someone some digging.
There are a lot of tools out there and others have posted lists that are handy. I’m going to put my list of common tools here and try to keep it updated every now and then for my own use as well as anyone else who may like to reference it. Feel free to send me more to add to the list.
Code & Text Editors
Visual Studio Extensions
Yes, I went and did it. I converted my blog to MiniBlog. It is much lighter than BlogEngine.NET. I'm liking the HTML5 and it should be fun to tweak it out a bit more too.
I've nixed some things, my old resume, the VS Achievements that only worked in VS 2012, a few other things. I might bring some back later. Still poking around with this. Stay tuned.
- Web front end (static HTML)
- UI views, scripts, and related image files
- Localized strings as JSON files
- Middle tier (WebAPI/SignalR)
- Back end (database/web services)
So, to explain a little about this layout… The front end is all static. The files may be generated by a compiler or parser but upon publish they are static and require no server processing. This allows one to put these files into a CDN whether it is Azure or Amazon for massive scale and economy. Having the localization files as static JSON allows them to be packaged up with the front end and sent along with it. Depending on the configuration and build process these files could even be combined and minified further.
The middle tier is your standard WebAPI and/or SignalR server side code layer hosted on a standard ASP.NET server, usually Azure Web Sites in my case. This tier is basically an API that provides the site with any dynamic actions and information it needs.
Finally, the back end consists of a database used by the middle tier, usually a SQL server of some kind, and any external web services needed by the middle tier. You could lump the external web services into the middle tier but I prefer to think of them as something separate for the sake of organization.
There are some interesting issues you run into when implementing this pattern, including how to handle authorization and security trimming. I generally move the navigation page list into a JSON object that can be generated by the API. In this manner you avoid exposing all your pages to the client even though the templates for those pages may exist in your CDN as public files. All of the security should be enforced on the middle tier so that users cannot perform actions they are not supposed to be allowed to do.
I've found that this model is fast and performs well under load when done properly. The trick is keeping it simple while utilizing all the tooling available to generate the published result. If anyone is interested I could go into more detail about that.