I was following an example found here on StackOverflow, and everything went well until I need to register my types.
My web application is running on Silverlight 4, with Prism and MVVM.
The example is using "Microsoft.Practices.Unity" (it's a windows form application)
Bootstrapper.cs
protected override void ConfigureContainer()
{
base.ConfigureContainer();
Container.RegisterType<IApplicationMenuRegistry, MenuRegistry>();
Container.RegisterType<IApplicationCommands, ApplicationCommands>();
Container.RegisterType<ShellViewModel, ShellViewModel>(new Microsoft.Practices.Unity.ContainerControlledLifetimeManager());
}
Mine is using: Microsoft.Practices.Unity.Silverlight (web) and throws the following error:
The non-generic method 'Microsoft.Practices.Unity.IUnityContainer.RegisterType(...) cannot be used with type arguments.
And the RegisterType<> constructor is not visible for me. Which alternatives do I have to register my types?
I am using Unity for Silverlight and have not had this issue.
According to this post, http://unity.codeplex.com/workitem/8205, you need to add "using Microsoft.Practices.Unity;" to the file. The generic versions of Resolve are extension methods and you need to pull in the namespace to use them.
Apparently ReSharper may think the using statement is not needed and may remove it.
Hope that helps.
Related
Since dart is an open source language I was trying to get the implementations of dart abstract classes? for example I would like to see how dart team implemented String abstract class to see "trim()" method implementation, there is similar question here maybe but couldn't help me.
Navigating the Dart SDK repository require some experience before it gets easier. One reason is that it contains different implementation of some methods depending on the target platform (native vs JavaScript). Also, sometimes the native implementation is being done in C++ depending on if that makes more sense.
In your case, I have found the following two implementation of String.trim(). The first is used for native (Dart VM and AOT):
https://github.com/dart-lang/sdk/blob/1278bd5adb6a857580f137e47bc521976222f7b9/sdk/lib/_internal/vm/lib/string_patch.dart#L485
And the second is used when the target is JavaScript (sometimes, we can proxy methods directly to native JavaScript methods but in this case, the trim() in JS does have a different behavior from the String.trim() in Dart. This is documented above the method in the link):
https://github.com/dart-lang/sdk/blob/1278bd5adb6a857580f137e47bc521976222f7b9/sdk/lib/_internal/js_runtime/lib/js_string.dart#L263
Note about the annotations used in the first link
The internal Dart source code can often look a bit alien compared to the normal Dart code. E.g.:
#pragma("vm:recognized", "asm-intrinsic")
#pragma("vm:external-name", "String_charAt")
external String operator [](int index);
The #pragma is used tell the Dart compiler some additional information. It can e.g. be to enforce inlining of certain methods. Or as here, tell the compiler it should call a C++ method bound to an entry called String_charAt. If we make a search in the GitHub repo. we can find that method here:
https://github.com/dart-lang/sdk/blob/e995cb5f7cd67d39c1ee4bdbe95c8241db36725f/runtime/lib/string.cc#L443-L449
I'm giving a MVVMCross a spin, to see if it will be of use in some bigger projects coming up, and it's great. I like the navigation, viewModel location and general cross-platform approach, which is just what I need. However, I'm a bit stuck on splitting out some of the dependency injection depending on the platform.
So, we have the basic application, with a shared portable library, that initialises the service references when starting up:
public TwitterSearchApp()
{
InitaliseServices();
}
private void InitaliseServices()
{
this.RegisterServiceInstance<ITwitterSearchProvider>(new TwitterSearchProvider());
}
Fine. That defines the service implementations that will be used across all the platforms. But what about the situation where I will need different implementations on different platforms - for instance perhaps storage/caching, where the core requirement is the same, but needs to be handled differently on a phone than on a tablet.
I thought it might go in Setup somewhere:
public class Setup : MvxBaseWinRTSetup
{
public Setup(Frame rootFrame): base(rootFrame)
{
}
protected override MvxApplication CreateApp()
{
var app = new TwitterSearchApp();//set platorm specific IoC here maybe?
return app;
}
protected override void AddPluginsLoaders(Cirrious.MvvmCross.Platform.MvxLoaderPluginRegistry loaders)
{ // or perhaps here?
loaders.AddConventionalPlugin<Cirrious.MvvmCross.Plugins.Visibility.WinRT.Plugin>();
base.AddPluginsLoaders(loaders);
}
}
but I'm not sure. I've seen the references to replacing the ViewModel locator, but is there are similar way of replacing the other IoC services?
thanks, great job on the framework in general, I really like how it works (apart from this bit, which I don't understand properly yet)
Toby
There are three basic options:
1. Add the platform specific services in your UI project and then register them in an override during setup - which override you use depends on when your services are needed, but for most cases you can just use the InitializeLastChance override which gets called at the end of initialization:
protected override void InitializeLastChance()
{
this.RegisterServiceInstance<IMyService>(new SingletonMyService());
this.RegisterServiceType<IMyService2, PerCallService2>();
base.InitialiseLastChance();
}
If 'last chance' is too late for your service - if you need the service during the core app startup - then you can override any initialisation step after InitializeIoC - e.g. InitializeFirstChance. For the list and order of initialisation steps, see InitializePrimary and InitializeSecondary in MvxBaseSetup.cs
2. Add the platform specific registration in some other bit of the UI code - e.g. in the constructor for a specific View (this option isn't used much... but you could use it in some odd cases, if you wanted to...)
3. Use a plugin - all plugins are is a wrapper around IoC. Plugins have the disadvantage that they add some development overhead (you have to add the separate projects and the plugin boilerplate files), but they have the advantages that they can be reused across apps and it's easier to write test apps and test harnesses for them. For more info on plugins, see Making mono cross platform support for Task/Intent and see http://slodge.blogspot.co.uk/2012/10/build-new-plugin-for-mvvmcrosss.html
My general advice - start with the first option and migrate out to a plugin if you want to reuse the code in later projects...
I'm using ASP.Net MVC 4 RTM Web API. I have a controller action with a parameter that I'd like to populate via custom model binding. To achieve this, I created a class that derives from System.Web.Http.Controllers.HttpParameterBinding that sets the value of this parameter. I then created an attribute class that derives from System.Web.Http.ParameterBindingAttribute which I use to decorate the parameter on my controller action.
This is all working great, my HttpParameterBinding class is populating the action parameter correctly. The problem I have is that my custom parameter binding class has a dependency that I'd like resolved via my IoC container (Unity). Is there a way to override how Web API creates HttpParameterBinding instances so that I can build up my custom binding class dependency from Unity? I was able to do something similar for a filter attribute by creating a custom filter provider that uses Unity's BuildUp method to populate dependencies, however I'm not seeing anything similar for Web API's HttpParameterBindings.
In general: to use IoC / Unity in the Web API you need to set it up seperately.
Try downloading the nuget package Unity.WebApi and see if that helps!
Take a look at this article: Parameter Binding in WebAPI
It walks through a couple different options from Converters to Binders to BinderProviders. It sounds like you may be able to write a custom ModelBinderProvider which knows how to provide your dependency. If that isn't high enough in the chain you can look at replacing the default IActionValueBinder service. It's a DefaultActionValueBinder instance, which you can extend or simply re-implement.
I also highly recommend downloading the WebAPI source code, as it's been an incredible help for these issues as I've run into them. Here's the WebAPI source code. I recommend downloading it so you can open it in VS for easy navigation.
Feel free to check out FlitBit too (It's very modular, don't let the number of packages scare you off)! I'm working on a WebAPI package for supporting FlitBit, specifically FlitBit.IoC and FlitBit.Dto. I'll add an update if I work out my IoC issue, since it's very similar to yours.
When the context is generated i see there are some extension methods : AcceptChanges, MarkAsAdded, MarkAsDeleted, MarkAsModified.
When should i use these methods since they are available only on the service?
They are available on the client as well - make sure you've included their namespace at the beginning of your file. If not, the intellisense will not offer a suggestion for it since these are extension methods.
Usually, you reference the same project on the client side, and you should have these methods as well. You use them when appropriate of course.
I'm working on a GWT project and I find it very tedious to have to add a function to my servlet, then copy and paste the function signature into my Service interface, then copy and paste it into my ServiceAsync interface and change the return parameter to be a callback. Is there a tool or a setting where I can just add public methods to my class and they can get copied into the other interfaces? Even if its not automatic it would be nice to be able to select specific methods and have them copied automatically.
I'm using eclipse and ideally it would update my interface each time I save implementation since thats when it checks my code and complains that my changes break the interface.
If you add the method to your *Service interface, then Eclipse can auto-generate the method ("Add unimplemented methods...") in your *ServiceImpl servlet, which you can then just fill in. Also, if you've got the Google Eclipse plugin installed, it will underline the new method in your *Service interface and complain that it's not in the *ServiceAsync. It might have a CTRL + 1 option to generate it in that interface as well.
You don't really need a tool. Just factor out the many RPC methods by just one method that takes a Request/Response. all you need to do is create subclasses of Request/Response and you don't need to think about adding new methods in the 2 interfaces.
You can use Google Guice on the server side to map the incomming request to a class handling the call... or you could use a visitor approach to forward the incoming request to the code handling the request (without resorting on a big instanceof construct).
Instantiations WindowBuilder GWT Designer does exactly what you are looking for.
The RemoteService Wizard will create all three files at the same time as well as keep them in sync as you make changes.
http://www.instantiations.com/windowbuilder/gwtdesigner/index.html
FWIW - I am only a user/purchaser of this product. I am not employed or in any other way related to Instantiations.