Looking at the silverlight business application, it seems to add a number of libraries specific to Input Forms and the like.
Am I right in saying that creating Complex classes results in these forms being generated automatically?
Looking at the file size of the basic Silverlight business application XAP file, it's around 412Kb. Is there a way to reduce that size?
Regards,
Jacques
You can re-zip the XAP file, but that is only a 20% saving generally at best.
Using the PRISM pattern and a modular approach, we managed to get our initial page load down to around 150Kb (the entire app is over 4Mb). The rest of the modules continue to stream down in the background so we get something on-screen very fast.
If you intend to build a large application, PRISM and/or MEF is the way to go. It has an additional learning curve but it results in very modular apps (great for team development/maintenance).
Here are some tips and tricks to try to make your XAP smaller. Like removing references you don't really use and re-zipping the XAP. Hope it helps!
http://forums.silverlight.net/t/21548.aspx
Related
We've been developing several WinForms projects for a client over the past year and have noticed that the projects are starting to use a common set of image resources (about 20) for controls like tool strip buttons, picture boxes, etc. Would it be considered good, acceptable or poor practice to embed these images in their own class library and provide a reference in each WinForms project, instead of continuing to embed them in directly in each WinForms project? Each WinForms project would use most of the images, but not necessarily all. Would there be any type of performance penalty for using the separate DLL for the images?
Any thoughts on this would be appreciated.
Many thanks,
Paul
The resources are only loaded into memory as requested, meaning that you will pay for them by disk space but not by memory consumption or performance.
There is some overhead associated with the assembly itself (that you could avoid by using LOAD_LIBRARY_AS_DATAFILE, considerably complicating this task), but this overhead is of no concern if the assembly contributes no code.
The change impacts your development processes more than the end product, which is typical of reuse. If you can say that it is the same team of people collectively managing all the applications, I see only good sides to this particular practice. You will just have to be a little more careful with versioning so that changes done for one application will not break another.
I have a WPF application (KaleidoscopeApplication) organized as follows:
Solution (6 projects)
Cryptography (DLL)
Rfid (DLL)
KaleidoscopeApplication (buildable "startup project")
Basically, KaleidoscopeApplication contains a bunch of resources (sounds, images, etc) and your standard WPF junk (App.xaml, App.xaml.cs, other xaml and code).
I need to create a new application that is very similar to Kaleidoscope, but I'm not sure of the best way to organize. This new app will need access to much of the same code and resources as Kaleidoscope. Preferably, I would like to create a new project in the solution, then simply use the "set as startup project" to pick which app I want to build. However, will I be able to access (share) the Resources folder of Kaleidoscope?
I know I will be able to access much of the code if I simply add a reference to the project and include a "using Kaleidoscope". But the resources I'm not so sure about.
Is this the right way to organize or am I asking for trouble in the future?
Thanks in advance!
The recommended solution in this case would be to refactor the resources and any common required code into a separate Assembly that both UI applications could use. You will probably need to do some manual tweaking to make sure everything is exposed the way you need it to be, but it'll make things cleaner in the long run.
I agree with Dan about this. You definitely need a common type of project to put all those shared classes and resources, and one for your start up. From there, you can easily add new projects by following the same kind of pattern of separation of concerns.
I want to utilise the 3dwall feature of cooliris, the physics effects of the icons in bumtop to design an application for making the image viewing more intuitive and interactive. I dont want to use flash as it would slow down the speed for interaction on desktop. PLease could someone tell me about
choice of
1.) physics engine - physx or ODE for the physics effects like bumtop
2.) opengl or direct 3d
3.) WPF(windows presentation Format) - what is its use
Flash with Actionscript 3 is the best for such things. Checkout http://www.flashloaded.com/flashcomponents/3dwall/ for an illustration of CoolIris type application in Flash.
WPF is great for building application like this. VS2008 doesn't provide solution for good visualization,
but you can always call for help Blend included in MS Expression. There you can select silverlight project for building fancy web applications (silverlight.net/showcase). At start, combining different controls and trigger events to start simulations is entirely included. Yes, inside Blend you can set frame keys like in flash.
It's certainly a lots of effort, but it don't need to be. Recently new set of WIN RadControls for WinForms and Silverlight are issued and they look, believe me, excellent. You can look for Run Demo program which shows example of using these controls. Under section Integration, Carousel and others you will see what you looking for and beyound.
I am currently working on a project of mine using Prism (the Composite Application Library/Guidance). The application will be a specialized MSPaint-like application for basketball (predefined objects for balls, players etc.).
Now I am wondering how to go about organizing my application into Prism modules. Especially when thinking about the drawing part of the software.
Should I split the general drawing view (2 columns: toolbox, canvas) in 2 modules (toolbox and canvas) or would the overhead created by the constant communication of these modules be too overwhelming?
How fine grained should Prism modules really be?
Thanks in advance and best regards,
crischu
There's very little overhead when you separate into modules.
I would go with what helps you organize your solution, rather than worrying very much about performance considerations. You can easily combine modules if you find they are causing you trouble or you are finding that two modules really belong together.
The rule is:
Make it run.
Make it run right.
Make it run fast.
In that order. Do what feels good first and refactor later if necessary.
I'd say it depends on how you distribute the functionality of your application over the UI. If you have just one screen, but with multiple sections that manage different features, each of that section (tab page, panel, etc) should have it's own module. This is the case with the StockTrader RI or NewsAggregator samples.
But on the project we are starting we decided to have multiple pages, one page for each major feature and to have navigation between them. In this case, a module will represent a page, nothing smaller than that.
Background: We have an offshore group working up a Silverlight 2 prototype for us. There is the conception that we need to be very concerned with lazy loading of various "screens"/parts of the application. The offshore group has decided to dynamically load assemblies in order to achieve this; however, I would think MS has already dealt with this issue.
Question: Does Silverlight already deal with loading assemblies in an intelligent manner or is that something that we will have to be concerned with?
Cut+paste from my existing answer on another question.. Jesse Liberty has some decent tutorials on multi-page Silverlight apps:
Tutorial
and
Update
You can make your initial app nothing more than a basic "stub" and then load the other bits once you at least have some GUI available. Doesn't come out of the box, but it's straightforward to do.
Tim Heuer has a good video explaining how you can dynamicly load assemblies at runtime:
http://silverlight.net/learn/learnvideo.aspx?video=65687
There should also be a version of the Prism toolkit from the Microsoft PnP people sometime in the 1st quarter that will help with that.
Silverlight does have a built in ability to fetch various bits of the application in an on demand basis. However all these bits would be listed initially in the manifest.
However I suspect your partners are thinking in terms of dynamically determining new chunks of the application being downloaded and displayed even after the intial xap has been built.
I don't think you should be too concerned about this, its not actually excessively difficult to achieve.