I am currently trying to find a solution on how to create (not consume!!!) a RESTful service with Xamarin for Android and on Windows Phone. I already searched for it, but only found libraries and solutions on how to consume a RESTful webservice on those platforms.
Do you know any good library to create a webservice on those platforms or any hints on how to implement a simple werbservice (not using ASP.NET)?
TIA Octo
The Xamarin.NET and WinRT frameworks (and their package ecosystems) have pretty comprehensive support for web services etc. from a client perspective, but not so much if you want to act as the host. You can't install something like webapi or signalr host into a PCL, or even the native platform projects.
Based on your clarification comments, I would suggest one of the two approaches below. I will assume that the RESTful requirement is more of a "nice to have", and the "calling methods with parameters and getting results" is the priority.
1. Make the mobile apps clients too - remove the hosting requirement from the mobile devices by adding a hub on another server with the full .NET profile. Both your mobile apps and your "test runner" connect to this and the hub routes the messages between them. SignalR would handle this easily. This option is not at all RESTful and requires an additional server, but is quick to get up and running and will easily support your desire to pass json messages back and forth.
2. Go lower level - Use sockets to facilitate communication directly between the mobile devices and "test runner". The mobile devices can open sockets for listening, and your "test runner" connects to them direct. Again, not RESTful and a bit more involved - you need to define a (hopefully) simple protocol (e.g. {length of type name}{type name}{length of payload}{payload}) and use that to send send and receive json - but it avoids needing a middle machine for routing.
Related
I'm trying to create a new application from the ground up. I've used SignalR and WebAPI. I believe I know a lot of the differences, but isn't SignalR faster since it uses websockets? WebAPI makes sense to me for external frameworks to be able to reuse. SignalR makes sense to me for anything I'm not necessarily going to use externally. I've done some research and I can't find anywhere it says you shouldn't. I realize this is somewhat opinion-based, but why would you use a mix of the two rather than just SignalR?
I think what I'm mostly asking is if it is wrong to use SignalR to send back to the caller, except in cases where I would send to other clients on that channel? To me SignalR can be used like WebAPI when you are just sending back to the client. Is that wrong to do? It is less code for the client calls(2 lines vs 6 or more, depending on what I'm doing with it). My thinking is I may be trying to manipulate data and send it to the caller now, but maybe I want to send it to all clients later or send a notification to all clients. I'm not a fan of using signalR calls in my webApi controllers. It just feels like the signalR calls should be in the Hub. Thanks for your help.
There is no reason why you shouldn't use them together because they target two different problems. Web-API is a means of making web services easy to target by many different kind of apps/devices whereas SignalR offers bi-directional communications in a way that the Server can call a piece of code on the client without the client having to keep polling the server for results.
E.g. Instead of having a client keep asking the Server for any new messages (like facebook notifications) with SignalR the server knows that there are new notifications for a specific client and it can send them directly without the client having to ask for them.
http://www.asp.net/web-api
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework.
http://www.asp.net/signalr
ASP.NET SignalR is a new library for ASP.NET developers that makes
developing real-time web functionality easy. SignalR allows
bi-directional communication between server and client. Servers can
now push content to connected clients instantly as it becomes
available. SignalR supports Web Sockets, and falls back to other
compatible techniques for older browsers. SignalR includes APIs for
connection management (for instance, connect and disconnect events),
grouping connections, and authorization.
A potential problem is that while SignalR is great at targeting JavaScript code on a client, Web-Api enables connectivity with all sorts of platforms and devices. So the same techniques used through SignalR to target Web Browsers, will not necessarily work on a native Android App.
You can use them together depending on your application needs. I recommend you look at difference between HTTP and WebSockets protocols. WebApi uses HTTP(S), SignalR mostly WebSockets and in some cases others transports. They both have benefits and disadvantages. The main benefits of using SignalR are duplex bidirectional communication as mentioned above and low traffic overheads. Browsers send as a rule a few KB data in HTTP headers and cookies for every request.
It’s easier to use RESTfull services (HTTP) from browsers, HTTP clients, tools, languages and so on instead of using WebSockets. Google Chrome supports monitoring WebSockets traffic but very poorly and Microsoft Edge doesn’t.
Many tools like Google Analytics and Microsoft Azure Application Insights can monitor errors in HTTP requests but can’t do this for WebSockets. You need to implement monitoring manually. Actually WebSockets traffic is simple messages from client to server and vise versa, no additional information. SignalR has some wrappers for this - some kind of error message format.
WebSockets also use more server resources because of keeping open TCP connection and it’s harder to scale web applications that use WebSockets. For instance if you have 100K online users it means you have to be able to keep 100K TCP connections. For HTTP – not necessary. For some very simple sceneries you can replace SignalR with some kind of client polling, but be careful that’s approach may bring a lot of problems.
So, If you don’t need bidirectional communication and traffic overhead (as a rule a few KB per request) is not a big deal then use WebApi only.
If you need bidirectional communication you can use SignalR for server to client push notifications and WebApi for client to server requests simply to ease development, scaling, debugging and using API from other sources. But you also can use SignalR only if you are ok with disadvantages of it or traffic overhead is big for you.
I'm new in Mobile dev. Going to use C#. I'm going to write small android(maybe iOs in the future) app. And I can't figure out what I need to use as web server. I want mobile client to send requests to server and get result from it. Best idea I have - use WCF web service and json.
Is it a good idea?
What can I use except WCF?
What could I read about web servers for mobile application?
P.S. Link for some tutorial will be great.
There are tonnes of tutorials out there on this topic.
I would use socket connections
For C# you can create a TCP Listener using sockets
using System.Net.Sockets;
https://msdn.microsoft.com/en-GB/library/bb397809(v=vs.90).aspx
and like wise for the android
TCP sockets would be an easy implementation.
http://examples.javacodegeeks.com/android/core/socket-core/android-socket-example/
As for Android and connectivity.
the Android developer platform is always a good start.
developer.android.com/training/building-connectivity.html
Or you could create a Rest interface in c#
codeproject.com/Articles/112470/Developing-a-REST-Web-Service-using-C-A-walkthroug
and make a http call in android. depends on your intended application to what will be better for you
Why REST + JSON is preferred over SOAP for mobile web services
http://www.bamboorocketapps.com/rest-json-vs-soap-xml/
I want to create an Instant Messaging app for Windows Phone.
I have found some information about Live SDK, but it looks like the messenger api is outdated?
Can anyone help me start? All I want to do at first is embed the IM.
A simple IM app where the user logs in with their Live ID, sees who already has the app (Live Contacts) and an IM-service with a UI like the SMS-service in windows phone.
Can anyone help me get started?
Firstly i hope i got your question right.
I have multiple lookouts for you:
XMPP (Jabber): start from there. It is fairly simple, and there are opensource clients out there where you can dismantle code and learn by understanding what others have done.
Check out the SignalR
ASP.NET SignalR is a new library for ASP.NET developers that makes it incredibly simple to add real-time web functionality to your applications. It's the ability to have your server-side code push content to the connected clients as it happens, in real-time.
You may have heard of WebSockets, a new HTML5 API that enables bi-directional communication between the browser and server. SignalR will use WebSockets under the covers when it's available, and gracefully fallback to other techniques and technologies when it isn't, while your application code stays the same.
SignalR also provides a very simple, high-level API for doing server to client RPC (call JavaScript functions in your clients' browsers from server-side .NET code) in your ASP.NET application, as well as adding useful hooks for connection management, e.g. connect/disconnect events, grouping connections, authorization.
I have an asmx web service that hosts various data, and now I want to send live tile updates from the web service. I have understood that push notifications can be sent from cloud to WSN, but I haven't really found any good examples for custom web services. Any ideas how this can be implemented?
In addition to the great references already provided I wanted to speak specifically to the use of "custom web services." In a greenfield push notification scenario, I'd strongly recommend looking at Windows Azure Mobile Services (WAMS) which abstracts much of the underlying REST/HTTP/OAuth choreography AND provides the benefit that it's backed by the Windows Azure cloud architecture (pay for what you use, failover, data backup etc.)
Given you already have a service, you may or may not decide the benefits of WAMS are worth the code changes/migration it would require. Should you want to continue with the service you have, you will end up doing a bit of grunt work yourself - using OAuth to authenticate with WNS, etc. It's not rocket surgery, but it's tedious :) The Windows Azure Toolkit for Windows 8 did include a recipe for doing all that, but it's now deprecated by Windows Azure Mobile service.
I tackled the subject of doing the push notification flow from "scratch" leveraging ASP.NET (I used WebAPI but ASMX could be used as well) in Windows Azure Web Sites (which you might consider as a host for your service). There's a bit of ancillary work involved as you'll need somewhere to store the channel IDs for the notifications (I used the free MySQL instance) and you'll need to use OAuth to communicate to the WNS (I used a helper class posted as a Gist), but I cover all that end-to-end in a three-part blog series
Your server infrastructure (Windows vs. Linux) and the type of application (asmx vs. aspx) don't really have any impact on how you send the notifications. Notifications are sent as an HTTP POST from your server to the MPNS server with specially formatted XML data.
Here are two really good references to get you started:
Push Notification Overview
http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx
Sending Push Notifications
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh868244(v=win.10).aspx
Dev support, design support and more awesome goodness on the way: http://bit.ly/winappsupport
This book might be helpful. Go to Chapter 13.
http://blogs.msdn.com/b/microsoft_press/archive/2012/10/29/free-ebook-programming-windows-8-apps-with-html-css-and-javascript.aspx
I am developing a smart device application, which is going to communicate with a wcf service over wi-fi. As there is no option to add a service reference into a smart device project I decided to use the NetCFSvcUtil.exe. Everything works great!
But...
In the end I understood that the application must interact with the service in the background.
Having read this article Microsoft .NET Compact Framework Background Processing Techniques. I decided to use the Asynchronous Web Service Call. There http://msdn.microsoft.com/ru-ru/library/aa347733.aspx I found the /async parameter, but it appeared to not work for the NetCFSvcUtil.exe.
What can I do to get the async proxy for my smart device application? Is there a way to generate it or I'm expected to add async methods to the interface with my own hands? Maybe it would be suitable for .Net CF to use SvcUtil.exe to generate the async proxy in my case?
A further more information like which platform you are using to build your Smart phone application would be helpful.
I have done Blackberry development and consumed web services. There are two ways you could build your web services
RestFul Service - Consumption of web services would be pretty easy. Posting data could be a little pain as multipart form data is posted as stream in Wcf - Rest Starter Kit
Soap Service - If you decide to use SOAP, then for blackberry and Android you have to use preverified KSOAP -2 to send and receive soap messages between your app and the web service. If you decide to use KSOAP -2 , go back ASMX services. Somehow WCF services does not communicate with KSOAP -2 (due to change in SOAP version or something) where as a simple ASMX service works pretty smoothly. There are dozens of article which you could use to learn how to use KSOAP
he original idea was to host it in a windows service...
Windows Services could never be web facing. If you want any thing to be web facing, you need a Web Server !
In the end it worked. The "Add web reference" tool created a proxy with Begin/End async methods and the proxy interacted with the wcf service hosted by a simple console application (later a windows service) through the URL property of the proxy.