Javascript calling C# with multiple parameters - xamarin.forms

I used the following - https://developer.xamarin.com/guides/xamarin-forms/application-fundamentals/custom-renderer/hybridwebview/ to implement a hybrid webview. All works fine expect the part where I need to call the C# function from Javascript. The C# handler gets called but from the article, it seems like I can only get a single parameter passed to C#. So message.Body.ToString() gives me the arguments passed from Javascript. I however want to pass atleast to arguments. Can anybody please show me how I can achieve this.

It looks like you can only pass one parameter through. Hence you just need to develop your own way to pass more information through. You could for example create a class and serialize it in JSON, then deserialize it at the other end. JSON serializers and deserializers are widely available in .NET and JS, this shouldn't be much of a problem at all.
Or if the data is really simple, e.g. 2 numbers, you could do 1#4, and split via the hash at the other end.

Related

JSON.NET without classes

I have a component that acts as a middle man between 2 web services. Both of them communicate using JSON.
The data that goes back and forth from the web services is very similar. However, it does need to be massaged a little.
I currently have this working by deserializing the JSON, build a new JObject and serialize it. It seems like there should be better way.
I'm looking at JsonConvert, JsonConverter, JsonSerializer, JsonReader, etc. trying to see if there's a better way to do this.
Any guidance on what classes to use/override to make this process more efficent?
Thanks!
You can write a custom JsonConverter using the approach described in the documentation, so you'll only have one concrete class, but this class can translate to a slightly different JSON representation of your object.
Another, more verbose, blog post about writing custom JsonConverters can be found here: http://blog.maskalik.com/asp-net/json-net-implement-custom-serialization/

Streaming an http response within a composed action in Play! Framework 2.1

I'm creating an authentication action that wraps other actions, using the Play Zentasks sample app as a template. One of the things that this needs to be able to do, is hit a webservice in certain circumstances, in order to retrieve a user's details. I want to do this in a non-blocking fashion, but I don't want to have to pass a future back to the action that I'm wrapping.
The only way that I can think of doing this is by using Enumerator.fromStream() with an InputStream pulled from a URL object. I'm guessing this isn't the best way though, since it seems like a duplication of efforts (considering the ws object). The async ws api (and underlying asynchttpclient) returns a Future for everything however. I don't suppose anyone has tackled this issue before and could point me in another direction? Is there something that I'm missing? Also, would using a Enumerator.fromStream() as I've suggested definitely not block?
Thanks in advance,
Suche
You can use the async WS api. When it returns a future, you can call map on that, and pass the value to the action you're wrapping. Now you have a future containing the result of your wrapped action. Turn that into an AsyncResult or just wrap the whole thing in an Async{} block and it should work.

What's best practice in this situation?

I was just writing a small asp.net web page to display a collection of objects by binding to a repeater, when this came to mind.
Basically the class I've created, let's call it 'Test', has a price property that's an integer data type (ignore the limitations of using this type, I'm just using it as an example). However I want to format this property so it displays a currency and the correct decimal places etc.
Is it best practice to have a function within the class that returns the formatted string for the object, or would it be better to have a function in the back end of my web form that operations on the object and returns the formatted string?
I've heard before that a class should contain all it's relative functions but I've also heard that presentation should be kept in the 'presentation layer' in my N-tier app.
What would be the best approach in my situation? (and apologies if I haven't explained this clearly enough!)
Thanks!
In my opinion, both options are valid from an OO point of view.
Since the value is a price (that just happens to have the wrong data type), it makes sense to put the formatting into the data class. It's not something that's specific to the web interface, and, if you develop a different kind of user interface, you are very likely to require this formatting again.
On the other hand, it's a presentation issue, so it also makes sense to put it into the presentation layer.
For general OOP stuff, the object should not be exposing implementation details. I choose to interpret this as "avoid setters and getters when possible".
In the context of your question, I suggest that you have a getPriceDisplay() method that returns a string containing the formatted price.
The actual implementation of the formatting is hidden in the implementation details. You could provide a generic function for formatting, use some backend call, or something else. Those details should make no difference to the consumer of the 'Test' object.
Though it's not an OOP approach, in my opinion, this is a good time for an extension method. Call it .ToCurrency() which has the format of the currency...this could be taken from the Web.Config file if you wanted.
Edit
To elaborate, I would simply call .ToString("your-format") (of course this could be as simple as .ToString("C") for your specific question) in the extension method. This allows you change the format throughout the UI in one place. I have found this to be very useful when dealing with DateTime formats in web applications.
Wouldn't .ToString("C"); do the job? This would be in the presentation layer I would imagine.

ASP.NET. Is it better to pass an entire entity to a method or pass each property of this entity as parameters?

We're developing a business ASP.NET application. Is it better to pass an entire entity to a method or pass each property of this entity as parameters? What is the best practice?
Case 1. Pass Customer entity to a manager - InsertCustomer(Customer cust)
Case 2. Pass each property as a parameter - InsertCustomer(string name, string address...etc)
P.S. We're using Entity Framework as our data access layer
Pass the entire entity, not only for reasons given in the other answers, but generally methods with long parameter chains are bad. They are prone to error, and tough to work with from a development standpoint (just look at Interop with Office)
In general, if I see I am getting too many parameters (usually more than three), either I have a method trying to do too much, or I explore ways of encapsulating this data in a struct.
You should pass the entire entity as when you update the entity, e.g. add or remove members you do not have to update all your method calls in all your layers. You only need to change your datalayer and the layer where you are consuming the entity. asp.net is Object Oriented and therefore you should orientate your code around your objects
The whole concept of object orientation requires objects to be passed around. If all is happening internally I would go with this.
If this is being posted to a webservice / across a network etc you would need to serialize, and hence may find it better to pass each individual parameter, especially if the receiving framework is different.
Don't forget your Strings etc are all objects too.
I agree with another poster, passing a whole entity "encapsulates" everything so that it can be updated/modified so you have less to worry about.

using reference parameter for a web method in .NET

I am working on a web application that consumes a web service. Web service is written in .NET.
I want to know whether using a reference parameter for a Web method is a good practice or not?
You can use ref and out params with WCF services, but under the hood they're wrapped up.
Anything passed to a WebMethod or service has to be serialised - you can make it behave as if it is a ref or out by wrapping it in something that sets the values back, but this is messy.
You're better off with a record class - a simple serialisable class that's basically just a list of auto properties that's the return of the WebMethod.
This results in extra classes, but is much easier to maintain.
It is best to have the ws message based.
You can still be doing so implicitly when you use multiple parameters, there is still the message you are receiving with those. Just keep them separated, if you need multiple outputs return a simple result class for the operation.

Resources