I'm currently investigating MEF to know the feasibility of some kind of plugin subsystem for a software we are writing at my company. One of the first questions that came to my mind is to know the influence of MEF components in the application load time.
Moreover, if that's something of significant weight, is it possible to load those components completely at runtime?
Thanks in advance
Roman
I'm building an application completely on top of MEF and the load time is quite good. Yes, you can instantiate objects at runtime; it's called Lazy Imports.
Related
my first question on here and I cant seem to find a similar question so sorry if this has been asked before.
This is Unity related by the way, and yes I have also posted on Unity3D answers but thought I might also be able to get help from knowledgeable individuals on stack overflow also.
Basically I am wondering if there is a way to make platform dependent objects or components. I know I can wrap code in pre-processor directive commands which I have been doing, but I tend to use a ton of plugins, many of which only function on specific platforms.
However, I have just one project for all my platform dependent versions of the game and wish to continue working this way. So I was wondering if somehow I can make say an object that has the compatible plugin components, that will only be created if a certain platform is being built for.
If not, is there a way to make an object use say a specific plugins component if say on WP8, but then another entirely different component in its place if building for Android?
If these are not possible, how do you guys get around having platform dependant plugins? Do you simply just make separate projects for each platform? (feels like that defeats the point of unity's cross platform-ness though...)
Thanks guys, any help will be greatly appreciated!
Unfortunately, you will be forced to rely on pre-processor directives if you need to run unique code per platform.
However, this can be a lot easier to manage if you apply a facade-based design pattern. Instead of peppering platform-specific details in myriad scripts throughout your project, you can create one or more facade components that expose a more generic, abstract interface. The facades can internally manage prefabs, APIs, or whatever other platform-specific details you need.
As an example, you could write a SaveManager class that manages player save data. On platforms where direct file access is available, the SaveManager instantiates and controls an internal FileSaveManager that uses direct file access. On other platforms such as web builds, the SaveManager instantiates and controls a PlayerPrefsSaveManager that uses Unity's PlayerPrefs system instead. That way, each of those classes contains only the code that it needs, and other classes can just call SaveManager without worrying about those details.
At the moment I'm doing it in a global, singleton ApplicationModel, but I feel that model should be thinner, and a more cohesive set of tasks and properties concerning composition could be relocated, on their own, to a new 'CompositionModel' class. Each of the vertical imported modules has their own MVVM stack and are basically self sustaining, with very little dependency on the core, or shell, application.
Works for me! I'm currently using it in an application where the client needs to be able to configure services by simply dropping plugins into the relevant folders, haven't run into any major issues so far. As far as your resource dictionaries go you may want to look at the answers to this question, paying particular attention to the build settings...you will need to call InitializeComponent() to get the resources to merge correctly.
I am working with an application that has some Wicket pages, divided into some Applications. We are expanding the Wicket development to substitute other legacy content. Right now, there is no clear path wether to write new Wicket Applications for each workflow, or if we should have one big Application with many URL mappings. I did not find any information about this either.
As far as we are, we see following issues:
Many Wicket Applications pattern:
Each Application (Workflow) can be easily mounted without much of a hassle.
Even if it's not more time consuming, you end up writing more Java Classes (at least for each Application you need at least some basic structure).
Each Application default URL get's accessed by it's homepage, so no further config is necessary.
One big Application pattern:
Each Workflow needs a Page, which has to be mapped in the Application class. As far as I've seen, there is no configuration in xml files to archieve this, but it should be possible to develop some schema that allows to structure this in some xml file. Disatvantage: more time consuming for the first time
For further addings, it should be somewhat easier than with the Application pattern, but it doesn't make a difference that would make a real difference considering that the workflow development is always way bigger than the initial config.
Each Workflow default URL can be accessed by the URL mapping, and can be changed easily, it seems a little easier than with the Application approach, but doesn't make a big difference either.
Now, what I'm looking for:
Opinion based on experiences, maybe arguments for deciding for one or another way.
Is there any documentation from Apache or some source for this? If so, some reference would be a great advice.
As I understand it, you would still deploy all of your Wicket Applications within one single Web Archive.
Doing that, in my opinion you lose the only real advantage of separating your code into different Wicket Applications. If you separate your code into multiple Wicket Application classes
you have to think of configuring each Wicket Application the same way and not forget a single one (include it in the web.xml, call the same settings in the init()-method, ...)
you are writing more boilerplate code as you already said yourself
The configuration and code would be more complex than with the "single application" approach. With a single application
you only have to mount the start page of each workflow in your single application class...which is one line of code compared to a new class and some lines of web.xml config with the multiple applications approac
So, if you don't want to deploy your workflows separately, I'd go with a single application. It makes it so much easier. Especially when you have accumulated more than a couple workflows the single application approach will probably be much easier to maintain.
How much shared coda are you likely to have?
Are there different performance/load tolerance/availability requirements for the different workflows?
These are the questions I use in general to decide whether two things should go in one application or not, and that's pretty much independent from Wicket.
Obviously much shared code points towards a single application. Of course you can still use separate applications with all of them depending on a set of shared modules but in practice you'll spend a lot of time trying to keep your modules in sync.
Similarly, wildly different availability requirements might steer you in the direction of separate applications as you'd probably want to deploy them separately.
The most difficult scenario is if you have much shared code AND you still want to deploy them separately, in that case a multi-tiered approach (multiple frontends connecting to a common backend) might be worth considering.
I am about to start building an app that will be used across all platforms. I will using monotouch and monodriod so I can keep things in .net
I'm a little lazy so I want to be able to reuse as much code as possible.
Lets say I want to create an application that stores contact information. e.g. Name & Phone number
My application needs to be able to retrieve data from a web service and also store data locally.
The MVVM pattern looks like the way to go but im not sure my approach below is 100% correct
Is this correct?
A project that contains my models
A project that contains my views,local storage methods and also view models which I bind my views to. In this case there would be 3 different projects based on the 3 os's
A data access layer project that is used for binding to services and local data storage
Any suggestions would be great.
Thanks for your time
Not specifically answering your question, but here are some lazy pointers...
you can definitely reuse a lot of code across all 3 platforms (plus MonoWebOS?!)
reusing the code is pretty easy, but you'll need to maintain separate project files for every library on each platform (this can be a chore)
MVVM certainly works for WP7. It's not quite as well catered for in MonoTouch and MonoDroid
some of the main areas you'll need to code separately for each device are:
UI abstractions - each platform has their own idea of "tabs", "lists", "toasts", etc
network operations - the System.Net capabilities are slightly different on each
file IO
multitasking capabilities
device interaction (e.g. location, making calls etc)
interface abstraction and IoC (Ninject?) could help with all of these
The same unit tests should be able to run all 3 platforms?
Update - I can't believe I just stumbled across my own answer... :) In addition to this answer, you might want to look at MonoCross and MvvmCross - and no doubt plenty of other hybrid platforms on the way:
https://github.com/slodge/MvvmCross
http://monocross.net (MVC Rather then Mvvm)
Jonas Follesoe's cross platform development talk: Has to be the most comprehensive resource out there at the moment. He talks about how best to share code and resources, abstract out much of the UI and UX differences, shows viable reusable usage of MVVM across platforms and nice techniques for putting together an almost automated build. (yes, that includes a way for you to compile you monotouch stuff on Visual Studio)
Best of all he has a available source code for the finished product and for a number of the major component individually placed in its own workshop project and a 50 + page pdf detailing the steps to do so.FlightsNorway on github
IMO the only thing missing is how best to handle local data storage across all platforms. In which case I would direct you to Vici Cool Storage an ORM that can work with WP7, MonoTouch and (while not officially supported) MonoDroid.
*Disclaimer* The site documentation isn't the most updated but the source code is available. (Because documentation is Kriptonite to many a programmer)
I think the easiest way to write the code once and have it work on all three platforms will probably be a web-based application. Check out Untappd for example.
You can start by looking at Robert Kozak's MonoTouch MVVM framework. It's just a start though.
MonoTouch MVVM
At what level of complexity is it mandatory to switch to an existing framework for web development?
What measurement of complexity is practical for web development? Code length? Feature list? Database Size?
If you work on several different sites then by using a common framework across all of them you can spend time working on the code rather than trying to remember what is located where and why.
I'd always use a framework of some sort, even if it's your own, as the uniformity will help you structure your project. Unless it's a one page static HTML project.
There is no mandatory limit however.
I don't think there is a level of complexity that necessitates a framework. For me whenever I am writing a dynamic site I immediately consider a framework, and if it will save me time, I use it(it almost always does, and I almost always do).
Consider that the question may be faulty. Many of the most complex websites don't use any popular, preexisting, framework. Google has their own web server and their own custom way of doing things, as does Amazon, and probably lots of other sites.
If a framework makes your task easier, or provides added value, go for it. However, when you get that framework you are tied to a new dependancy. I'm starting to essentially recreate a Joel on Software post, so I will redirect you here for more on adding unneeded dependencies to your code:
http://www.joelonsoftware.com/articles/fog0000000007.html
All factors matter. You should measure how much time you can save using 3rd party framework and compare it to the risks of using other's code
Never "mandatory." Some problems are not well solved by any framework. It would be suggestible to switch to a framework when most of the code you are implementing has already be implemented by the framework in question in a way that suits your particular application. This saves you time, energy, and will most likely be more stable than the fresh code you would have written.
This is really two questions, you realize. :-) The answer to the first one is that it's never mandatory, but honestly, parsing HTML request parameters directly is pretty horrible right from the start. I don't want to do it even once, so I tend to go toward a framework relatively early on.
As far as what measurement is practical, well, what are you worried about? All of the descriptions that you list have value. Database size matters primarily for scaling, in my opinion (you can write a very simple app if you have a very simple schema, even if there are hundreds of thousands of rows in the database). The feature list will probably determine the number and complexity of UI pages, which will in turn help to dictate the code length.
There are frameworks that are there for getting moving very quickly with a simple blog, django or RoR all the way to enterprise full-stack applications Zope. Not to be tied to just the buzz world, you also have ASP.Net and J2EE, etc.
All frameworks and libraries are tools at your disposal. Determine which ones will make your life easier for your given project and use them.
I would say the reverse is true. At some point, your project gets so expansive, that you actually get slowed down by the shortcomings of the framework. For sufficiently large projects you may, in fact, be better off developing your own framework, to meet your own needs. I have seen many times where people were held back in the decisions they could make, or the work they could produce, because they were trying to do something that the framework didn't anticipate. And doing these things that the framework doesn't anticipate can be very troublesome. The nice thing about making your own framework, is that it can evolve with your project, to be a help to you system, instead of a hindrance.
So, to conclude, small projects should be use existing frameworks. Large projects should contain their own framework.