I'm working on a project that needs to send messages from a server to clients with support for both Android and iOS. For now i'm using SignalR in a C# server application with Android and iOS clients. Everything is working fine. But i'm looking for some alternatives that may be better.
I also did some research and found some examples, but there not fitting my needs.
SocketRocket (only iOS)
Alchemy Websocket (not sure if supports native iOS and Android)
I know this is an old question but in case this topic is still relevant to someone:
We have been using HTTP based requests from client to server and Google Firebase Cloud Messaging to push messages from our backend to a Xamarin iOS application (server to client) at work.
Firebase allows to:
Send notification messages that are displayed to your user. Or send data messages and determine completely what happens in your application code.
and
Add message handling, topic subscription logic, or other optional features to your client app. [...]
We mainly chose Firebase over SignalR because SignalR seemed to stop working when the application was running in the background and the managed C# threads were suspended by iOS.
Firebase turned out to be more reliable in these cases (at least in our use-case).
Although I have no experience with it, Firebase is also available on Android (it's a project by Google after all, so it is officially supported).
Saying either one being "generally better" than the other would come down to opinions and would have to be decided based on specific project requirements, but Firebase is a valid and mature alternative to SignalR in some circumstances, even though the integration with the iOS simulator does not seem to work (server side message push just fails with an exception, at least in our project).
Related
I have a C# console app that sends Push Notification to android device using Http post. following is my existing code:
sample code Using HTTP call to FCM
But now my requirement has been changed and not only sending the push message from server to android device, i also have to receive the acknowledge something from device to server i.e two way communication is needed.
The HTTP supports the one way communication( from server to client). I don't want to add an extra API which can be called from android device after receiving push either.
I came to know from the link https://firebase.google.com/docs/cloud-messaging/server that XMPP Protocol would do bidirectional support but i could not get a sample code how can i call the FCM using xmpp in C#.
*HTTP: Downstream only, cloud-to-device
XMPP: Upstream and downstream (device-to-cloud, cloud-to-device).
Can someone give me the sample code for sending push using XMPP in C# ?
It's not that easy just to receive the sample code since implementing XMPP is a huge amount of work. I myself implemented it by reading through RFC's and XEP's.
Since you have to authenticate and negotiate the connection with the server calling FCM from an own implementation is going to take even longer.
However, best thing you could and should do now, is looking for a Library on Github for example, that already implements the stuff you need.
Here are two of them, but I did not look into them:
https://github.com/ForNeVeR/Jabber-Net
https://github.com/tiagomtotti/firebaseNet
I hope they fulfill your needs.
Long story short
I am trying to discover (Android) devices from a Windows 10 computer, using WiFi Direct Services - but it seems to me that Windows and Android do not agree on the standard here.
When I write Wifi Direct Services or Wifi Direct Advertisement, I mean the feature where a WiFi Direct capable devices can broadcast what services it offers, so potential peers can scan for available devices / services before they make any connection.
Have any one had any success with this across the Windows-Android gap?
Details on what I have tried
So I have been working a bit on this, searching for documentation and examples.
Android <-> Android
Using this Service Discovery example for Android, I have had success with making two Android devices find each-other and list their available service(s) before any actual WiFi Direct connection was made.
The way it works is that a device that want to find other devices (services) will broadcast probe requests. A device publishing a service will then see these probe requests and respond with a probe answer. The probe answer include Bonjour(-like) information informing the first device about available services. This is (similar to) active scanning.
Enter Windows 10
I have been playing with the WiFi Direct Services example project (and others) from Microsoft - but without the big success. Windows is able to see the Android device(s) but
only if the Android device is in Service Discovery mode (i.e. sending out probe requests)
Windows is only able to see the device, not which services it provides.
Basically my conclusion (a bit of guessing) is that Windows 10 uses passive scanning and thus (erroneously?) reacts to the probe requests of the Android devices (when Windows should actually send out probe requests itself and react to probe responses).
So, actual question
I am having trouble forming one clear question, sorry, but
Has anybody successfully made a service discovery between Android and Windows?
Does anybody have any insight into how Windows (10) works here? Can I make Windows use the active scanning mode and parse the service announcements?
Other hints that will help on my way is greatly appreciated :-)
Just for some context to anyone finding this question, the Windows API you linked uses a Wi-Fi Alliance standard called Wi-Fi Peer-to-Peer Services (P2Ps) for service discovery in probe requests and responses. A service is advertised and discovered over Probe Response frames when a matching hash is included in a Probe Request frame. The services may also be discovered over ANQP/GAS frames with the type P2Ps.
The Android API uses service discovery as defined in the Wi-Fi Alliance Wi-Fi Peer-to-Peer (P2P) standard. This is a form of service discovery that predates P2Ps. It uses ANQP/GAS frames with the type Bonjour or UPnP.
Both methods are valid and standards based, but they are not compatible with one another. The closest you can (likely) get to compatibility is by using Wi-Fi Direct and no service discovery (you can only see device names essentially at discovery time, rather than a "service").
Windows sample: https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/WiFiDirect
Android sample: https://developer.android.com/training/connect-devices-wirelessly/wifi-direct.html
I have done this using an Apple Bonjour server running on the Windows side (Bonjour == Apple's implementation of Zero Configuration Networking).
The catch is that I had to use Mono.Zeroconf library to pull it off http://www.mono-project.com/archived/monozeroconf/, and it's a little off the well-trod path because the most popular libraries for this on Windows side are client only and do not allow for registration as a service provider. Also, and as an added surprise, the source in this project hadn't been recompiled recently when I found it. It works though -- I just had to recompile it to get it working with .Net46.
Anyway, the operative point is that Android's Network Service Discovery is interoperable with ZeroConf as they are both DNS-SD based and I've been quite happy with the results after finding out most android devices don't do MultiCasting
I'm creating an ios application using swift for the client and C# for the server. I currently have a web app hosted in azure that communicate with the client via web api. Now I need to employ push notifications
I'm looking at Azure tutorials as my push notification provider, but it seems that it only cares about sending mass broadcasting. My need is to send custom notifications per user/device for specific notification such as "someone liked your profile" or "someone wants to connect with you" or that sort of 1-1 notifications. But look at azure example here at the section: Update server project to send push notifications (.Net) #3, there is no indication of sending a message to only one device, but rather to any device who connect to the specific hub.
So, I think the azure tutorials are not what I am looking for.
look at this lean code: He doesn't seem to be relying on any server like azure to send his notification. He is not using a hub either. He is just sending everything from a TcpClient and his notification is direct at 1 device like need it (note the deviceID he is receiving). But I've read that you must use an APNS provider all the time, so, where is his?
so, do I have to use Azure (if I want to stick to MS) to do 1-1 push notification? Does it support that? Any good tutorial about that? Or I don't need it and just simple block of C# is enough?
(I would try the code in option #2 out, but I have to setup the certificate and report back before being allocated more time)
after much investigation and trials, I found out that I don't have to rely on azure, its push notification or anything like that. I can do the entire thing by executing C# code like #2.
All I had to do is setup the .p12 certificate and give it a password. Bring it over from Mac to my pc and executed the C# code and was able to receive notifications on my phone.
My client are currently using Google Cloud Messaging (GCM).
I've been researching this for a while but I only seem to find examples on how to send push notification with GCM to android devices using C# but I can't find anything regarding receiving/capturing push notification sent from GCM to a UWP Windows 10 application?
Is this is possible?
Can it be done without having to use Azure? I've just checked and I can see that you can set up GCM in the notification hub in Azure but my client doesn't want to use Azure if at all possible and just stick to GCM
Google Cloud Messaging is an Android only Service by Google. Every OS has it's own similar Service and they are not intoperatable.
While it would be a really cool thing to have a cross platform Notification Service, I wouldn't bet on it to happen anytime soon. Notifications are deeply integrated into the OS for reasons like battery saving and security.
All current notification Systems work very similar and sending messages to them is mostly just sending some json/xml via Http. All you have to do is distinguish between android and windows targets when sending your notification and then either post it to gmc or wns.
Find information on WNS here.
Azure Notification Hubs are just a service that do exactly that for you, so you don't have to code it yourself (with some other nice extras), but they are not required to use WNS.
I am using WCF to write a server that should be able to communicate with .Net clients, Android clients and possibly other types of clients.
The main type of client is a desktop application that will be written in .Net. This client will usually be on the same intranet as the server. It will make an initial call to the server to get the current state of the system and will then receive updates from the server whenever a value changes. These updates are frequent, perhaps once a second.
The Android clients will connect over the Internet. This client is also interested in updates, but it is not as critical as for the desktop client so a (less frequent) polling scenario might be acceptable.
All clients will have to login to use the services, and when connecting over the Internet the connection should be secure.
I am familiar with WCF but I am not sure what bindings are most appropriate for the scenario and what security solution to use. Also, I have not used Android, but I would like to make it as simple as possible for the person implementing the Android client to consume my services. So, what is my strategy?
with the small bit of android I have done.
the android sdk doesn't natively support soap server, you have to write it all your self.
Rest is your only option when working with WCF and android. Thats the way that Google are pushing you to develop apps.
WCF via HTTP transport is the way to go because it is not binary and does not make assumptions re all peers are .net/windows.
see this page for more info