I am trying to access a web API using an HttpWebRequest in C#. However, whenever I attempt to use the method GetResponse I get an error that the method does not exist.
However it is clearly defined here that GetResponse should work.
I have done something almost identical to this on a different app. The code for that app was written on a different machine. Still, is it possible to perform a GetResponse without having to muck with threads?
I think that is caused because you're on Silverlight which has a subset of the actual framework. You should use the async methodsof the GetResponse. It seems it's duplicated on this post Can't find HttpWebRequest.GetResponse() in WP7 Project
HttpWebRequest and HttpWebResponse are not available when your are develop apps for WP7. You need to use WebClient and there only the async methods.
Related
I have read the two other questions on SO regarding this and I wanted to know if there is a good solution for that now / best practice.
Long story short, we use an SDK which is written natively and we've wrapped it so that it works on Xamarin.Android and Xamarin.iOS. It has asynchronous callback methods. I need to call a method in the shared code when a callback is received in the Android project for instance.
There's a lot of info for doing the opposite - using DependencyService. How about in my scenario? Does anyone have experience with an app like this and what's the best approach to keep code clean and do this using MVVM?
The options I know are:
Using a static App instance - this is what we currently do.
MessagingCenter
Anything else?
Actually I've never seen anyone recommend usage of MessagingCenter for anything else than communication between ViewModels so I am not sure it is recommended here. Also, I need to know the sender object type so I need a reference to the class in the platform specific project.
I would recommend you to use messagingCenter to pass data or call method between shared project and platform project. You can just send a new object instead of the class in the platform specific project.
Also, have a look at using eventhandler as I mentioned in this answer may help someone who want to call from the shared project into the platform specific one.
BTW, I mean you can even pass an object as TSender if it is not necessary to use:
MessagingCenter.Send<Object>(new object(), "Hi");
MessagingCenter.Subscribe<Object>(new object(), "Hi", (sender) =>
{
// Do something whenever the "Hi" message is received
});
I am using RestSharp in my Xamarin.Forms Project. Problem is RestClient.ExecuteTaskAsync is returning cached response when accessing same end point without stopping app. I have tried some suggestions like adding Random Number/TimeStamp as parameter, have tried setting header and Cache Policy like
_client.AddDefaultHeader("Cache-Control", "no-cache");
_client.CachePolicy = new
HttpRequestCachePolicy(HttpRequestCacheLevel.NoCacheNoStore);
But nothing work. Interesting point is, Cache is not creating problem for one Api Call where I am passing Credentials as Json Body. But for all other API Calls, even changing the parameters doesn't effect. It always bring cached response, until I stop app and then open app again.
I am using MVVM and Dependency Injection, So RestClient Object is passed as Dependency to constructor of class where I am using it. Currently testing in Android not tested in iOS. Please advise.
This article suggests it was possible, or in the works, with some code that suggests it can be done, but I can't figure out what code needs to happen or the WcfTestClient's uri needs to be.
Here's the code from the article that makes me think I can do it:
// Metadata routes to support $metadata and code generation in the WCF Data Service client.
configuration.Routes.MapHttpRoute(
ODataRouteNames.Metadata,
"$metadata",
new { Controller = "ODataMetadata", Action = "GetMetadata" }
);
Is this feature implemented?
No, it does not work as you intend. WCF Test Client supports talking to SOAP-based services. OData is not supported in the current version.
Granted, as #Snixtor mentioned, you could create a SOAP service using ASP.NET Web API, including support for metadata (WSDL). But I really don't know of any good reason why anyone would want to do that.
We have a long established, greatly multiplatform codebase that is currently being ported to WinRT. One of the challenges we're facing is how to handle WinRT's asynchronous style.
For example, we are unsure how to handle WinRT's async file operations. Unsurprisingly, our codebase's API is synchronous. A typical example is our File::Open function which attempts to open a file and return with success or failure. How can we call WinRT functions and yet keep the behavior of our functions the same?
Note that we are unfortunately constrained by legacy: we cannot simply go and change the API to become asynchronous.
Thanks!
I assume you wish to reimplement the library to support WinRT apps while not changin the definitions of the APIs so that existing applications remain compatible.
I think that if you don't include the await keyword when calling an async method you will not do an async operation, it should execute in a synchronous way. But it really doesn't work if the method returns a value (in my experience).
I've been using this code to make a file operation synchronous:
IAsyncOperation<string> contentAsync = FileIO.ReadTextAsync(file);
contentAsync.AsTask().Wait();
string content = contentAsync.GetResults();
If you want to share your code with a platform that does not support async/await - you are probably better off having a different API for the old platform and the new one with switches like
#if SILVERLIGHT
#elif NETFX_CORE
#elif WPF
#endif
Eventually the async APIs are likely to show up in older platforms and you could actually wrap the non-async calls into Tasks to make them async if they don't. Forcing async method to work synchronously is bound to bite you back rather quickly. Your WinRT app might become unresponsive for a few seconds for example and get killed by the OS. Or you could get deadlocks waiting for tasks to complete and blocking the thread they try to complete on.
... is eating me for breakfast.
Just pretend I know nothing. I have ended in NotSupportedExceptions, or worse. Every example I can find on the web uses GetResponse (either I am confused or you can't use that in the version on WP7, must use BeginGetResponse right??)