I have a problem when calling a web-service(asmx) in Xamarin.forms. My web-service works in Android and I generated it with svcutil.exe, but when I tested it in IOS I got a problem saying:
"Mono touch does not support dynamic proxy code generation"
After searching I found out that I have to use a Silverlight tool called SLSvcutil.exe in order to override the CreateChannel method, and to make it work in IOS. It worked, but I need the methods to be synchronous (not async).
I kept searching how to make a pure synchronous method for my web-service and I found this: Monotouch/WCF: How to consume the wcf service without svcutil
Here is my code:
protected override POService2Soap CreateChannel()
{
return new POService2SoapClientChannel(this);
}
private class POService2SoapClientChannel : ChannelBase<POService2Soap>, POService2Soap
{
public POService2SoapClientChannel(System.ServiceModel.ClientBase<POService2Soap> client) :
base(client)
{
}
public ClientLoginResponse ClientLogin(ClientLoginRequest request)
{
object[] _args = new object[1];
_args[0] = request)
return (ClientLoginResponse)base.Invoke("ClientLogin", _args);
}
I get the interface from the Silverlight-generated code, and I create the LoginResponse class there etc, but the problem comes where i call base.invoke("Client Login",_args).
Basically, the ChannelBase doesn't have an Invoke method, it only has BeginInvoke and EndInvoke. So I get the problem cause there is no Invoke in the ChannelBase class inside ClientBase. How can I invoke this, or does anyone have any better solution for getting synchronous results from the web-service?
P.S. I know why Silverlight has async methods, also I know that it is better to async now, and I also know that web-services (asmx) especially in mobile development are a bit "outdated". But in my case I need it like that.
Thanks in advance.
Related
I'm currently designing a REST WVF web service in C# that will be used by an MVC website and just confused about one point. Say I have two methods with signature
public bool IsEmailAvailable(string email address) { ... }
public DbUser GetUser(object id) { ... }
Can I just keep my service interface and implementation as above? Someone has mentioned to me about designing it more like
public IsEmailAvailableResponse IsEmailAvailable(IsEmailAvailableRequest request) { ... }
public GetUserResponse GetUser(GetUserRequest request) { ... }
What are the pros and cons of implementing it each way?
This is someone is a clever guy. Remote interface is very important, the second version is more maintainable. You can can add additional params into Request|Response without breaking changes. This is a message based style.
As for me, even the second version is not good choice. The second version contains too concrete methods. A remote interface should be based on parametric polymorphism, so this kind of API will be stable and flexible
Thus, RESTful api should look like:
object Get(object request);
object Post(object request);
object Put(object request);
object Delete(object request);
etc..
Unfortunately, WCF doesn't support this kind of interface by default, but we can use the Message instead object and get the same result.
Take a look a following article for more details: Building RESTful Message Based Web Services with WCF
Our application calls external services like
//in client factory
FooServiceClient client = new FooServiceClient(binding, endpointAddress);
//in application code
client.BarMethod(); //or other methods
Is it possible to track all of these calls (e.g by events or something like that) so that the application can collect the statistics like number of call, response time, etc? Note that my application itself needs to access the values, not only to write to a log file.
What I can think is to create a subclass of VisualStudio-generated FooServiceClient and then add codes like this
override void BarMethod()
{
RaiseStart("BarMethod");
base.BarMethod();
RaiseEnd("BarMethod);
}
and the RaiseStart and RaiseEnd method will raise events that will be listened by my code.
But this seems tedious (because there are a lot of methods to override) and there is a lot of repeated codes, my code needs to change everytime the service contract changes, etc. Is there a simpler way to achieve this, for example by using reflection to create the subclass or by tapping into a built-in method in WCF, if any?
The first thing I would look at is to see if the counters available in your server's Performance Monitor can provide you with the kind of feedback you need. There's built in counters for a variety of metrics for ServiceModel Endpoints, Operations and Services. Here is some more info http://msdn.microsoft.com/en-us/library/ms735098.aspx
You could try building an implementation of IClientMessageInspector, which has a method to be called before the request is sent and when the reply is received. You can inspect the message, make logs etc in these methods.
You provide an implementation of IEndpointBehavior which applies your message inspector, and then add the endpoint behavior to your proxy client instance.
client.Endpoint.Behaviors.Add(new MyEndpointBehavior())
Check out the docs for MessageInspectors and EndpointBehaviors, there are many different ways of applying them (attributes, code, endpoint xml config), I can't remember of the top of my head which apply to which, as there also IServiceBehavior and IContractBehavior. I do know for sure that the endpoint behaviors can be added to the client proxy collection though.
I found a simple way to do it by using dynamic proxy, for example Castle's Dynamic Proxy.
Firstly, use a factory method to generate your client object
IFooClient GetClient()
{
FooClient client = new FooClient(); //or new FooClient(binding, endpointAddress); if you want
ProxyGenerator pg = new ProxyGenerator();
return pg.CreateInterfaceProxyWithTarget<IFoo>(client, new WcfCallInterceptor());
}
And define the interceptor
internal class WcfCallInterceptor : IInterceptor
{
public void Intercept(IInvocation invocation)
{
try
{
RaiseStart(invocation.Method.Name);
invocation.Proceed();
}
finally
{
RaiseEnd(invocation.Method.Name);
}
}
//you can define your implementation for RaiseStart and RaiseEnd
}
I can also change the intercept method as I wish, for example I can add a catch block to call a different handler in case the method throw exception, etc.
I am trying to create a sample app using OData and Silverlight, using (what else?) the Netflix service. I've already succeeded in creating the app using WPF, but am struggling to port my service class to an async model.
My existing service class (simplified) looks like this:
public IEnumerable<Title> BlockingSearch(TitleSearchParam param)
{
var catalog = new NetflixCatalog(new Uri("http://odata.netflix.com/Catalog/"));
return catalog.Titles.Where(t =>
t.Instant.AvailableFrom > param.InstantStartDate && t.Instant.AvailableFrom < param.InstantEndDate &&
(string.IsNullOrEmpty(param.TitleName) || t.Name.Contains(param.TitleName))).ToList();
}
All of the examples of consuming OData asynchronously employ some kind of Respository Pattern and/or require an instantiated collection to be passed in. I would like to model the method signature for the Silverlight/Async call to look something like this (with the service class itself being stateless):
public void AsyncSearch(TitleSearchParam param, Action<IEnumerable<Title>> completedCallback, Action<MyErrorClass> errorCallback, object callBackOwner)
{
}
I think I could so something along the lines of what MS outlines in Calling Synchronous Methods Asynchronously, but I was hoping there was a more elegant solution that I was missing.
As you already know, you can always run the call on a different thread than the UI thread, so there will be no blocking per se. That seems like a decent enough solution. Then you can (in fact, must) use dispatchers to handle results coming from callbacks if you intend to use them with UI.
I already searched a lot in Google.
I created a EntityClass on client side, and then I added the library reference of this class on Web Service side. But when I want to call the method, it shows this error:
Error 2 Argument 1: cannot convert
from
'Services_Library.UserService.UserServiceSoapClient'
to
'Services_Library.UserService.UserEntity'
here is the code, this method is called from a User Interface:
public UserEntity test(UserEntity userEntityx)
{
UserService.UserServiceSoapClient userService = new UserService.UserServiceSoapClient();
userService.testUserAsync(new UserEntity());
}
I think we can do this without explicit serialization, right? If so, I prefer this way.
I think the problem is when you actually call the service, you're passing in the serviceReference and not the object that the call accepts. I think it should look something like:
public UserEntity test(UserEntity userEntityX)
{
var userService = new UserService.UserServiceSoapClient();
return userService.testUser(userEntityX);
}
No explicit serialization needed.
Also, keep in mind that if you're calling the Async version of the method you're code is going to become more complicated. I used the synchronous version in my example.
Can someone tell my why when I have wcf contract:
[ServiceContract]
public interface IService1
{
[OperationContract]
string TestGetName();
}
and implementation
public string TestGetName()
{
return "Kasia";
}
When I try consume it in Console app I can do just that:
Service1Client client = new Service1Client();
Console.WriteLine((client.TestGetName()));
but in Silverlight I must use that way :
Service1Client clientTest = new Service1Client();
clientTest.TestGetNameCompleted += new EventHandler<TestGetNameCompletedEventArgs>(clientTest_TestGetNameCompleted);
clientTest.TestGetNameAsync();
void clientTest_TestGetNameCompleted(object sender, TestGetNameCompletedEventArgs e)
{
this.dataGridChild.DataContext = e.Result;
}
Why in SL I don't see this first short solution, but only this with Event handlers?
Or better... why in Console app I can choose synchro operation generation and in SL I must use Generate asynchronous operations... :/
A synchronous call would stop the Silverlight UI thread and possibly the executing environment, i.e. the browser. To prevent this, only asynchronous calls are allowed.
Of course this is something unusual at first, but in the long run it is actually helpful to decouple the view and service layer.
Silverlight does not support synchronous calls (which is what you're doing in your console app).
Update: http://forums.silverlight.net/forums/p/34531/104526.aspx "The main point is that it looks like synchronous behaviour was removed on account of not being supported by all browsers."