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.
Related
In Urban Airship, when I am composing a notification, I can target specific users by searching for a Urban Airship channel_id (device ID):
I sent from Urban Airship the push notification that I am showing above, and I received it successfully. Now I want to do the same thing, send a push notification to a specific device, but now using the Firebase console. The problem is that in Firebase, in the step where I need to specify the target, it only allows me to choose User segment or topic. I was expecting to see a third option: Target specific users (for sending notifications to one or many specific GCM/FCM device token IDs. So my alternative is to add a GCM/FCM device token ID to a topic and then send the push notification to that topic, which is something that I have successfully done before. Nonetheless, that would be a workaround and not the way I would prefer to do this. Is it possible to send push notifications to specific users (by defining the target GCM/FCM device token IDs) from the Firebase console? Thank you.
UPDATE 1: See how the Firebase console (https://console.firebase.google.com/) only shows User segment and Topic as the Target:
First Step:
Second Step:
Third Step:
By design, the notification feature in the console is for sending out broadcast-type events. Sending user-specific alerts would be more of a programmatic operation done through the API.
For sending test messages, there is a console tool for this, explained here.
Note that it is possible to send a notification to one device by subscribing a device to any topic and sending the notification to that topic in the console (keep in mind topics are public and you can't prevent users from signing up to them; fine for testing most likely).
Another alternative is to send a message via HTTP or curl. Perhaps the best resource for this is the quickstart/messaging example.
I am building my app using Ionic3 and Firebase. Here users can send eatch other messages. I want when a use sends a message to another ures he/she should get a notification in the phone even when the app is closed. I have no idea how to achieve this with Ionic3.
Any suggesions please.
I can see there are mainly 2 plugins for push notifications. cordova-plugin-firebase and cordova-plugin-fcm
At least I can fine some tutorial for cordova-plugin-fcm in the internet. There is no clear example of any wayout given for cordova-plugin-firebase.
You have to use the cordova-plugin-firebase and each time a user logs in using a device, a unique device ID will be registered with respect to that device. This device ID is used to send notifications. Make sure to handle this (device ID), every time a user logs in & logs out. If you do not remove the device_id from the database when a user logs out, he will continue to receive notifications.
You have to use a cordova-plugin for sending push notifications. One of the many available plugins is: cordova-plugin-firebase. This one is a good fit for Ionic 3 because there is an ionic-native wrapper available.
For sending the push notification you can use a third party service (there is also one offered by ionic) or you can send them yourself from your backend.
I'm thinking to work on firebase notifications in the last few days but I want to some answers for this few questions:
Does Ionic2 support firebase notifications ?
Will notification show in the top of screen when my application closed or it should be work in the background ?
Is firebase notification sent on time or it may take long time ?
If I assumed Ionic 2 can send private notifications (to my device only), so can I send public notification for all application users ?
If the answer of all questions "yes", wish you give me any useful links that may help me (if you have a time)
In addition to Gabriel's answer:
The default behavior for notifications is for it to show on the top part of the screen. I haven't worked on Ionic before, but AFAIK, the behavior should compared to Android.
With that said, you should refer to the Handling Messages part of the FCM docs.
There are factors to consider that may affect the time it takes for the device to receive a message, but as FCM's behavior, it would try it's best to send the message, as soon as feasible (see my answer here).
Gonna itemize this further:
Specific device only - Yup. When sending the message, just specify the registration token(s) that should recieve that message.
All devices - Yup. You could use the Firebase Notifications Console. But if you intend to send the message by using the REST API, you have to make sure that the devices are subscribed accordingly to your custom global topic.
About the device-to-device Gabriel mentioned, I think it should be worded as server to specific device(s).
Yes it does, and it works fine with FCM (Firebase Cloud Messaging, aka GCM - Google Cloud Messaging). It supports subscribing to topics and device-to-device notification via HTTP client. The topics subscriptions and device-to-device both require FCM plugin.
Yes, they'll appear on top of your device screen as any push notification, you'll just need to code how it'll behave after receiving it, like execute something if the notification is tapped, or do something if it's received and the app is already open (foreground), it's all up to you.
It's sent on time, i've never had delay problems, the longer it took to send the notification and i receive in my device was 10 seconds. But as far as i know it "stores" your notification for 24 hours, so if the servers go down or something happen the notification has a life time of 24 hours to be sent.
You can, as said in first answer, subscribe your users to topics. Let's say you want a topic to sent message so all users can receive, you can have an all topic, or have one only for logged users, one only for users who bought products, you can even get all users tokens and send one by one, but it's much better having them subscribe to topics.
Topics notifications can be sent via the Firebase project console. Device-to-device is sent by your app code.
To send device-to-device you'll need a token, it's provided by the FCM plugin (link above) and you'll need to store this token somewhere, like in your user node on Firebase. I usualy use the user device ID provided by the Device plugin to have his token, since the user can have multiple devices and log in all then, this'll prevent token overriding.
I don't know good tutorials about configuring FCM with Firebase, if i find something i'll edit the question and add it for you, but stick to the ionic native link and the FCM plugin github page.
Hope this helps.
the thing is that we already have a backend that handles all the push notification process. From device registration on our DB and notification handling on the device and notification sending to Apple and Google servers...Looking into Parse I saw that it has a lot of things that will take us a lot of time to develop but mostly on the process that sends the notification to the devices.
So...I need to know if devices can register in our backend, then from our backend to Parse and then send push trough Parse. Is this possible? Image below.
Thanks!!
Yes this is possible. You'll need setup your push certificates with Parse and register each device's push token with a Parse Installation object's deviceToken field for it to work. All this is documented on their web site. You'll need to setup a Parse User object for each user as well as each Installation is associated with a single User.
I'm trying to understand what I will need to build on my server for Push notifications to work successfully.
My thoughts were:
The phone sends the notify URL to my server
The server stores the information in a Database
A separate process or PHP script will query the database and open continuous looping process for each device. (Each socket will be querying a 3rd party API)
When there is a change detected in the API for that device a push notification will be sent to the device's notify url.
Is this the right method on what needs to be done. Isn't this going to eat up server resources or is it the expected outcome of Push a push notifications server?
I've produced a simple diagram on all this below:
First of all, let's separate the process in the main stages needed for PUSH.
Device subscription.
Send the PUSH
Process the notification on device.
Subscription
For the subscription, your device (more specifically, your App) must call the PUSH api,for enabling PUSH notifications. This call to the push API will give you a URL that uniquely identify the device where your application is installed and running. You should store this URL on your database, the same way you store a user's email, or a user's phone number. No special black magic here. You only use it when you need to send a communication to a user.
Send the PUSH
For the push stuff, the same approach as for email, or SMS messaging here: "One does not simply make an infinite loop and send a message if any change is detected". What you have to do is, just send the PUSH message when your application needs to. So you have the user to which you want to send a message, instead of opening a SMTP connection to send ane mail, just build the PUSH XML Message and call the URL associated with that user. Some things to consider here are:
Network reliability (you need to retry if you can't connect to the server).
Response error code-handling (you don't need to retry if the server tells you that the phone has uninstalled your application, for example).
Scalability. You don't want to send a PUSH message from your PHP code, because you don't know how long it will take for the task to be completed. You have to make this thing asynchronously. So just queue up all the push messages, you can create a separate process (windows service, nodeJS service, cron job, daemon, etc.) to send the PUSH, handle retries and errors and clean the queue.
Process the notification on Device
So now that you are this far, you need to handle the notification on the phone. It depends on the type of PUSH notification that you are sending:
Tile. You will update the image, text and counter of the application tile, if the user has put your application to the start screen. On client side you need nothing to so, as all these parameters are part of your PUSH request.
Toast. This one requires a title, text (limited to some 35 characters more or less) and a relative URL inside of your APP. Your application will be launched (like when you click on a Toast notification from Twitter, for example) using the URI that you specify in the payload. So a bit of data can be already injected here. You may/or may not make a request to your server for new data. It is up to you.
Raw. This one is pretty much silent. Is not seen by the user if your APP is not running. As you might guess, this kind of PUSH is useful to live update your running APP, instead of continuously polling your server, wasting user battery and bandwidth and wasting your server resources. You can send anything (raw bytes or strings) up to the max size of the payload allowed my Microsoft.
If yo have any more questions, don't hesitate to ask.
Bottom line: separate the PUSH sending, make it async, don't you ever forget that...
Your PHP script that continually pings the database for changes...THAT is what will eat up your system resources. Push notifications go hand in hand with Event Driven Programming. This means that ideally, your code shouldn't continuously ping your DB. Rather, when something happens (ie, an "event"), THEN your code does something...like contact your phone via push notification.
Your steps for push notifications are more or less correct, but are incomplete. Step 4: the server contacts the client via the notify url (which you have). Step 5 is that the client then contacts the server to actually pull down the information it needs. That is: The new information is not provided to the client via the notify url. Once the client has its new information, then the program continues as normal (populates a list, downloads skynet, etc.)
Your third step is very wasteful and not practical if your app is installed on more than a few devices.
Instead, each device should be subscribed to types of server updates it cares about. Your server's DB will have a mapping from each type of update you support to the list of notification channel URLs of devices that care about this update type.
When your server detects an update of type X, it would send a notification to all devices subscribed to that type of update.