Xamarin and Push Notifications - Reason to use Azure Notification Hubs? - firebase

Good afternoon,
I apologize in advance, as I know this is subjective. But, I'd very much love the opinion of a Xamarin expert.
I'm building a mobile application for a client using Xamarin targeting Android and iOS devices. We have a .NET Web API back-end application that is consumed by a MVC web application (hosted in Azure), and now our Xamarin application. Our API needs to send basic push notifications (to iOS and Android) when certain things happen.
I've configured push notifications (also targeting Xamarin projects) in the past, but it has been a few years. That configuration included Azure Notification Hubs and GCM (the GCM piece was recently updated to Firebase - still in combination with Azure Notification Hubs). All of that is working just fine.
After reviewing push notifications again, it seems as though Firebase has become something of a Notification Hub itself, handling both iOS and Android applications. There is plenty of documentation on setting up push notifications in a variety of ways, using just Firebase for both iOS and Android, using Firebase with Azure, using just Azure for iOS, etc.
So, my question is.. If you are a seasoned Xamarin developer creating a new iOS and Android targeted application with a .NET backend, would you use Azure Notification Hubs? Based on my reading, it seems as though the simplest approach would be to utilize Firebase for both iOS and Android, leave out the Azure Notification Hub piece of it, and use our back-end to make a single POST request to the Google API (i.e. https://fcm.googleapis.com/v1/projects/myproject-b5ae1/messages:send based on their documentation at https://firebase.google.com/docs/cloud-messaging/send-message) to send a new push notification.
However, that doesn't sit very well with me considering that Microsoft is behind both Xamarin and Azure. My gut is telling me that I should be using Azure Notification Hubs. Could someone please provide some guidance? I feel like I'm not understanding something that's preventing me from being able to come to a good conclusion on my own.
Thanks,
Chandler

This seems to be a problem with the software architecture. Technically, notifications can be done for both Azure and IOS/Android notifications. But from user data statistics and future data service analysis, you need to consider whether the notification service you used before can continue to provide services for you. At the same time, if you are ready to abandon the previous use, you can slowly split some users to use the new notification service. From my personal point of view, this is the safest.

Related

Push notification in xamarin.forms

I asking this question for clarification about push notification in xamarin. I have a xamarin.forms app which will display certain items in list view.The back-end of my app is in .Net. The items which shows in list view inside app is added from back-end.What I am trying to achieve is whenever items add in back-end, I want to receive notification in my app.
For the notification part I found two options.
FirebasePlugin Link
Azure push notification
I need some clarifications about
Which way should I follow? Is there any other cost effective way to implement push notifications in ios and android in cross platform way(Xamarin.forms)?
For implementing push notifications in ios ,is APN certificate is mandatory? Currently I don't have apple developer account.So for testing notification in ios seems difficult.
Any help or guidance is appreciated
Which way should I follow? Is there any other cost effective way to implement push notifications in ios and android in cross platform way(Xamarin.forms)?
From my experience the easiest way for me was to use firebase console to manage notifications both for Android and iOS. I have similar platform that uses push notifications to users whenever webapp database is updated, by certain users. To my disappointment Azure Push were more complicated to manage.
For implementing push notifications in ios ,is APN certificate is mandatory? Currently I don't have apple developer account.So for testing notification in ios seems difficult. Any help or guidance is appreciated
Yes. Apple developer account is mandatory. Moreover you cannot test your push notifications on iOS emulator. You must use physical device.
App Center Push is what I've started using now. Push services are free (which is great) and they have Xamarin SDKs which handle most of the platform specific config so it's really quick to get push working.
As the other answer has stated, you will still need an apple developer account and physical device to test on iOS.
It's part of the the Microsoft App Center offering which provides many other useful services for mobile development.
#groveale App Center Push feature is being retired(https://learn.microsoft.com/en-us/appcenter/push/) so I would suggest using firebase or the implementation provided by xamarin docs.

Why use a push notification service over a Web Push library?

I'm planning to add push notifications to my web app.
As far as I understand it, to push notifications to my users, I can either use a web push library and deliver the notifications directly, or use a push notification service such as OneSignal, Firebase Cloud Messaging, or Batch.com.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
If I'm focusing only on Web Push for now, is there any advantage I should be aware of, to use one of these services over a web push library directly?
Web Push is a standard which is still under development and subject to change. Also browser support is quite limited at the moment (see https://caniuse.com/#feat=push-api).
The advantage is: you have one API to rule all the supporting platforms (including desktop).
Disadvantage is: You have to be aware that not all platforms support the standard.
Using a notification SaaS solution to handle notifications enables you to handle all platforms. Sending out a notification from your backend will be a single call to your notification SaaS service, but you still have to be aware, when you want to have native notifications on Android, iOS and the browser, you will have to handle the integration of those platforms differently in your client apps (see example here using Google Cloud Message integration in an Android App: https://firebase.google.com/docs/cloud-messaging/android/client).
So your decision should be based on which platforms you have to support.
- If you get away with supporting Chrome, Firefox and Edge browsers on non-iOS-Devices (or handle iOS Notifications differently), you can use Web Push.
- Otherwise i would choose a Notification SaaS Solution.
The most important point for me personally when doing your own implementation is that you control everything. This means that your notifications don't fail when AWS loses a region or pricing changes and you can't afford it any more. Not any provider can ban you because of the content you distribute or the complaints from users. You can implement your own logic for showing the notifications on the front-end, like stacking them or having your own segmentation rules (paying users versus free tier, for instance). I'm not even speaking of the custom subscription UI. No weird copyright in your messages.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
When you've got the server logic to process the app events and send notifications in place, it shouldn't be really hard to extent it do work with mobile push notifications. The only thing that changes is the way you subscribe devices.
And the last, but not the least - it's fun to develop. This is more of a personal matter, I guess, but I like learning new thing :)
Hope that helps you to make a decision.
you can implement push notification to your website without using third-party libraries. You have required to get subscription token from the client and store this subscription token onto the server (Inside database). After when you want to send a push notification to the user then you have to just call endpoint (endpoint is mentioned in subscription token). That's it.
Due to security risk and managing subscription tokens, developers prefer to use firebase, AWS push notification or onesignal.com services. These services are optional you don't need at all.
Read links introduction to push notification and also the same lab code examples. Later I will update with simple working code for further reference to your question.
It depends on what you want. It‘s not possible to use iOS Safari for Web-Push. For notifications to iOS you have to use a service or build your own app.
I use Pushover for notifying myself from Scripts and Software. That may or may not be a solution depending on how much users you have, how many notifications you send and how willing your users are to use a web app like Pushover (or an app on iOS).
A service will keep notifications going when things change. So it should be less maintenance for you.
If you want to target iOS visitors also, this is not possible, as web push notifications are not supported by iOS.
To circumvent this, you need to use a third party service like Wise Notifications.
The alternative is to build an iOS app and send native push notifications.

Push notifications: Why use Amazon SNS over Google's GCM/FCM?

I have created a mobile app for Android and iOS using Phonegap Build. Last year I had nearly finished writing code to use GCM (Google Cloud Messaging) for remote push notifications - which can go out via Apple's APNS too - but the project was shelved.
This year the project is resurrected and I find Google has changed everything to Firebase (FCM). I then read some enticing things about Amazon SNS handling notifications. Just when I started to think SNS might be a better option, I noticed you still have to set up GCM/FCM anyway, and pass all those details to SNS.
So is there any benefit to using SNS when I've got to do the full FCM setup as well?! Both services seem to offer the same features: interact with APNS if required, subscribe to topics, provide you with a nice API/SDK, etc. The app code, and the server-side code would be no simpler, as far as I can see. Why add another layer (SNS) on top of FCM?
(I'm trying not to let this be an opinion-based question: I want to know whether SNS is saving me any effort, giving me any advantage, or adding any features that FCM does not have.)
Just some thoughts.
If you are already using some mobile AWS SDK, then it's more convenient to use it for SNS too.
That also helps keep your app smaller.
And you're happier as a developer since API calls are somewhat unified.
If your backend is hosted on AWS infrastructure you can use IAM roles for EC2 instances (also Lambdas etc.) to make those call without access key/secret key.
You get metrics in your CloudWatch.
But Firebase Cloud Messaging is free :)
Let's answer a few questions first.
1.Do you want to develop, maintain and run the code to talk to GCM?
2.Do you wish to do the same for another platform (iOS, Kindle Fire), if you choose to develop your app for other mobile platforms.
3.Do you want to manage change of registration_id's by yourself?
4.Do you care if a notification is delivered to your users a few milliseconds later?
If you answered NO to any of the questions above, I recommend using SNS to deliver push notifications to iOS, Android and Kindle Fire devices.
SNS talks to GCM to deliver notifications to android devices. Here is what SNS can offer you.
Simple API to send notification to heterogeneous platforms.
Manages application registration_ids. As a developer you don't have to worry about change of registration_ids.
Scales really well. You don't have to worry about managing infrastructure if your app becomes super popular.
Can tolerate GCM downtime & throttling.

Phonegap notification options that work for both for iOS and Android

I am building mobile apps for iOS and Android using PhoneGap Build. I would like to send push notifications to both types of device using the same server-side process. Is this possible?
Apple's certification process to enable push notifications is painful, much more so than anything available for Android. Do I have to use it?
GCM (Google Cloud Messaging) says it supports both operating systems, but the more I read about it - with respect to Phonegap - the less I see iOS mentioned! And sadly the GCM/Phonegap plugin doesn't support subscribing to a topic, which is a way of sending one message out to all devices in one go via a 'global' topic.
UrbanAirship and PushWhoosh seem to integrate with Phonegap, but I am forced to use their website to create my messages. GCM looks more attractive in this respect, because I can get our own ASP.NET server to talk to GCM via HTTP and thus control messages from our databases.
Main question: Are there any options for a single server-side option which can send push notifications to both iOS and Android via a single Phonegap plugin? (Ideally I would control messages from my own server, where one message can go to all Android/iOS devices in one go, and avoid as many Apple certificates as possible.~)

Signal R Vs Push Notifications for real time applications like Chat

I want to create a chat application for ios, android and windows phones as well as it should work with browsers in the future. My search led me to using Signal R with Azure Mobile Services(AMS).
My questions:
1) SignalR uses Websockets under the hood. Is websocket supported in Android, IOS, windows phones and all mobile/desktop browsers??
2) If not, how will it effect using SignalR with AMS?
3) Or should I just use Push notifications supported in AMS?
4) Any sample app/code snippet you can share. Note that I will be using Xamarin for my app development.
5) Any advice you can give for same.
Azure Mobile Services has SignalR integrated, and Azure Mobile Services provide a SDK for client apps, I suppose it is provide out-of-the box
See
Real-time with ASP.NET SignalR and Azure Mobile .NET Backend
Master the Managed Azure Mobile Services Backend–Part Four
High value mobile backend capabilities included
You will find many capabilities included in Mobile Services and readily available for your Web API. Mobile push notifications, real-time notifications with SignalR (auto-scaled out), social auth for your consumer apps, offline data sync for occasionally connected scenarios, to name a few.
Samples:
https://github.com/gshackles/RealTimeGallery
Sample to help developers to implement Push Notification, through Azure Notification Hubs, in mobile applications.
Note:
Azure Mobile Service is based in WebAPI!
For that you want, you should not use only Push Notification because Push Notification in iOS could not be read by the application if the user ignore it, only in android or windows you can get and save it. Another thing that can be a problem is the fact if the app is running you should not show the push notification and you should show a pop up with the notification... and the push notification can have a delay from the Push Notification Service (Apple, GCM, WNS...). Push notification are a notification that something happened in the app when the user is not using it.
In my opinion you should use AMS+SignalR for realtime communication and then Push Notification for update the user then he not using the app.
Using SignalR is efficient to save yourself from hitting any push notification cap if you ant to limit your costs. But you'll need to either turn notifications on/off at the right time when the app becomes active or inactive, otherwise the app may go in the background and push notifications won't be sent.
You can use a pure push approach where notifications are shown when the app is inactive/in the background, and whenthe app is active, you simply intercept the notification in the app, consume it and cancel it so it doesn't get shown. I have written a blog post on this approach along with 3 samples in Github for iOS, Android and Windows Universal at http://www.ageofmobility.com/2014/10/06/azurechatr-building-a-cross-platform-chat-app-for-windows-ios-android/.

Resources