I have few things to be clarified in BlackBerry push client applications. I have developed an push-enabled application which can receive push messages from the sample push initiator application installed on a publicly accessible location (through BIS). I have now run into a question about sending personalized messages to each device. For that matter I need to use subscription API that comes with BlackBerry push SDK. This question is similar to what has been posted here, but it contains no information for me. My questions are,
I used the registration API for BlackBerry client app registration to receive push messages from PPG. It requires only app-ID, device-port and push URL(not push initiator URL). Client app registers itself when the application UI starts up(this is how I register with push API). Is this all I need to do to get a subscription for that client with push initiator or does client need to contact push initiator directly for a subscription?
Why do I need to provide subscribe/unsubscribe URLs in the push initiator application (I don't provide any unsubscribe/subscribe facility in the client push application ) or is there a way to achieve this through application manager/operating system? or do I need to get unsubscribed users from the PushResult object and process them?
How does push initiator come to know about clients initially when there is no mechanism for the push client to subscribe with push initiator?
Is there a blog post or tutorial describing each and every step involved in the entire communication process apart from the documentation materials provided by RIM?
Currently I am using Push Essentials but might migrate to Push Plus service later(in the distance future).
Kindly appreciate your quick response.
Ok, so there are 2 things to keep in mind:
1) The BlackBerry Infrastructure (Push Proxy Gateway or PPG) needs to have your device listed as subscribed for your specific application ID in order for pushes to be delivered to your device. Subscribing from the device registers it with the PPG and tells the PPG "I would like to allow pushes from this App ID to be delivered to me". If your device is not subscribed to the PPG then your pushes from the initiator will be sent, accepted by the PPG but never allowed to be delivered to the target device.
2) Even if the device is registered with the PPG, how does your server sending the pushes keep track of what devices are registered? This is done by registering with the Push Initiator. The client sample application included with the Push SDK has a mechanism to show how this can be done. As well the server sample is set to receive these requests and add the client to the database so that it can be included for future pushes.
With all that in mind what happens if:
1) The user un-installs the application
2) The user switches devices
In the above cases there needs to be a mechanism to de-register the device from receiving pushes both from the PPG and from your server Push Initiator. Again the client sample application shows how this can be done.
Related
I'm working on react native push notifications. i'm looking for some answers before i make a purchase to any third party notification provider
Why do third party notifications providers such as OneSignal, Pusher & PubNub are based on Firebase Cloud Messaging?
Can't they send notifications independently without relying on Firebase. why pay more to third party providers when FCM does the work for free?
Firebase is a Brand of Services
First, Firebase is a brand that encompasses more than just 1 thing. For example, there is Firebase the realtime database, and there is FCM (Firebase Cloud Messaging) which is the current incarnation of GCM (Google Cloud Messaging) which came from the original product, C2DM (Cloud to Device Messaging).
PubNub and others are push gateway providers
Second, third party realtime messaging services are not push notification services, rather they offer push notification gateways to the push services: APNS for iOS and FCM for Android.
PubNub Realtime Messaging & Mobile Push Notifications
In PubNub's case (my employer), we provide a realtime messaging service (publish, subscribe and much more) and if you provide a valid APNS and/or FCM payload, we will not only deliver that realtime message to active subscribers, we will also send a mobile push notification to the devices that are properly registered for them on that channel you published the message to. This allows the message to be delivered when the app on the device is either not active (background) or not running and therefore, no active connection to PubNub unless it is running in a background service). Now you can have an active connection to PubNub in the background with proper implementation and permissions from the owner of the device (easier on Android than on iOS which also has a review process that rejects apps that don't qualify as valid background service apps).
For Your Consideration
If you did not use a service such as PubNub or one of the other realtime messaging vendors or a push notification specific service like Urban Airship, you would have to implement your own server-based push notification service which is possible but might be more work than you would expect especially if it needs to scale, be secure, robust, etc.
The real question you should ask is do you need realtime messaging in your app or just push notifications and to what level of scalability where it is worth paying a third party for all that goodness.
I'm integrating Roku into our multi platform app with paid subscriptions model so webhooks/push notifications are crucial for business to know when subscription being renewed, cancelled etc. I came across Roku Push Notifications documentation which seems to have big security concerns or I'm missing the point:
Roku sends data down to our push notification url without any validation (e.g. like Stripe signature check does). So how do I know the data came from Roku and I can trust it?
They require to respond with our private API KEY(!) in the header... Does it mean that we can potentially expose it to anyone who found what the url is?
Not really a security concern but more of a business safety issue that they can stop sending push notifications without any notice if the endpoint fails consecutively which could lead to big problems again.
I would appreciate any advice on how to use Roku push notifications securely and if my concerns are valid at all.
I wrote application which uses GCM topic massaging to receive push notifications from server. Applications works fine on iOS 8.1 but on 9.1 it registers for registerUserNotificationSettings and registerForRemoteNotifications successfully, gets APNs token and GGLInstanceID token successfully, Subscribes to topic successfully. But it doesnt receives messages sent on topics but it does receives messages sent directly to its registration token. I have spent a whole day debugging this but i am unable to reach any conclusion because some times it receives messages when app is running in debug mode but when i make package and transfer ipa file to device it never receives topic messages.
I am developing a BlackBerry application in which I need to use PUSH API. I already have registered with RIM and they have sent me the credentials for evaluation service. In my BlackBerry device, I installed sample push API application just to test that the push messaging works. After setting the content provider URL which is publicly accessible, I entered all the details for the sample application to register the it for receiving notification messages. When trying to register it asks for username and password but I don't know what they are for. In the email received from RIM, there are passwords for server application and content provider admin portal applications but not for the push client.
When I added an arbitrary username and password it fails with the message that java.lang.Exception Registration with Push API failed, caused by port is unavailable. But when I unregister it successfully unregisters the user with the given arbitrary username and password. By the I use the port given in the RIM's email.
I have no idea why this happens and I appreciate immediate response from you. Thank you.
The first thing to point out is that the RIM sample push application is ridiculously overcomplicated. The username and password you are referring to are used to authenticate against the sample push initiator web application which runs on your tomcat server. It doesn't matter what you put in there, they are not used for authentication. I can only assume they were added to show you that you can send a username and password to a web based service.
The only things you need in your BlackBerry app to register for the push service are:
Push Application ID (e.g. 2672-c870l6c924r1i298O4o33cc5391y0e75134)
Push Port (e.g. 31940)
BlackBerry Push Server URL (e.g. http://pushapi.eval.blackberry.com)
The port is unavailable message you're receiving is probably because the device you're using has not been provisioned for BlackBerry Internet Services (BIS). Make sure it has a SIM with an active BlackBerry data plan.
i want to know that when we want to use push notification service.From where we send json payload, from our app or it may be generated on server? if it has to be sent from our app then how do we send json payload+device token to our own web server?
It can't be sent from your app. First off that would make no sense, if your app is running why would you have it send a push notification to itself.
Second, in order to communicate with the APNS servers you need a per app cert file to sign requests. You cannot distribute it without compromising the security of your applications push service.
Louis is absolutely right that you can't send messages from your phone, and his reasons are spot on. You'll definitely need to communicate to your own server, which will then send things on to Apple.
To send messages to your own server, look at ASIHTTPRequest - it's a fantastic package that makes it really easy to send HTTP requests.
On your server, you'll need to keep open a persistent connection to Apple's push service from your own servers and translate the JSON from the phone into a message to deliver to Apple.
There are at least two services out there that take care of the heavy lifting for you:
Urban Airship (full disclaimer, I work at Urban Airship)
iLime
You might want to look at one of these services to help you implement this. Again, I work at one, so take this with a huge grain of salt.
If you want to see some examples of how to use ASIHTTPRequest to send a device token to a server, you can look at our push sample application on bitbucket.