I have been setting up Apple Push Notifications for an iOS app, using JSON Web Tokens rather than certificates.
I can generate a JWT and make the required POST request from within the app (using the Swift-JWT package) and the notification is delivered.
I am using MongoDB Realm, which has serverless functions (in JavaScript with a Node environment) that are called from the iOS app. A scheduled trigger updates my JWT, as Apple advise it should be refreshed every hour.
However, despite trying several Node modules for making the POST request there were always errors (like “BadDeviceToken” or “InvalidProviderToken”).
I finally got it working using the node-apn package! However, I have two queries about using it in this serverless function context:
It tries to keep a connection open to the Apple server, which would be fine, except it might mean a new connection is opened every time the function is called. Calling Provider.shutdown() does not seem to stop the connection. I don’t think I can have a long-running process to receive future requests in a serverless context.
Apple advise not refreshing the JWT more often than every 20 minutes. node-apn manages the JWT for you, but in a serverless context, will it be generating a new token every time the function is called? Notifications do seem to get delivered every time I test it in development mode (to the Apple sandbox endpoint).
I’d be grateful for clarity on these points, and whether node-apn is appropriate to use in serverless functions.
Update
Provider.shutdown() not working seems to be a recognised issue.
I was able to shut down using this workaround:
Provider.client.endpointManager._endpoints.forEach(endpoint => endpoint.destroy());
I would still like to know about whether it is reasonable for this to be used in a serverless function. I am concerned about JWT being refreshed with every request, which Apple may not like!
I have scanned through Apple's documentation on this and given some thought to your question about refreshing tokens within a serverless context.
You could imagine the following approach for ensuring that you refresh the token no more than once every 20 minutes and at least once every hour, as per Apple's documentation:
Generate the token for sending a single notification request
Send the notification, and then after, in the background, save that token to some collection (e.g apn_tokens) inside of MongoDB (optionally alongside a createdAt timestamp field)
On the next request to send a push notifcation, fetch the stored JWT token from your server.
If the token's createdAt date (or iat field on the JWT itself) is less than an hour (or within some threshold less than the hour e.g 50 mins), then reuse the token in sending the push notification request
Otherwise, restart the process from step 1!
Note on this process: It would require that your database (or theapn_tokens collection) is only accessible from trusted sources (i.e your cloud application/functions alone), if they aren't already. Clients should not have access to this table in any way. You can imagine setting Collection-Level Access Control for your serverless environment. As an extra layer of security, you could imagine deleting "expired" tokens after re-generation in step 1, such that there is only one token present in the table at any time in order to prevent potentially active tokens from laying around in the database without use.
I hope this helps!
Related
Is there a way to atomically move a redis key from one place to another when it expires? There's ways of doing this in the client by being notified of redis expire notifications, but if no clients are running when the notification is triggered then the event is missed.
But if there's a way to do it on the server (through a LUA script maybe) then it can be atomic and the key exists in one place before the expiry and the other place after expiry.
Expiration keyspace notification isn't fired when the key expires. It's not guaranteed to happen as you might expect... (see Timing of expired events)
When the key is accessed by a command and is found to be expired.
Via a background system that looks for expired keys in background, incrementally, in order to be able to also collect keys that are never
accessed.
IMHO, I believe that you should go with another approach. Use some external task scheduler and automatically start a task to move expired keys some seconds or minutes before they're going to get expired. I understand that you'll check if target keys are still alive using ttl command.
For me, key expiration is a good approach to automatically free up memory but you shouldn't use it to produce actions based on expiration events since it's unreliable for such use cases.
Lua scripts cannot be triggered by a keyspace notification.
You must do this on client side.
I am working on an application which GET and POST information to a server. I am doing so using AFNetworking framework. My aim is to push a notification to a client whenever someone posts new info to the server. Eg: a new grade is published, the student who's grade was published must receive a notification on his iDevice.
Although I am not familiar with how Apple Push Notification works, from what I read I concluded that I need to add server side code in order to trigger a notification.
Note that I don't have access to the server. Service is provided by Fedena.
Any suggestions or hints from where to start?
APNS needs a server in order to work. The usual flow goes like this:
The iOS Application asks user to enable push notifications
Upon access granted, a device token is generated and then must be sent to the server.
Your server must be setup with the proper APNS certificates generated from the Apple Developer site
Then in your server's, when a new post is created, you need to add some logic where you load all the APNS token you've received already and then send the notification to the devices.
This is a very simple flow description but I guess you understood that you need to have access to the server to be able to do what you are trying to achieve.
Some third parties exists to handle push notifications (like Urban Airship), but those push notifications are usually pushed manually from a person, and not triggered from a server event
I recommend that you can use secondary server of your own as intermediate and use it as infrastructure back bone.You can use SignalR library. Use secondary server as to create connection between two devises. One client will push events and another client will listen to events.
Here is the link to the signalR library code written in IOS.
I am currently using these library. What you can do is start hub and connection using these library.
This library allows invoking method on server. Something like this.
[_hub invoke:#"MehtodName" withArgs:params];
What i would do is to create event registry on server. So one client can listen to event on server and other can push events or vice versa.
So your student device can invoke method "subscribe to events" and server will add it into the registry list. You can create secondary service "Publish Events". Grade publisher can publish via calling this method. Here publish events will look up registry and find interested clients and call desired method on client.
Read more about signalr through this site.
Benefit of using Signalr Over APNS.
Cost Effective. As this will save you money which you might have to pay to Apple for pushing notification.
Can Easily make it cross plateform in future. Just have to impletement similar library in Android/Windows.
Quicker as the data does not travel to apple server from your server.
Worst case you can fallback to apns any day, just put push notification code in any of your secondary server methods.
I have done battery and performance testing as well and works perfectly fine.
If you wanna know, here how it handles connection which is very reliable.
SRAutoTransport chooses the best supported transport for both client
and server. This achieved by falling back to less performant
transports. The default transport fallback is:
SRWebSocketTransport
SRServerSentEventsTransport
SRLongPollingTransport
Let me know if you have anyother question. i am currently doing similar work, might be able to help you with your issue.
I am currently in the process of writing an iOS app and it's now been decided that there will no longer be an in-built real time messaging service. This was the main reason around using Socket.io on the server. So basically when the app is loaded it logged in in the background by sending the login credentials with the connection request. Now that I don't need the messaging service, most of the app is just information requests and the server responds with the relevant information. I could still utilize the real time aspect by sending updated information to the device if it gets updated on the server and some in-app notifications could utilize this too. However I'm pretty sure it can be all done using http requests and I'm not sure how likely I would need real time functionality in a future update.
Ignoring time and money, should I fundamentally re-write the way the server and the app communicate or would it be okay to continue using Socket.io and websockets?
I am quite new into programming and I cant find efficient solution for my problem. Could someone point me in the right direction please?
I have an app which is heavily relying on server data. Data on server is unique for each user and may change every minute as well as only every few hours. Currently I am updating local data when app becomes active but I also need a way of notifying app to trigger updates when app stays in active state and data has changed on server. I thought about few solutions:
1) NSTimer set to one minute and triggering url request to check if there is new data on server. Server after comparing lastModified value would return new data if available.
I don't really like that solution as I don't want to overload my server with number of requests, especially that data in the database may change only every few hours or even longer.
2) APNS - sending notifications from server every time data will change and than update local data with server database when notification received.
It seems like a good solution but only if it would be possible to restrict remote notifications to be received when app is in active state. As far I know it is not possible and as I mentioned before data may change even every minute so I don't want to spam users with number of notifications when app is not running.
3) TCP Sockets using NSStream/CFStream?
This is something I never did before, so I am not even sure if I am going in the right direction researching about this one.
This is a hard topic in general, but more technologies are coming out to help with it. Couple thoughts on each of your solutions:
The NSTimer solution is effectively polling, which is the worst option I feel. You'd be hitting your server pretty hard for each user.
This would be a better solution. APNS now supports silent notifications, so you can send push notifications to a user without worrying about notifying them. You can send a silent notification by including the content-available key in the payload and not including the alert key. More info here: http://hayageek.com/ios-silent-push-notifications/. It is rate limited, though. You may go minutes to hours without getting a delivery, so if that's important you'd be best to go to option 3.
This is your best solution. It would require a persistent connection with your server. AFNetworking 2.0 supports this kind of connection based on Rocket. Here's Rocket's documentation: http://rocket.github.io. Take a look at server-sent events.
Hope that helps!
i'm writing an app that manage a sqlite database, and i have write a web server, i want the user register in my web server with username and password, i already know how make a request from ios app to server and receive the response, but i want enable also the synchronization of the sqlite database to other device, i now that with core data i can use iCloud synchronization, but for now i prefer use sqlite, and find a way to synchronize it, for example i want create this:
make a change in the sqlite in the iPhone app;
the app send this change to the server for that user;
then the server have to send this update to other device connected at that user;
and now i can't go over, how the server can send this change to the other device? the device has to be always listen to the server? or there is a way to send this update directly to some device and handle it? like an apple push notification?
EDIT: if it's possible use an apple push notification to do this, i doesn't want alert with text sound and badge the user, but send a "silent notification" it's possible?
As a high-level there are a few different ways to approach this, all of which have pros and cons. Two name two examples you can do a polling method, active push or a hybrid approach.
Polling: at some pre-determined interval the app tries to "phone home" and send the delta db changes up to the server. Here you know that your server will be expecting X number of responses in any given interval so you can appropriately gauge your load.
Active Push: The user decides when they want those changes to be transmitted to the server by hitting a "Sync" button. This allows the user to only push data back up to the server when they know there's a change but an over zealous user may make a change, upload, make a change, upload, etc instead of queueing up a bunch of changes and sending them all at once. This may create frequently unneeded server calls.
Hybrid: You setup a polling schedule within the app AND give the user the ability to Sync at-will in the event there is a critical change that needs to be made ASAP.
Regarding the listener side of the equation you face a similar challenge conceptually. If the original user makes 20 changes and presses Sync 20 times do you bombard the second user's device 20 times as well or do you queue those changes up and send them down every 5 minutes (as an example)? Unless you have both devices paired to each other or are connected to the same network AND visible to each other via your app you're going to need to leverage that back-end server. Push notifications can be very useful in this manner but there is extra development and setup overhead to take into account to properly implement them.
To boil this all down I would recommend laying out what YOU want your syncing model to look like before you start marching down a path.