I've set up an app to send motion data from one device to another using websockets (Starscream library). Now I need to send push notifications when a critical event happens (when app is minimized), does it have anything to do with websockets or I just need to use something like Pusher?
As you said, I think you should use Pusher or any other external service (Pushwoosh, Onesignal, among others) to send push notifications to the users. You can't do this with websockets.
I recommend you to use OneSignal (it is free and some big companies like Uber or Zillow are using it)
EDIT:
I think you can't send a push notification from one device to the other one. One device (let's say Kid.app) should notify the server of an event, and then the server will send the push notification to the other (Parent.app).
Check this link, it will be useful for you.
Related
I work perfectly with Push Notifications for iOS using APNS. So for some customers, I need an on-premise or local solution, where I could send notifications to the device without APNS and without dependence on the internet. Somebody knows? can you help me?
Not possible. You cannot get notification from APNS without internet.
What you can do to accomplish this is you send message from your server to the app while it is in background mode and generate local notification accordingly.
Let me clarify your question.
"Locally" means: you got either no internet connection, a local network without connection to APNS OR the users simply did not register for push notifications.
1. iBeacon with Local Push Notification
So, here is an alternative, and that's kind of NOT what it is basically used for, but as you may know. iBeacons can be used to transport small data chunks, very very small ones. If your users did enable location services, you could include these for your application to trigger certain events (in this case, a very small notification that users came into range of a point of interest).
Downside: The application bundle requires either a static "notification text" to beacon mapping or you have to dynamically download the mapping from a web source, so you could update the notification's text.
2. Bluetooth with Local Push Notification
Another alternative would be to use bluetooth instead.
Devices could auto connect to your Bluetooth Station "Peripheral" - These devices now (with the help of your app) would register to a broadcasting characteristic of your Peripheral.
The peripheral could send messages to the registered devices.
If now the device does receive such a broadcasted message, you could perform a local push. - Without any network connection, just with the help of bluetooth, which itself also requires user permissions, of course.
3. Internet Connection / Silent Push with Local Push Notification
If your application of course had a working internet connection, you could avoid the APNS from Apple and send your own notifications to the device as silent push notifications.
As of iOS 14 this is available through Local Push Connectivity, but you will require the App Push Provider entitlement that you must apply for specifying why you are unable to use APNS.
Apple sample code is available here.
APNS works only with internet. If you need to push a message to the user without internet one solution (probably only solution currently) is using SMS api. But that requires user mobile number. Using URL Schema the user can open your app from the SMS message.
The application where only four users can share the videos other three users can see the videos and vice versa. I am using cloudkit as a central server.
I would like to send a Push notification without using any Backend server setup to user if one user shared the video.
is there any third party library to obtain this?
Sorry no this is not possible. With Push notifications the Provider needs to send the notification to the APNS (Apple Push Notification Service) which will send it to the correct device.
This works like:
You are also not able to send files just notifications in the for of Text, sound etc. So no XML file via Push notifications sorry.
You could however do it were you notify the user through Push Notification that there is a file available and then download it when the app opens.
Apple provides CloudKit to handle the backend server for you. You can use push notifications though CloudKit by subscribing to record changes. You can pair devices with GameKit for peer to peer connection. Without more information on what you are trying to accomplish this is all the information I can provide.
We have iOS push notifications configured and running. However, we would like the user to select which categories are interesting to receive and which are not important and would like to omit receiving those notifications.
Is there any way to do this through Apple push notification itself rather than through the server sending the notifications? (We can change the sent JSON). Can the iPhone send which categories it would like to receive and which are not needed by registering them to Apple? Other choice, can we interrupt the push notification before being shown and decide whether it should be shown or not through a delegate? So far, I can't find an available method to do either.
Any help is appreciated
The short answer is not from the client side. If you want a solution that works 100% of the time you will need to do something on a server which only sends the types of push notifications the user subscribes to.
If your App is in background there is no concept of "categories" of PUSH notifications and you have no control over if they show up in the notification center.
You can examine inbound push when the App is in the foreground and decide on the basis of some meta data to display or not, but that is not a 100% solution.
I am considering using EventSource (server-sent events) to send notifications to my iOS App users, instead of APNS. This is great when app is active, but is it possible to ensure these users receive my messages when my app is not currently running on their device? Or is the only way to do this APNS?
If you need your events to arrive in real-time (like a messaging system), then APNS is probably your best bet. APNS is the only way to send realtime messages from a server to your app. However, it is wise to know that there are downsides to push notifications.
If you don't care about real-time events (not a messaging system), or if it's okay if you get the events a bit delayed, you can use background fetching to periodically poll your server for new events.
Objc.io has a great article discussing some of these: http://www.objc.io/issue-5/multitasking.html
I want to create an iOS chatting app using APNS. If I have 10,000 active and they are continuing chatting, will apple block my developer account ? Is there any limitation regarding this?
I would discourage you from using APNS as a backbone of an "chatting app".
If you need fast chatting functionality you should write your own TCP-socket based server.
If every-few-second syncing is o.k. you can get away with a HTTP-based server backend (but all the pull-syncing can be hard on network traffic - so TCP-socket is still better choice).
You could however use APNS for fallback - when your app on certain device is not responding (i.e. is not connected to server) you can send an initial message trough APNS (to wake up your app & to notify the user there is a message waiting for him).
As soon as the user opens your app you should switch back to your TCP-socket or HTTP request based server communication.
As for your question: no, Apple would most probably (one can never know for sure) not reject your app just because of using APNS for chatting. But note (as the others said allready): messages between two users will get "lost" if they would interact too frequently - see the link Roman Barzyczak gave you.
"If you are sending multiple notifications to the same device or computer within a short period of time, the push service will send only the last one."
more information: http://developer.apple.com/library/ios/#technotes/tn2265/_index.html
but Apple wont block your developer account :)
You can use them for messaging but you are going to quickly find out that there is no guarantee they will arrive. This is known as the black hole of push notifications. ;-)
I like this answer here.
First try to use an APNS only solution.
Make your push notifications stateless (they only serve as "Hey you have some new stuff in the server").
So when the client gets a push notification it asks the server for new data (messages or other stuff).
Use OneSignal to simplify the code that sends push notifications (from the back-end). If a user in your app gets a message after 10 seconds he dose not care if you used TCP,socket.io or xmpp...
Even Whatsapp's messages can take couple of seconds to arrive.
A chat app is not a realtime game. A delay of couple of seconds will be acceptable by end users.