Re: App loading speed

[Stephen Price]

Know what you mean there. I was implementing Prism by looking at the source
code and writing my own bits with the same names that they used in Prism.
Prism was in alpha at the time. Switching over was fairly easy (mainly
because of my choice of copying that which we ended up using.)

Heck, it's all made up as we go along. Once someone stops and looks for the
common things we're making up, they smack a label on it, call it a pattern
or best practice and then its official. Remembering Silverlight was barely a
whisper three years ago (half my official development career) makes me
realise how fast things are moving still. Wh, Silverlight 4 is out this
week and I'm not even sure its hit its third birthday... nope. just checked,
it's third birthday is the 5th of September.

Agreed though, using Prism for a little project would be overkill but it
sounds like its gotten to the size where splitting things up would be of
benefit. You don't have to implement the whole of Prism, just pick the bits
out you want. If you get stuck ping me off list. I wouldn't say I'm an
expert with Prism but if I can help, be happy to.

cheers,
Stephen

On Wed, Apr 14, 2010 at 3:53 PM, Greg Keogh  wrote:

>  Stephen, Prism would divert and solve my whole loading problem. Trouble
> is that I started this app when Prism was still in nappies and I decided to
> write my own mini-CAB which used the View-Controller pattern. I spent
> several weeks writing a demo in CAB and it was monstrous overkill for a team
> of one and half people. It made more work than it solved. I figured the same
> would happen with Prism, however I would now consider using it for any new
> large SL project, or perhaps the MVVM-lite that I saw last week.
>
>
>
> I was rather irritated that I followed the CAB pattern, and then last year
> everyone goes into a frenzy of MVVM and binding everything to everything
> else. Due to peer group pressure, over the last few months I’ve refactored
> my app to use binding in the MVVM style. Now my app is mostly MVVM with some
> remnants of View-Controller where I found the binding so mind-bogglingly
> difficult to  implement that I skipped it for now.
>
>
>
> I find that using pure binding is like building a delicate crystal palace
> made out of puzzle pieces. Binding is a clever invention, but it was
> released before anyone looked at the big picture of how to use it
> consistently and productively. I spend more time tweaking bound classes,
> properties and XML than I do writing code. Now we’ve got people advocating
> binding for method calls using wrapper classes and attached properties and
> I’m still not sure what’s the best way of doing it. It’s like it’s being
> invented on the run.
>
>
>
> Greg
>
> ___
> ozsilverlight mailing list
> ozsilverlight@ozsilverlight.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
>
>
___
ozsilverlight mailing list
ozsilverlight@ozsilverlight.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight

RE: App loading speed

[Greg Keogh]

Stephen, Prism would divert and solve my whole loading problem. Trouble is
that I started this app when Prism was still in nappies and I decided to
write my own mini-CAB which used the View-Controller pattern. I spent
several weeks writing a demo in CAB and it was monstrous overkill for a team
of one and half people. It made more work than it solved. I figured the same
would happen with Prism, however I would now consider using it for any new
large SL project, or perhaps the MVVM-lite that I saw last week.

 

I was rather irritated that I followed the CAB pattern, and then last year
everyone goes into a frenzy of MVVM and binding everything to everything
else. Due to peer group pressure, over the last few months I've refactored
my app to use binding in the MVVM style. Now my app is mostly MVVM with some
remnants of View-Controller where I found the binding so mind-bogglingly
difficult to  implement that I skipped it for now.

 

I find that using pure binding is like building a delicate crystal palace
made out of puzzle pieces. Binding is a clever invention, but it was
released before anyone looked at the big picture of how to use it
consistently and productively. I spend more time tweaking bound classes,
properties and XML than I do writing code. Now we've got people advocating
binding for method calls using wrapper classes and attached properties and
I'm still not sure what's the best way of doing it. It's like it's being
invented on the run.

 

Greg

___
ozsilverlight mailing list
ozsilverlight@ozsilverlight.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight

Re: App loading speed

[Stephen Price]

Another option is to look at Prism. We're using that. Shell downloads and
then modules download as required or when available (after the initial shell
has downloaded). It comes with some other stuff such as publish/subscribe to
enable communication between parts of the app.

Its more a pattern than a framework but provides an implementation. (also
uses Unity).

It would require a fair bit of work to implement (from memory I spent three
days or so, but as I was already following a lot of the pattern it was
fairly easy to replace my code with theirs).

You can also download dll's in the background and load them dynamically
(which is what I was doing before switching to Prism)

good luck,
Stephen

On Wed, Apr 14, 2010 at 1:32 PM, Greg Keogh  wrote:

>  Hi Asheesh,
>
>
>
> My first test of moving the images to “site of origin” worked nicely, as no
> code changes are needed. The XAP file reduced from about 2MB to 800KB and
> you can feel the loading speed improvement.
>
>
>
> However, I have noticed that some later controls load more slowly first
> time as new Tree control images are loaded. This seems to be a trivial
> problem though.
>
>
>
> I forgot that MEF now gets parts from XAPs. I’ll read the documentation on
> that feature.
>
>
>
> Thanks
>
> Greg
>
> ___
> ozsilverlight mailing list
> ozsilverlight@ozsilverlight.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
>
>
___
ozsilverlight mailing list
ozsilverlight@ozsilverlight.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight

