I am writing a connected home device (alarm system) which can receive events/messages from a mobile device (e.g. a message to dismiss an alarm).
Example of a scenario (mobile device is an iphone for the sake of the example):
Connected device at home sounds alarm and notifies the iphone (using iOS push notifications, not firebase)
iphone user brings up the app, and clicks "dismiss"
connected device gets "dismiss" message and stops the alarm
I was thinking about using firebase's live database for this interaction, so the iphone app would set a db field, and the home device (which runs python) would subscribe to this field and see that it has been set.
The problem is that this is not a very clean implementation, as I would need the home device to turn off the dismiss field after it has received it, so that subsequent dismiss event can be recognized.
Essentially I am implementing messaging on top of a live database.
Is there a cleaner way to do this in firebase?
If not, is this a reasonable implementation?
Are there alternatives to firebase that take care of such a scenario?
What I really need is a web-based event-broker as-a-service...
I would suggest looking at https://github.com/firebase/firebase-queue
There are a few examples of usage on SO such as My Firebase Queue doesn't do anything after I changed to Firebase 3
Many of our developers are using Firebase with a server to perform tasks like background processing, integrating with third party APIs, or handling advanced authentication requirements. Today, we're introducing Firebase Queue, a fault-tolerant multi-worker job pipeline built on Firebase.
If you're writing your server code in Node, Firebase Queue makes it easy to handle background jobs with a worker queue. We're already using it in our private backups feature, where we reliably handle hundreds of jobs per day across multiple machines. ( https://firebase.googleblog.com/2015/05/introducing-firebase-queue_97.html )
Related
I've been researching different options for implementing messaging, specifically sending a message from the server to the client code, in React Native apps. I have found two main options: push notifications and in-app messages.
Push notifications can be implemented with services, such as Firebase and OneSignal, and work well except there is a claim that they are not very reliable and sometimes messages can get lost. The advantage of push notifications is that they work regardless of whether the app is in the foreground or background.
In-app messages can be implemented with event-bus services, such as SignalR (Azure or standalone), AWS SNS or GraphQL subscriptions. These services are pretty reliable, but this approach only works when the app is in the foreground.
However, there appears to be another option which doesn't seem to be as popular as the first two. This option involves running a native background service/process on the mobile device which participates in in-app message exchange similar to the normal in-app messaging. The background service would subscribe to SignalR or SNS or GraphQL and display a local notification on the device when it receives a message.
What are the problems with the last approach and why not prefer it over the hybrid approach (push notifications when app is in background but in-app messages when app is in foreground) which seems to be more commonly used?
Thanks!
The main limit is that mobile devices do not allow applications to keep a long-lived connection open in the background. This limit became more strongly enforced in Android 8 (Oreo) (documented here https://developer.android.com/about/versions/oreo/background#services), and this has always been true on iOS. Exceptions are made for certain VoIP applications, but generally, this rule applies to all apps.
One of the key reasons is battery life. Keeping a connection open takes a small amount of energy and if a user had dozens of apps like this, then it would be a noticeable issue. As a result, both Google and Apple have standardized around having a single connection open to the device that all notifications are delivered through.
For what it's worth, iOS notifications are actually very reliable and consistent. Android is more problematic due to modifications made by various OEMs. (documented here: https://dontkillmyapp.com/)
One workaround is that you could distribute an application outside of the Google Play Store that bypassed this limitation by requesting special permissions, however, it would still be affected by the OEM issues just like FCM is and likely worse.
I am coding a vue.js app using web pushes with Firebase Cloud Messaging and I wondered if it was possible to send a web push to a user and in case the user was offline, to somehow store it for later display when the user opens the app again. Is there a principled approach to this problem, i.e. managing web pushes when the end user is offline?
The reason I am asking this is that, so far, all the web push notifications I've committed to FCM server with tokens of offline clients (i.e. desktop browsers) went into oblivion. To be sure, FCM didn't try pushing the notification again when the clients went back online.
For this reason I am considering coding a self-made dispatcher to manage web push for offline clients, but I need to make sure my efforts are worth it.
updated: I am now able to display notifications sent to an offline client after coming back online using appropriate time_to_live values. However, only the latest notification is displayed. How is there any specific reason why?
FCM's default behavior is exactly like that. From the docs:
If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device.
I have a xamarin forms project that uses an azure mobile service with offline sync. The iOS client is working perfectly in that it can save things locally and sync in the background. The context of my app is a game scorekeeper. So, there are two players involved both scoring on the single device.
What I would like to happen is for the "visiting" player or the player who doesn't own the device in use (ie not the primary user) to have their device sync when new data is pushed from the device in use.
Device A pushes new content, Device B somehow knows to pull new content.
This could open the door for each player to score on their own devices in a future version.
Anyway, the question is how do I tell device B to pull? Do I use APN type notification and that triggers a sync, or SignalR to tell it to sync?
The best approach on sync scenarios like this is to have your background sync process going at set intervals but then also trigger your sync process from a specific Push Notification.
If you send a Push Notification with a "special" payload (i.e. meaning something that just means to sync to your code). Then start the sync once the device receives that.
This article might help with Azure Push Notifications with Xamarin Forms: http://www.xamarinhelp.com/push-notifications/
So my requirements in mind are I have an application continuously running on a phone and I need to be able to push events to this application from time to time.
The application will primarily pull data from the server but sometimes the server will have urgent data it needs to send to the phone. I also have as a requirement to send the notification to a very specific phone, which the application will have a unique identifier associated with that phone. So I'm not looking for a simple broadcast solution.
Polling a web service by the application on a frequent time interval seems like it would impact a data plan too much, plus battery usage of the device. So I'd like to avoid a polling solution if possible.
What would be a good way to accomplish this?
I recently used PubNub to send push notifications to a web app in lieu of Web Sockets. PubNub has SDKs for all sorts of languages. Their long polling method is extremely fast and efficient. You can map messages to different devices based on the UUID of the channel. At first it seems like a simple broadcast solution (and Pubnub can be used this way), but we were able to create unique sessions with a relative amount of ease.
http://www.pubnub.com/developers/
I do not quite understand if you want to build the application yourself or if you are looking for one.
I use Pushover to do this. Pushover runs on Android, iPhone, iPad, and Desktop. It supports multiple message priorities. You can do a http POST with a unique ID and message to send a message to a unique device.
Pushover has it's own API and is really easy to use.
Polling can indeed be costly in terms of data and battery. The most efficient way to send data from the server to a phone is using Push Notifications (iOS) or Google Cloud Messaging (Android). Both notification types can be implemented directly by the developer or by making use of an API.
Golgi is an SDK that produces custom type safe communication APIs. The APIs produced have full support for both Push Notifications and Google Cloud Messaging.
I want to collect device attributes and send them to the mdm server using push notification.
Steps involved are:
create a configuration profile with mdm payload
get device token
use apple push notification service to send a notification to the device.
get back device attributes
do same with multiple devices which the company manages
Questions:
Will the user always need to act on a message or I can send a message onto the device without user action and get the work done?
Do I need an app on the device to send back the token?
It sounds like you're trying to use push notifications to poll iOS devices and return information.
Push notifications do not provide a mechanism to execute code on a device without user interaction. You would have to have an application loaded on the device, and the user would have to click through from the notification to your app.
In iOS, applications generally don't run unless the user is actively interacting with them. There are a few exceptions (e.g. background audio.)
You do need to have an app running to get the device token. You call registerForRemoteNotificationTypes. See APNs docs for more information.
Edited to add more information:
Looks like the MDM protocol uses push notifications to do just what you describe. However, there's nothing about it in Apple's "Local and Push Notification Programming Guide" (linked above).
Apparently Apple keeps tight control over the MDM documentation (see here and here).
However, I did find this paper from blackhat describing how the system works.
My earlier point about not executing arbitrary code on a device without user interaction still applies. There's a finite set of commands that can be executed (see Appendix A).
I came across this question when searching for iOS push notification access payload without user interaction - Just want to add that, in iOS 7 and above, it is possible to send silent push notifications to app, and app can process them without user interaction.
However, I've also found some discussions saying that the silent push notifications are not delivered reliably, in this SO post. That's why I'm still looking for alternate ways to retrieve payloads of the normal remote push notifications. Doesn't look like there's a way.