We Keep Coding

Incorporating Signal R into an already existing web application

From my understanding, the beauty of signal R is that it takes care of the "handshake" between the client and server to determine the best form of communciation between them (websockets, long polling, etc). I understand that by default it does this at the /signalr route. I read that before this the handshake would be accomplished with an HTTP Get request with an Upgrade/Connection header specifying to upgrade to this new connection.
In my current application we support handling many HTTP requests in a RESTful manner. If we wanted to expose some of this data in real time rather than in this request response format, what would be the best way to determine if we should open a connection using signal R? Would checking for those headers still suffice? I just feel like that is a bit redundant since signal R abstracts that away.
Instead of this, would a solution be for the client to specifically invoke a hub method to kick off the streaming as soon as he connects to the proper endpoint?
TLDR: Need a way to open a signal R connection from a HTTP request, don't know the best way to go about that whether it be from requesting the resource with custom HTTP headers or by just navigating to the url resource and having their client invoke a hub method.

A typical example of using signalr is:
an html file using JavaScript to connect to a signalr Server when the page is loaded. we call this signalr client.
a signalr server written in c#. it can be a winform or console or service.
the signalr Server can call any dll, or webservices or webapi located in the same server, or even in different Server.
then, the client can call any function defined in the signalr server. the server can call any function defined in the client for a particular client or for groups of clients.
also, client x can call client y functions as well.
I would also suggest you create this index.html inside a Cordova project, so that your client can use this app using any pc desktop browser, or any mobile phone browser, or run it as an Android or iPhone native app, by using One set of client codes.

if they navigate to some url resource instead of receiving a response with json in its body we want them to be constantly in real time using signal r receiving data
I don't think this is possible with SignalR. Reason is that all SignaR communication is done through single route (xxx.xxx.xxx.xxx/signalR) + all SignaR connections are established using handshake (By client sending negotiate request to this route. Well maybe not all - not sure if negotiation is happening in case you initialize SignalR connection object with specific transport).

What is the right way to communicate between a C# server and Windows Phone?

Ok so i have a C# server and a windows phone app that acts as a client. The client will have to modify settings on the server, receive images from the server (possibly a video stream) and receive notifications from the server (the best way would be instantaneous, like when someone sends you a message on facebook and you get the notification right away).
I have the server and client set up so they are communicating, they are sending each other an object that is serialized with XmlSerializer (it currently only contains a public String field with public get/set methods). They connect over a socket. This works well if i want to send just simple messages between them, but i assume i'll run into problems when i want to have instant notifications and transfer of images / video streams. How would i go about continuing my work in a proper way?

Consider designing an API solution via web services using RESTful or SOAP services. Personally I suggest using RESTful web services. Here are some kick start links about REST:
http://www.codeproject.com/Articles/255684/Create-and-Consume-RESTFul-Service-in-NET-Framewor
http://www.codeproject.com/Articles/148762/NET-4-0-RESTful-Web-Service-Introduction
http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa
http://msdn.microsoft.com/en-us/library/dd203052.aspx
This is another useful article in MSDN which compares WCF REST and WCF SOAP: http://msdn.microsoft.com/en-us/library/vstudio/hh273094(v=vs.100).aspx

I think if you are looking for two way communication between the client and server then using sockets is the way to go.
As for images you don't need to send the actual image. You can just pass a URL to it and then download it with one of the classes specialized for that.
For near instant notifications you could also take a look at push notifications.
Of course if you don't really need the server to push data to the client then it would be much simpler if you used a REST API as someone else suggested.

C# Traditional Server with WCF Web Service

I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar

I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.

WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.

Communication Between WCF Rest Service and host application

I have a WCF Rest web service that I am hosting in a managed application. What I would like is for client input to the service to be passed to the host application for processing, and the results are then passed back to the client. From similar questions like here and here I know I can use events to pass the data from the service to my host application. However, I cannot seem to figure out how to get the resulting data passed back to the client. Is there a way to do this using the webOperationContext or perhaps by creating another event in the host application to pass the data back to the web service?

Android and REST Web Service Response Help

The problem:
How to send data to and from a RESTful web service to an android phone. The data currently is sent in bytes and there are multiple messages sent both ways until the entire message is sent (denoted by some delimiter in byte array). It is easy to send to the web service from android using a POST to web service. The service must now send multiple responses back to android.
I am wondering if this solution would work, or if there is something better?
Suggested Solution:
After a successful post to the web service from android, the android will receive an initial response from the post function call. This response will contain a message ID. Now if that response does not have the message delimiter, then android makes a call to the POST function again with a special parameter containing it's Message ID and the web service will return the next part of the byte array. This continues until the entire message is sent.
Thanks in advance for any help. Also to note, the web service knows the phone's IP address after the first message and we must keep this connection-less (so no sockets)

REST uses a simple Request/Response mechanism. The way http works is that you send a Request, and the server sends a Response back. What you are mentioning is behaviour more like Web Sockets. You should do a little research on web sockets. They allow you to make a connection with a server from the client, and then until the connection is severed, the server can send messages to the client.