RE: App loading speed

[Greg Keogh]

Hi Asheesh,

 

My first test of moving the images to "site of origin" worked nicely, as no
code changes are needed. The XAP file reduced from about 2MB to 800KB and
you can feel the loading speed improvement.

 

However, I have noticed that some later controls load more slowly first time
as new Tree control images are loaded. This seems to be a trivial problem
though.

 

I forgot that MEF now gets parts from XAPs. I'll read the documentation on
that feature.

 

Thanks

Greg

___
ozsilverlight mailing list
ozsilverlight@ozsilverlight.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight

Re: App loading speed

[Asheesh Soni]

Link for MEF:

http://mef.codeplex.com/wikipage?title=DeploymentCatalog&referringTitle=Using%20Catalogs


On Wed, Apr 14, 2010 at 3:05 PM, Asheesh Soni  wrote:

> 1. Remove the images from the XAP and web-deploy them. You'd have to move
> your XAP outside the clientbin (one level up)
> 2. Use MEF
>
> On Wed, Apr 14, 2010 at 2:33 PM, Greg Keogh  wrote:
>
>>  I’ve finally hit the point where the loading speed of the SL3 app is
>> becoming an issue. On my LAN it takes 3-5 seconds to load, but it takes a
>> frightening 30 seconds or more from a different office over their ADSL-1
>> connection. My XAP file contains a fr-FR locale for globalisation testing
>> and I’m using some Liquid and Visifire controls. Below I’ve pasted the
>> contents of the XAP file in size order. The size is distributed like this:
>>
>>
>>
>> Root ~ 2.53 MB
>>
>> fr ~ 289 KB
>>
>> images ~ 1.2 MB
>>
>> TOTAL ~ 4MB
>>
>>
>>
>> I was hoping that I could simply take a couple of the big DLLs out of the
>> manifest and async load them as assembly parts, which would have been great
>> as the big Visifire DLL isn’t need until after you logon and navigate down a
>> few screens. But it doesn’t look that simple because the size is taken up by
>> a mix of different things. Just taking the 598 KB Visifire DLL out won’t
>> make significant difference. As a first experiment I’m going to see if the
>> images can be removed from the XAP and web-deployed.
>>
>>
>>
>> This is a lesson that you must not forget deployment size issues in a
>> large SL app. Some of you must have much larger XAP files than I do, and I’m
>> keen to hear what tricks or techniques you use to keep app loading speed
>> tolerable.
>>
>>
>>
>> Greg
>>
>>
>>
>>
>>
>> *Root folder*
>>
>> *fr subfolder*
>>
>>
>>
>> ___
>> ozsilverlight mailing list
>> ozsilverlight@ozsilverlight.com
>> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
>>
>>
>
<><>___
ozsilverlight mailing list
ozsilverlight@ozsilverlight.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight

Re: App loading speed

[Asheesh Soni]

1. Remove the images from the XAP and web-deploy them. You'd have to move
your XAP outside the clientbin (one level up)
2. Use MEF

On Wed, Apr 14, 2010 at 2:33 PM, Greg Keogh  wrote:

>  I’ve finally hit the point where the loading speed of the SL3 app is
> becoming an issue. On my LAN it takes 3-5 seconds to load, but it takes a
> frightening 30 seconds or more from a different office over their ADSL-1
> connection. My XAP file contains a fr-FR locale for globalisation testing
> and I’m using some Liquid and Visifire controls. Below I’ve pasted the
> contents of the XAP file in size order. The size is distributed like this:
>
>
>
> Root ~ 2.53 MB
>
> fr ~ 289 KB
>
> images ~ 1.2 MB
>
> TOTAL ~ 4MB
>
>
>
> I was hoping that I could simply take a couple of the big DLLs out of the
> manifest and async load them as assembly parts, which would have been great
> as the big Visifire DLL isn’t need until after you logon and navigate down a
> few screens. But it doesn’t look that simple because the size is taken up by
> a mix of different things. Just taking the 598 KB Visifire DLL out won’t
> make significant difference. As a first experiment I’m going to see if the
> images can be removed from the XAP and web-deployed.
>
>
>
> This is a lesson that you must not forget deployment size issues in a large
> SL app. Some of you must have much larger XAP files than I do, and I’m keen
> to hear what tricks or techniques you use to keep app loading speed
> tolerable.
>
>
>
> Greg
>
>
>
>
>
> *Root folder*
>
> *fr subfolder*
>
>
>
> ___
> ozsilverlight mailing list
> ozsilverlight@ozsilverlight.com
> http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight
>
>
<><>___
ozsilverlight mailing list
ozsilverlight@ozsilverlight.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozsilverlight