So far I have been creating Silverlight apps with all logic crunched into a single xap file. But as the application grows in size,
I seriously think I should break my Silverlight application into smaller multiple independent applications.
I would like to know how others solve this increasing size problem??
If you're looking to make some changes to your application, by refactoring it and splitting out parts, consider all of these.
Custom controls get their own control assembly
Definitely create control assemblies for any custom controls you develop. Not only do you get the benefit of self-contained controls, and optional use in your current and future projects, you can
take advantage of default control styles
use the cached assembly feature with them
share components with other projects
invest in your core code and controls, instead of investing in cleaning up application logic (if you're using static or style analysis, for instance) - spend your time where it will make the most impact
Consider dynamically loading new assemblies
There are some methods available for dynamically loading additional code into your app domain, it may be possible to abstract out less-often used parts of your app, and use this to load in those components. This is a more complex and involved app, but it can improve start-up performance.
It'll take time to split out the code into other assemblies when you're looking at a large application, and testing it can be a challenge. But you can end up with "sub-pages" and parts of your app being loaded only as needed.
Taking the time to design a system to load in new functionality and parts of your app, and architecting this framework, can take time to do right. This typically is using AssemblyPart to load a new assembly that you can reflect into and instantiate new objects from.
Merged Resource Dictionaries
Resource dictionaries can allow you to store styles, control templates, and other resources outside of pages, and outside of your App.xaml.
Cached Assemblies
Once you move to Silverlight 3, you can use the cached assemblies feature to store individual assemblies outside your .Xap, alongside, on your server - and as a bonus, those assemblies will be cached on the machine for quite some time.
A resource diet
Are you really using all of your graphic assets, XAML, controls, string resources, etc., that are stored inside your XAP file? Audit it from time-to-time and make sure you're getting the most bang for your byte.
A splash screen
If you're simply trying to improve the performance (download time) for your application initially, consider creating a splash screen. The Silverlight Toolkit samples have one - it's a simple Silverlight page that will load and display while your .Xap downloads.
Remote graphics
Instead of including image resources right inside your application/XAP, move your images to your CDN or server, so they can be loaded only as needed. This is often a nice and quick win.
Simplify your app
Make sure you actually need it to be XAML-heavy, graphic-heavy, etc. Maybe it can be simplified!
You should distribute your Silverlight modules using PRISM or MEF frameworks.
Visit http://mef.codeplex.com/
Related
I have a growing WPF solution where I have multiple projects within.
I have one main "module-selection" project that acts as the entry point when launching the application. From this one I typically load one or more of the "module" projects.
I have several "module"-projects that are quite big and are currently set up as class libraries.
At the bottom I have a common resource project where I keep and maintain all resources that are common for all the modules (typically themes, colors, control styles)
When everything is in one project you can define your global resources in the app.xaml. When you have resources in class libraries I believe this works as well run-time, but not design-time. The workaround is linking in the resources from every control or page that needs it. This latter solution works, but will then spend time loading the resources everywhere you define it and this impacts performance significantly.
What is the best practice to achieve dividing your LOB application into multiple projects while maintaining global resources in an proper fashion?
I'm trying to figure out what would be best solution to the problem I'm facing. I have a Silverlight application which should be composed from different modules. I can use Prism, place regions and load modules and fill regions with loaded modules but this is not enough in my situation. Here's what I want to accomplish:
For most views that gets loaded from different xap files, I should place an element somewhere in the shell, which will perform navigation to the dynamically loaded view.
That element (which links to dynamically loaded view) should support localization and should have dynamically assignable data templates, different module links should have different content/data template (I'm thinking writing data templates in xaml files on the server and reading them from silverlight via XamlReader, maybe there's a better way?).
Uri mapping and browser journal should work with navigation. Silverlight default navigation mechanism better suits my needs than the one found in Prism.
The architecture should support MVVM.
I think thats all. I just couldn't think of a good architecture which will satisfy all my needs. Any help would be greatly appreciated.
I do not know of a single product/solution that would cover all your requirements, so here are some comments on each:
If one area of the shell has a region that supports multiple items, you just register a control of type link/button etc with the same region name in each module. For example we register views based on the Telerik TadRibbonTab (instead of UserControl) with a region named "views" which is a RibbonBarTab with a region named "views". Every module then adds its its own button to the list. You can do the same thing with any multi-item container.
Localisation is a completely different issue and can be solved in a number of ways. See my answer here: Load Resources ".resx" from folder in Silverlight
A custom navigation mapper can be made to behave like the standard one, without messing up the support for Prism regions. The one we created encodes GUI information such as current selections (current view and item selections etc) into the URL. That means we are in total control of the state and the URL controls the state.
Hardly anything stops you using MVVM as that is one small feature for separating views from code-behind data.
I will be interested in what other solutions are proposed as we are always looking for new ideas too.
I have a PRISM based silverlight solution under source control. In regards to theming I have a project for each theme, for example 'Theme_Summer', 'Theme_Winter' projects. In reality there may be over 30 of these theme projects. Each theme project contains a selection of resource dictionaries to hold the styles etc along with the images, sounds etc that are required.
Each of these projects also has a Main.xaml merged resource dictionary that ties together all the resources in that theme project. My main application then just uses the Main.xaml resource dictionary from whatever theme project it needs to use.
The problem I have is I need these 30 or so themes in my solution so they remain under source control and manageable but they all get compiled into the XAP which is obviously not good as the app gets deployed somewhere and only requires 1 theme.
My question is really what do people think would be a suitable approach? Having a seperate solution for each theme so that it gets compiled into a seperate XAP and loaded dynamically seems like a lot of work. Is there a way to externally load these while they are part of the same solution?
Thanks for your time
Disclaimer: What I am recommending may not be the best for you. I only know a tiny bit about your project and know nothing about what you have told the customer (or boss) what you would deliver them.
If you are going to have x (where x is between 2 and 30-ish) themes. You will probably want to spend some time building a framework for supporting x themes. Since you won't want to change this framework every time you add a new theme, PRISM is perfect for you.
I would move everything out into x-ish silverlight class libraries. Obviously you could package similar themes together, like Seasons or Holidays, which would widdle down on the numbers of projects. Now don't forget that your Visual Studio Solution can have more than one project in it (Simply right click on the project and select Add->New Project).
Using PRISM is rather simple and there are a lot of resources to help you dynamically load xap files. It sounds like you may eventually want to rid yourself of problems associated with compiling in a bunch of similar logic.
Is there a way to externally load these while they are part of the same solution?
The answer is yes! You will have to compile your individual silverlight applications into XAP files and load them with PRISM.
It may seem like a lot of work, but when you've created the first few of them, it becomes second nature and really simple to add more XAP's to your list.
http://development-guides.silverbaylabs.org/Video/Silverlight-Prism
http://msdn.microsoft.com/en-us/magazine/dd943055.aspx
http://www.sparklingclient.com/prism-silverlight/
I've got a single Silverlight app that I'd like to display in a grid. The way the Silverlight app displays its content is dependent on the unique ID of the record in each grid row. Unfortunately, the XAP file is re-downloaded for each row in the grid. With a size of 700KB, this really impacts performance. Is it possible to download the XAP file once and then just re-use it for each row in the grid?
Once a XAP is downloaded Silverlight will cache the assemblies etc locally per instance of a Silverlight control. If you create another instance of a Silverlight control then this in turn has it's own domain that it in turn looks after.
My suggestion is to abstract out the parts you requrie and bake them into a seperate xaml, then load them into areas where you need them the most. If you still require a central .xap to handle the marshalling / event management etc then in Silverlight 3 we've put in place a Local Connection API which allows other Silverlight instances to talk to one another within the one browser page locally (ie SilverlighA can talk to SilverlightB all within index.html)
This can then allow you to establish a sort of local proxy if you will.
Scott Barnes / Rich Platforms Product Manager / Microsoft.
I'm not sure you can. Theoretically it should be cached, but in this case theory don't seem worth squat.
It's all down to the way the < object > tag behaves with it's various params and this is (another) one of the "sparsely" documented areas of silverlight.
It is possible but not easy to do. You could download the xap and save it to IsolatedStorage and create a silverlight host each time you need one referencing your cached xap but you only have 1MB space available and you aren't guaranteed that if you have other silverlight apps from the same domain.
Given what you described I still don't see any value in doing what you want to do. I think you have it backwards.
I want to know about general methods to dynamically load content into your silverlight application.
More specifically, I want to create something like a widget-based application, where all GUI objects are small independent widgets. I want to provide a static chrome, like a frame, hosting the actual widget, that is loaded from an extern source like a website or is uploaded by the user and is shown in this frame.
The questions are:
What does the widget author specifically have to provide, in order for me to load his widget application into my application? I imagine I have to query the provided DLL for something like a ViewModel and its DataTemplate, a UserControl or even a XAP File. What would be the best way? The external widget should also implement a certain interface, so that the outer application can call methods like Loaded and Unloaded on it.
Small code samples would be appreciated.
What about security? How do I prevent the inner widget application to access my outer application. I think the widget app could go up the control tree or access the DataContext of my frame control, hosting the application. Is this an issue? If so, how to solve it?
Thanks in advance!
Andrej
You can dynamically load controls from dlls that your widget authors could provide, MS's Mike Taulty's done a walkthrough.
Microsoft also have Prism which allows you to break up your silverlight code in a modular fashion. I haven't tried it yet to see if it's suitable for loading individual controls, but my impressions of what I've read about it seem to indicate it has a framework for doing that.
As for security, they would have access to the rest of the application, so perhaps this isn't suitable.