JerryNixon
commented
6 years ago It hit me that some of you might not have the new Prism.dll so I have included it in the \Temporary folder in the solution. You can find it here: https://github.com/Windows-XAML/Template10/tree/master/Temporary
Please note that this assembly has not been released to Nuget yet. It is also incomplete. As a result, you will find a Prism folder in the Prism.Windows project, too. Those files will all end up in Prism.dll and it will all be in Nuget soon. This will be one of our long-poles to release.
doxxine
tibitoth
weitzhandler
jp-weber
akshay2000
mvermef
mitchcapper
UwpDev
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:
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
NavViewExwill 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
CreateRootElementor anything like that. Everything, timing-wise can be accomplished now inOnStart/Async(). Notice, too, thatOnStart/Async()no longer pass inStartKind. That is becauseStartKindandStartCause, both really nice features of Template 10 are properties ofStartArgs.SplashScreenhas been removedThe 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
BootStrappermakes 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
Typein Template 10 (Prism.Windows) is no longer supported. Can you believe it? Instead, you navigate with a simpleURI, like thisNavigationService.Navigate("MainPage?record=123");and treat it like a browser address.Nested navigation
Navigating to nested pages from a
Toastor aTileis simple, too. Let's say you wanna navigate toDetailsand you want to leaveMainin theBackStack. That's simple. Use thisNavigate("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
PathBuilderclass to help you get the syntax just right. Here's a pro-tip: if you lead your path with a forward slash, theBackStackwill 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
QueryStringparameters from theURLso 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
URLis saved and restored. I think this is an okay trade off and if you want to serialize your objects and put them in theQueryStringyou 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.
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
BootStrapperdoes 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.
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!