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
Related
I'm attempting to build a live support chat application in C# using a WCF microservice and after endless searches I still can't find the answer, hopefully someone here can point me in the right direction.
My problem is that rather than a typical chat room a where users broadcast messages to all connected clients, I need the application to be more like a Live Support app found on websites such as Amazon or eBay.
Ideally multiple customer support agents will have a pre installed WinForms chat application on their machines, when a customer opens a chat window (aspx page) it will connect to a server/service and the server/service will then call all connected customer support agents until one answers. At this point the customer and agent will be connected in a private chat window.
Could somebody please give me some insight or ideas on how to do this?
Thanks,
Owen
You can use ASP.NET SignalR which is a 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.
Here you can find more details and many tutorials about SignalR.
The first resoult in google
A WCF-WPF Chat Application
Video tutorial
WCF Chat Application
ASP.NET Chatting using WCF Services and JSon
A simple peer to peer chat application using WCF netPeerTcpBinding
usefull lectures
HTML 5 Web Sockets
Always first ask google, above you have few ready to use projects that you can copy to your solution
EDIT:
Also as tip I can recommend bi-directional message queues at application level, then make index for messages with session and users identifier. Next step would be WCF with pop and push logic based on wait objects. At low cost you will need to lock queue. WCF will do heavy job. Also problems can occure inside app with proxy management and message sending so dedicated proxy for chat would be great and safest idea. And read about Duplex Services that can be usefull here DUPLEX SERVICE
These are my findings, not checked though:
Live Support Chat using SignalR
Parle
A tutorial from ASP.NET team:
Real-time chat with SignalR 2
The first one looks very early development stage, Parle is somewhat more promising.
Anyway, since I continue my research on the topic maybe I'd need to augment my answer. Until then the links could be a good starting point.
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.
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.
Hey i have been developing a windows 8 desktop app using XAML and C#. I have to implement push notification functionality in it. But i cannot keep my database on cloud due to some security reasons. Is there any other solution so that i can keep my database inside my network only but still can write mobile service to implement push notifications. Any link or suggestion is welcome.
Typically in push notification scenarios there are three pieces:
App.
Cloud Service.
Push Notification Service
Where the app registers for notifications, passes the registration to the cloud service which can then use the PNS to send notifications.
However the Cloud Service component doesn't need to be in "the cloud" it can be anywhere the client app can connect to and send the registration. It's just a web service hosted somewhere, be in a cloud platform, your own hosting etc.
There is a company that provides this service for you for free called Notice Software. They provide push within apps at not cost and handle the cloud interaction etc. I think the product site is NativePush.com....also used UrbanAirship but not sure I want to pay that much! Frees always best :)
I am currently in the planning stages for a fairly comprehensive rewrite of one of our core (commercial) software offerings, and I am looking for a bit of advice.
Our current software is a business management package written in Winforms (originally in .NET 2.0, but has transitioned into 4.0 so far) that communicates directly with a SQL Server backend. There is also a very simple ASP.NET Webforms website that provides some basic functionality for users on the road. Each of our customers has to expose this site (and a couple of existing ASMX web services) to the world in order to make use of it, and we're beginning to outgrow this setup.
As we rewrite this package, we have decided that it would be best if we made the package more accessible from the outside, as well as providing our customers with the option of allowing us to host their data (we haven't decided on a provider) rather than requiring them to host SQL Server, SQL Server Reporting Services, and IIS on the premises.
Right now, our plan is to rewrite the existing Winforms application using WPF, as well as provide a much richer client experience over the web. Going forward, however, our customers have expressed an interest in using tablets, so we're going to need to support iOS and Android native applications as clients, as well.
The combination of our desire to offer off-site hosting (without having to use a VPN architecture) and support clients on platforms that are outside of the .NET ecosystem has led us to the conclusion that all of our client-server communication should take place through our own service rather than using the SQL Server client (since we don't want to expose that to the world and SQL Server drivers do not exist, to my knowledge, for some of those platforms).
Right now, our options as I see them are:
Write a completely custom service that uses TCP sockets and write everything (authentication, session management, serialization, etc.) from scratch. This is what I know the most about, but my assumption is that there's something better.
Use a WCF service for transport, and either take care of authentication and/or session management myself, or use something like durable services for session management
My basic question is this:
What would be the most appropriate choice of overall architecture, as well as specific features like ASP.NET authentication or Durable Services, to provide a stateful, persistent service to WPF, ASP.NET, iOS, and Android clients?
(I am working on the assumption that by "stateful" you mean session-based).
I guess one big question is: Do you want to use SOAP in your messaging stack?
You may be loathe to, as often there is no out-of-box support for SOAP on mobile platforms (see: How to call a web service with Android). No doubt its similarly painful with iOS. Calling SOAP from a browser ("ASP.NET") can't be fun. I'm not even sure its possible!
Unfortunately if you aren't using SOAP, then that quickly rules out most of WCFs standard Bindings. Of the one that remains, "Web HTTP", sessions are not supported because obviously HTTP is a stateless protocol. You can actually add session support by hand using a solution based on Cookies.
You could use the TCP transport (it supports sessions), and build you own channel stack to support a non-SOAP encoding (for example protocol-buffers), but even then you need to be careful because the TCP transport places special 'framing' bytes in it, so that would make interop non-trivial.
What sort of state do you need to store in your sessions? Maybe there are alternative approaches?
1) consider stateful utility services using singletons, but keep the request/response pattern at the facade level stateless.
2) consider distributed caching, perhaps Windows Server AppFabric Cache.