In the context of pushing notifications to web-browsers, the PUSH SERVICE acts as interface between the SERVICE WORKER and APPLICATION SERVER.
My current understanding is that
Google FCM is the Push Service for Google Chrome & FireFox browsers
APNS (Apple Push Notification Service) is the Push Service for Safari browser
Here, is it technically possible to substitute the ‘push service(s)’ (– i.e., Google FCM for Google Chrome & FireFox browsers and APNS for Safari) with a generic custom service worker which could potentially address all the popular browsers that support Service Worker and Push API?
In other words, whether developers have control over which push service to be used for a browser (or) develop a custom push service for all the browsers?
You're mostly correct: the Push Service acts as an interface between a service worker and application server, with the addition that the service worker (or potentially the web app) sends subscription info to the application server outside the Push Service, so the application server knows the endpoint and how to properly encrypt any notification content.
Google uses GCM/FCM for Chrome, and Mozilla uses its own Push Service in Firefox for desktop, while using GCM/FCM and/or its own service for Android; see the "What information does Firefox use to provide Web Push?" section here.
At the time of writing this, Chrome, Firefox and Edge support the Push API, so there's no need to handle each seperately (WebKit doesn't support it).
Short answer: developers don't have a choice in which Push Service the client uses, but the adoption of the Push API standardizes the service worker and web push across major browsers (excluding WebKit).
Related
As I looked into Google's references about smart home, I got to know that Google Home connects directly with the end device. But I wanted to specifically connects it with my gateway and sync with it so Google Assistant would only need to send command to the gateway to fulfill a user's request like "Turn on the light". Is this possible or Google need to connect to every end devices for it to work?
If you want, you can create a Hub device that talks to the Cloud and acts as a gateway to smaller, low-powered devices. In that case, you would still return all of your devices in the SYNC response but then handle all of the EXECUTE requests in your Cloud by forwarding to the Hub. From there the Hub can handle it however is needed.
Im trying to implement push notifications on Xamarin iOS project using Azure App Service Push, and I'm having problems with device failing to register.
The confusing part is this:
I've read https://adrianhall.github.io/develop-mobile-apps-with-csharp-and-azure/chapter5/concepts/
and it basically says that
The /push/installations endpoint is part of App Service Push - a feature of the Azure App Service resource. This exists on your .azurewebsites.net domain. It is not part of Notification Hubs.
However, according to this post:
https://blogs.msdn.microsoft.com/appserviceteam/2017/01/10/azure-mobile-apps-net-sdk-releases/
.AddPushNotifications() (which actually adds /push/installations endpoint)is now deprecated:
You should use the App Service Push endpoint instead. In your ASP.NET Owin Startup class, you can remove the reference to .AddPushNotifications() from the configuration.
Details here:
https://github.com/Azure/azure-mobile-apps-net-server/wiki/What-is-a-Default-Configuration%3F
If I understand correctly my App Service Mobile App, once connected to Push via Notification hub should expose some kind of endpoint for device registration but I find it unclear what that endpoint is and do i need to manually create it in mobile backend app?
.AddPushNotifications() is used to support the Azure Notification Hubs push registration endpoint via the Microsoft.Azure.Mobile.Server.Notifications package, you could check the NotificationInstallationsController.cs under the previous package. And at this point, you need to specific the Microsoft.Azure.NotificationHubs.ConnectionString app setting with the value for the connection string to your notification hub.
While the App Service Push is a feature provided by Azure Portal, and you need to go to your app service and click "Settings > Push", then choose your notification hub for your app, more details you could refer to here.
For your mobile client, you could leverage the extension method GetPush for IMobileServiceClient under MobileServiceClientExtensions.cs and the PushHttpClient.cs to send requests against push/installations for you. For more detailed code snippet, you could refer to here. Also, you could refer to adrian hall's book about using the .InvokeApiAsync() method.
I am trying send data between iOS device and backend using azure bus service .
But all the things that I found on Microsoft azure portal provide Accounts storage methods to azure or through hub providing push notifications.
I am trying to send a "Brokered message"(used for distributed systems) through a queue client using bus service Queue(FIFO). I also came across this method but found that on .net C# not for iOS even Our team here is able to send the data in .net but no luck with Mobile systems(iOS and Android)
You should be able to use REST API for Azure Service Bus from iOS or Android. There's also a good walk-through tutorial you can try.
We are using IBM Push-Notification service and Mobile-App-Security on our Bluemix app (serving iOS clients).
In order to send a push notification, our server sends a POST request to: https://mobile.ng.bluemix.net/push/v1/apps/{application-id}/messages
with the application secret in the Ibm-Application-Secret header (following the instructions here).
To initialize Mobile-App-Security SDK inside our app you need both the application-id and the application-secret - this means that the app itself must contain these values (as constant parameters or download it from a server). If a malicious user fetches these values using simple reverse-engineering, he would be able to send the same POST requests, i.e. send push notifications to other clients, right?
Shouldn't there be two application-secrets? One secret for the app (making it hard to fake registrations - i.e. require reverse-engineering) and one for the server (which allows to send notifications and should never be stored on client-side).
Is it possible to initialize the Mobile-App-Security iOS SDK without an application secret?
I understand your concern. To address all your questions:
-You must have the app secret on the Client side in order to authenticate with MAS and use the Push service (Push relies on MAS auth)
-We recommend implementing your own form of security to prevent a malicious user from easily obtaining the App Secret. For example, encrypting the file that stores the app secret, or just the app secret itself.
If you are looking for a more robust built-in level of security, I would recommend using the newer MobileFirst Services Starter, with support for Push and the Advanced Mobile Access service (AMA), which is currently only available for iOS 8.
A mobile device registers with its unique device id at the server running on Bluemix. If you don't trust a device, you could send a push notification with a key to this device and request it back. If you get this key back, the device has also registered at Google or Apple successfully.
I am using Amazon SNS Service for an iOS application that needs push notifications.
I have figured most of the things, except for the part where I have to register my device tokens.
This is where Amazon talks about it. It can be done manually or with the help of createPlatformEndpoint API which they obviously recommend for bulk uploads. My question is how we can directly register tokens from devices that will install the app later on. The documentation talks about a proxy server which I would want to avoid as of now. Isn't there a direct way of doing this, like where I can directly call a method and push the device token received in the application to my SNS Platform?
This, is a possible duplicate except that it is in reference to Android.
The AWS Mobile SDKs support accessing SNS directly from the mobile device. If you're interested in seeing code demonstrating this on iOS, we included some as a sample we prepared for re:Invent 2013 called Mobile Photo Share.
The important thing to note when accessing SNS directly from the mobile device is that you'll want to restrict the credentials delivered to the device to only those services and resources you'll need to access. You can accomplish this via web identity federation or a token vending machine with appropriately restricted policy.
If you want to learn more about the Mobile Photo Share app, we had two talks at re:Invent about the app and its architecture. The video and slides for those talks are available here:
Building Cloud-Backed Mobile Apps
Integrating Social Login Into Mobile Apps