On Jan 11, 2013, at 5:24 PM, ggeorge <[email protected]> wrote:
> One of the requirements is to load third party UI plugin(s) in my app
> dynamically.
How "dynamic" are you talking? :-)
There's "dynamic" as in "I'm going to load a local assembly via
Assembly.Load()", and there's dynamic as in "I'm going to download an assembly
from the internet and load it via Assembly.Load()."
Rephrased, the crucial difference: is the assembly you're loading dynamically
distributed with your app?
Why's it matter? Linking [0, 1]: in order to shrink application sizes, a
"linker" starts with a "root set" of assemblies (your app assemblies), looks
for all types and members actually used, then removes everything that isn't
used. Pro: smaller app sizes.
Con: if you download assemblies dynamically (and/or generate them dynamically),
there is a possibility that the types/members that your downloaded code uses
WILL NOT EXIST. Result: Boom.
Furthermore, since MonoTouch doesn't have a JIT, you can't download assemblies
dynamically _anyway_; all assemblies must be present at package time so that
they can be AOT'd.
If all of your 3rd party assemblies are present at package creation time,
you're fine; you can use Assembly.Load("FileBasename") and it'll be found,
types can be reflected upon and instantiated, you're good. If you instead want
to _download_ 3rd party code at runtime, you're on thin ice. Either it won't
work at all (MonoTouch), or you need to somehow ensure that the types and
members that the 3rd party code uses will ALWAYS be present in your app.
- Jon
[0]: http://docs.xamarin.com/Android/Guides/Advanced_Topics/Linking
[1]: http://docs.xamarin.com/ios/Guides/Advanced_Topics/Linker
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
