The latest version is here. Please read me.

If I am going to ask you to look at the new Template 10, I am going to need to explain some things and I am going to need to document some things. So, for all of you who are watching and waiting, wondering what is happening if anything will ever move with this project.

Thank you

Thank you for waiting. Thank you for all of you @Windows-XAML/template-10-developer-community who have faithfully helped developers asking questions when I have not found the time to check the Issues on this site. And, thank you for what we are about to do together. I think you will like what is happening.

Prism.Windows

You might already know that Prism is the framework built by Patterns & Practices to enable XAML development on the WPF platform. You might also know that Template 10 has taken a lot of leads from that framework, and their subsequent Prism for Store Apps framework. It’s true.

What you might not know is that the Patterns & Practices team is no longer a thing at Microsoft. And the stewardship for Prism for WPF was given to Microsoft MVPs like @brianlagunas who have taken Prism for WPF and reinvested it as Prism for Xamarin Forms. This work has been very successful.

One family

I’ve been talking about it for years, but I’ve finally worked out the details with the Prism for Xamarin Forms code base (even introduced a few changes) so Template 10 can use their namespaces and interfaces. From this point forward, there will be two libraries: Prism.Windows & Template10.Extras.

.NET Foundation

Someday it might happen that the Prism.Windows library (only that project) leaves this repo and lands in the official Prism library repo. At that point, that code base will enter the .NET Foundation, and all of the navigation born of Template 10, and the candy adopted from Prism for Xamarin Forms will be formally recognized.

Another Prism.Windows?

You might be thinking: Isn’t there already a Prism.Windows? There is. But that code base is rudimentary and abandoned. This Prism.Windows library is the fully compliant, and written by the time-tested copy/paste approach from the original Template 10 library. It’s all worked out on the back end.

Windows Template Studio

Does this mean Template 10 will show up in the Windows Template Studio? Well, sort of. The fundamental part of Template 10 that has always been the bread and butter is what is now in the Prism.Windows library. Once we have that tested, proven and delivered. I think you will see it as a WTS standard. Yes.

Community Toolkit

The confusion between what is Prism, what is the UWP Toolkit, what is WTS, and what is Template 10 can finally be erased. I will continue to stage Template 10 classes and controls for the UWP Community Toolkit, whenever they appear in the Toolkit, I will remove them from Template10.Extras.

VSIX Toolkit

Template 10 will continue to be a series of project templates in the Visual Studio Gallery. Will it also be in the Windows Template Studio? Yes. But the full-on implementation of features, including those of the extras will be demonstrated in the templates. I expect there will still be three.

November Update (10586)

You will be pleased and possibly surprised to learn that Prism.Windows is fully compatible with UWP apps all the way back to November Update 10586. This means Template 10 Navigation (aka Prism.Windows) is available to, basically, everyone. You will see that extras broken up like this:

1. Template10.Extras.10586
2. Template10.Extras.16299

The UWP number in the project name indicates the required version of UWP to support this. As a result, most of Template10.Extras can be in 10586, while FCU-specific features like NavViewEx will only be available in 16299. This means, if you want to support older UWP platform versions, just leave out the version of Template 10 that do not apply to you. Make sense? I love this, too.

Client project

There is only one working UWP project using this new library, and you can find it in VSIX\Prism.Windows (project) or just open the SLN file in the root. This demonstrates a lot of features, and is not (of course) the Basic or Minimal project templates we will ship to the gallery. This is might be called Advanced.

NavigationView

With Fall Creators Update came the new XAML control, NavigationView. I have created Tempalte10.Controls.NavViewEx which inherits from the NavigationView and implements several improvements as well as an awareness to Template 10 navigation.

Changes to BootStrapper

The BootStrapper, as you know, is the Application drop-in replacement. Many of the methods you might remember in the old Template 10 have been removed. Some have been simplified. More importantly, there are sibling async and non-async methods to everything now. Here they are:

There is no longer CreateRootElement or anything like that. Everything, timing-wise can be accomplished now in OnStart/Async(). Notice, too, that OnStart/Async() no longer pass in StartKind. That is because StartKind and StartCause, both really nice features of Template 10 are properties of StartArgs.

SplashScreen has been removed

The complexity of placing the Extended Splash at the right time cannot be overstated. I have removed this capability and demonstrated the three lines to show a custom Splash in the sample project. The logic is the same and the restructuring of BootStrapper makes the behavior basically identical.

Dependency Injection

It is 100% possible to use this without using MVVM. That was important in every iteration of Template 10. It is also 100% possible, and simple, to NOT use Dependency Injection. That being said, MVVM and Dependency Injection are fundamental to Prism.Windows, and developers using DI will love it.

Changes to navigation

Remember how Silverlight used strings/url to navigate? Navigating by Type in Template 10 (Prism.Windows) is no longer supported. Can you believe it? Instead, you navigate with a simple URI, like this NavigationService.Navigate("MainPage?record=123"); and treat it like a browser address.

Nested navigation

Navigating to nested pages from a Toast or a Tile is simple, too. Let’s say you wanna navigate to Details and you want to leave Main in the BackStack. That’s simple. Use this Navigate("MainPage/Detail?record=123"). If you wonder if you can pass more than one parameter or if you can pass them to all the pages all the time, you can.

PathBuilder

Of course getting the syntax correct will be tricky. Because of that I have introduced a PathBuilder class to help you get the syntax just right. Here’s a pro-tip: if you lead your path with a forward slash, the BackStack will be cleared before navigation starts. This class is optional. But handy.

No more serialization

In the old Template 10 every parameter had to be serializable. Ack, I hated this. Most of you did, too. This was the start of endless problems for me to chase. In Prism.Windows the only parameters are the QueryString parameters from the URL so there is no serialization anymore. It’s a dream come true. Which leads to the next thing…

SessionState is gone, too

Passing in-memory objects is still a requirement sometimes. We used to use SessionState, but I have removed SessionState from the new libraries because there is a <string, object>[] parameter property on Navigate you use like this Navigate("MainPage", ("MyObject", UserObject)); And, yes, that is a tuple. You will need to reference ValueTuple in projects pre-Fall Creators Update, since it wasn’t included.

The caveat here is that when you suspend and resume, only the URL is saved and restored. I think this is an okay trade off and if you want to serialize your objects and put them in the QueryString you still can. That just feels like it will be an edge case now.

Changes in ViewModelBase

ViewModelBase in Template 10 is a crowd favorite. No question about it. To understand how it has changed, let’s start, first, by looking at all the interfaces it implements. If it seems like a lot, remember there are async and non-async methods, now.

Prism MVVM only

There is no MVVM implementation in Template 10 anymore. This means the Template 10 RelayCommand is gone and we inherit from Prism, which has everything. I mean everything. Whatever you thought you needed with MVVM is already built and awesome, and standard in Prism.Windows.

Note: if you want to use another MVVM framework, the ViewModelBase is in the Default implementation, meaning it is simple for you to override. You ren’t required to use the Prism MVVM framework, but it is the default framework implemented.

Custom ViewModelBase

The out-of-the-box ViewModelBase gives developers a ready-to-go implementation of every scenario. I prefer overrides from interface implementations. That said, your scenario might not need many implementations and you might not believe me when I tell you the compiler will optimize unused overrides. Fine. Creating your own is as simple as possible.

Prism’s event aggregator

A while ago I taught a Microsoft Virtual Course on XAML and stepped through including the Patterns and Practices PubSubEvents nuget package. The good news is, Prism.Windows depends on Prism.Core and Prism.Core ships with PubSubEvents. That means you get messaging out-of-the-box.

OnNavigatingFrom no longer returns boolean

As part of the alignment with the Prism framework, we have removed the return type of OnNavigatingFrom which was used to stop navigation. This actually caused all kinds of problems for developers. Conveniently, Prism had CanNavigate/Async which is now fully supported.

GestureService

In Template10.Extras: BackButtonService is gone, as is the KeyboardService. They are both replaced by the new GestureService which handles more scenarios, including the Back/Keyboard as well as a flexible approach to raise events on a per-view basis with the new GestureService.GetForCurrentView().

Some missing things

Right now, I have not added in WindowsWrapper, DispatcherWrapper or ViewWrapper. I’ve also not yet implemented NavigationService.Open() yet because I am still a little confused on the best approach and am reaching out to the team to clear things up there. Anyway, if something CRITICAL is missing, I would love to hear your take on what should be added back to Template10.Extras or Prism.Windows.

Stacked projects

It’s important to notice that BootStrapper does not come from either Template10.Extras or Prism.Windows. Instead, it is a product of Prism.Windows.Default which uses, in this case Unity Dependency Injection. It could just as easily be your favorite container.

You can help, and please do

You should notice TONS of the stuff is gone. Most of the classes, all of the samples. Those are going to need to be built up again. But this is the code base. I’ve stared at it for days now and I think the changes to come are trivial and I welcome your Pull Requests to Master.

1. Load the Solution
2. Run the Project
3. Test some stuff
4. Make some changes
5. Try out navigation
6. Try out suspension
7. Test the splash

If you are wondering if I am accepting PRs, the answer is yes.

Documentation

Okay, so, I don’t know what to do with the current Wiki. I think what I really need is to create a hierarchy that includes Template10, Prism.Windows and Template10.Extras. I don’t plan on stopping support or updates to the old Template 10 for a while. And, I don’t want to, either. But, I would also like to start documenting somehow. It so easy using that Wiki instead of a PR for everything. Not sure what is best but I would be open to any suggestions.

There are problems to solve, but I’ve solved many of the big ones with this super PR!

Again, thank you for continuing to support Template 10. I hope you can see the vision. I hope you can see where we are going. I hope you can see the difference between Windows Template Studio, UWP Community Toolkit and Template 10. I know one thing for sure, Template10.Extras is going to continue to be a lot of fun. And, once we stabilize, there are going to be a lot of samples to write! Rock on, C# developers. Rock on, XAML developers. As UWP starts to show up in ore and more enterprises, I will also need to consider if validation should be inside Extras, too. Again, just thinking. Cheers!

[mvermef]

Poke the dead horse more.

[JerryNixon]

This is not production ready because we are waiting for, at least, @brianlagunas to update Prism.Core so we can reference it reliably without stubbing them in Template 10. @totht91 is 100% correct. It is also important, @obscuresystems, for you to recognize that it was written over the past 6 months and review 1 was only available this week. That means, testing is far from what I think you should use for production. Still, I would welcome you look at the library and try to use it, pushing me to enhance it or fix it so we can approach production.