This course is the 4th course in a series called "Prism Problems & Solutions" and continues to build upon the tips and tricks learned in the previous courses in this series. Every production WPF application has some form of navigation in which a user navigates from one view to another within the application. More complex applications have multiple regions in a single view, that can be navigated independently of the other regions on the same view. The problem which arises from this complex architecture, is when you must navigate a view into one region, while simultaneously navigating another related view into a different region of the same view. Things only become more complicated when having to handle navigating multiple related views in separate regions within a single view. By the way, they must all share the same data across these decoupled region boundaries. This course will show viewers how to solve this very complex navigation scenario by using the power and extensibility of Prism.
Brian Lagunas is a Microsoft MVP, a Microsoft Patterns & Practices Champion, Director of Technology for INETA, co-leader of the Boise .Net Developers User Group (NETDUG), board member of Boise Code Camp, speaker, trainer, author, and original creator of the Extended WPF Toolkit.
Course Introduction You're watching this course because you are a Prism developer. You write composite WPF line-of-business applications using the Prism library. Now, you could just be a beginner who just started using Prism if you've watched some video tutorials, read my blogs, watched some of my previous courses. Or, you could be an experienced Prism developer who's been using the Prism library for a long time now. Now, whatever the case is for you, chances are you've hit some roadblocks. You're watching this course because you ran into some problems writing your production application and you need some help figuring out the solutions to those problems. Hello, I'm Brian Lagunas and welcome to my course Prism Problems and Solutions: Loading Dependent Views. This is the fourth course in a series of courses in which I take a problem/solution approach to Prism application development. Now let's take a moment to discuss how each of the courses in this series is laid out. Each course will start out by identifying one or more problems. In order to demonstrate the problem, we will either see a sample or we will write the code necessary to reproduce the problem we are currently focused on. Each problem will then have a corresponding solution. After we have identified the problem and then reproduced the problem we will then discuss possible solutions to that problem. We will then write the code required for a solution to the corresponding problem. Then by the end of the course you should have all the information you need in order to implement the solutions into your production application.
Connecting the Ribbon People really love those ribbon menus don't they? Every company I've ever worked for or helped write an application just has to have a ribbon menu in their application. Chances are you're working on an app right now that needs that ribbon. So when we talk about injecting dependent views this is a great scenario to demonstrate that situation. Hi, I'm Brian Lagunas and in this module we're going to learn how we can connect the ribbon to our Prism application so that we can inject views into it. So, what do I mean by inject views into our ribbon? Well, we have this form okay and then we all know how we can inject a view into a region in Prism automatically. We already know how to do that. We watched the Introduction to Prism course, we know how this works. But now what we want to happen is whenever this view, some view and some region gets injected, we want a tab to automatically be injected into the ribbon control at the top. I mean this is very common. This is probably the most common situation you'll run into with a ribbon interface. And when you switch between different views your tabs will change depending on that view. Well before we can get there, we have a big problem to solve. What is that problem? Let's check it out.
Injecting Dynamic Ribbon Tabs In the last module you learned how to write a custom region adapter so that you could use your third-party ribbon control as a region in your Prism application. Solving that problem alone sets the foundation for the rest of this course. Hi, I'm Brian Lagunas and in this module we're going to continue to build on that knowledge and start actually solving more complex problems that will allows us to eventually achieve our end goal of injecting dynamic ribbon tabs. Before we can do that we actually have a few problems to solve. First, we need to figure out how are we going to associate the RibbonTabs with a view? How are we going to make that connection? Next, we need to figure out okay, what's the mechanism we're going to use to actually invoke the loading of these associated RibbonTabs? Or these dependent RibbonTabs? And next, RibbonTabs have buttons. They have actions that must be performed. So, how do we share the DataContext between the view being injected and the RibbonTab being injected? So that when I click a button on that ribbon it actually invokes a method on the DataContext or ViewModel of the view that was previously injected. Well fortunately, I have a solution to every one of these problems. So let's go ahead and get started.
Injecting Any View into Any Region In the last module we saw how we could extend Prism to give our applications the ability to inject a RibbonTab into a custom ribbon control, based on an association with a view that was being injected into some other region. Well that's pretty cool and all, I mean that's sweet. But in that module we kind of discovered you know what would be really great? Is if this wasn't limited to just RibbonTabs. It would be great if I can inject any view into any region. Hi, I'm Brian Lagunas and in this module we're going to learn how to do just that.
Reducing the Memory Footprint with Caching In the last module we saw how we could modify our custom region behavior to remove that dependency on RibbonTabItems and basically accept injecting any dependent view into any region. While we got all the injection part working, we stopped short of implementing the Remove functionality. Hi, I'm Brian Lagunas and in this module we're going to finish that Remove functionality, but at the same time I'm going to show you how you can reduce the memory footprint by caching those dependent views. So this module's going to cover two main problems. The first problem is performance and memory management. We don't want to keep recreating these objects every single time we inject the same view type right? No. So what we want to do is we want to cache that information. And the next problem we want to solve is once we cache these items, we want to actually remove them from cache because, I mean if you cache them, yeah they're there, but if you don't ever remove them, you're not better off because they're just sitting in memory taking up space. So let's go ahead and take a look at what it takes to implement caching through our dependent views.