In a few weeks, I'd like to track subscription status etc. for my app.
I know about the server notifications that you can set up on App Store Connect - however, I haven't found a way to request a data set for all transactions that would have fired server notifications if they were already set up at a time.
Does Apple expect you to set up the receiving end for these notifications in advance, even if you don't need the data right now, or is there a way to request the past few years worth of notifications (or transaction information or whatever you want to call it) that you have "missed"?
Related
I am about ready to update my app with CloudKit new record notifications. before I publish it should I delete the subscription I used to test it?
You can delete it, yes. But if you are asking this question, you might be overlooking something with subscriptions.
I always create CloudKit subscriptions programmatically in my app when it starts up (through a method called from didFinishLaunchingWithOptions). I set a static name for the notification like taskNotification for each recordType so that the same subscription gets overwritten with each app launch.
This is useful because this code will run for every user on every device so that their devices gets registered to receive the notifications.
It also ensures the subscriptions get created in the Production environment on CloudKit after you migrate to it.
If you are manually creating and deleting CloudKit subscriptions, you may not be allowing your users to subscribe their devices properly. Just thought I'd point that out.
Good luck!
Is there a recommended strategy for checking of notifications within my AngularJS app?
By 'notification' I'm talking about message alerts that are to be displayed to a user when they're logged into the application.
My plan is to notify the user of unread notifications in the app's NavBar as shown below:
My app communicates with my restFul API (written using Node.js, express, MongoDB), so I anticipate that new notification will be written to a MongoDB collection with details the user the notification is intended for.
What I'm unsure about is how the AngularJS application will check for notifications once a user is logged on. I could call my API for unread notifications every time the user navigates from one path to another but that seems simplistic and it wouldn't work if a new notification occurs whilst a user is viewing a page.
Another way would be some sort of timer system that checked, say, every 30 seconds. But this would results in unnecessary polling of my API when there aren't any new notification for a user.
So, wondering if there is a recommended strategy. Thanks for your help.
Polling is a solution but it is very inefficient. The solution to your problem are websockets. Websockets is a technology that provides a full-duplex bidirectional communication between your clients and your server. So you can send messages from your server to your connected clients. Your server maintains an array of connected clients and you just have to know which ID you need to send a message to it.
For your stack, the best solution I have came to is Socket.io http://socket.io
It also have cool features. For example, you can "observe" models, so if a model change in your database, for example an update to a user profile is made, you can trigger an event and automagically send a message to your client. This client get and handles the notification and do something, like put a badge on your alerts icon.
Hope this is useful for you.
My company do integration of our product with Jawbone API.
I'm looking for the way to get date&time when user uploaded data to Jawbone UP server last time. I mean time when users sync it's data from wearable device&smartphone to Jawbone Server.
Can't find something like that in API Spec. The only Idea I have is to use Pub Sub notification date & time as indicator that user recently uploaded data to server. However I'm not sure that Pub Sub notifications being sent only in case of data upload. Please let me know if you have an ideas.
PubSub is the best way. You can use the type field in the notification to determine what kind of data was just synced.
There is a list of all the possible Notification Types under All notification events on the Pub Sub documentation.
My app should get push notification on user defined time duration (like on each Monday 11 AM).
So for that App have to check for new updates on server (on background) on user defined date and time, App might not be running at this time, but it still has to check for new updates on server. If any update found, server will send push notification for the same.
How can I implement time based background process?
Thanks!
Why don't let the server do all that? I mean, you will have to do a post with the selected date by the user from the app, and the server at the selected time will send a push notification to that particular user (you know what user it is by his token id). Amazon Web Services works like that for example.
I want to notify a user if any other user wants to be friend with him. The only ways I can currently think of is notify through push notifications or recipients device will keep polling server for new information at certain frequency or device will check for new information only when it launches.
I have some problems with Push Notifications method to send requests
If device is offline only last notification will get processed
If app is not running, push notification will get delivered in Notifications and I don't know how can I extract information from there to my app.
Also, if device keeps polling for new information number of API calls will be very high which is not cost effective and alternately if device asks for new information only at start up launch it will not get real time updates.
Is there any way I can send information to device as soon as information is available?.
Any suggestions will be appreciated
Have you taken a look at Urban Airship?
They have a great framework set up for queueing and receiving push notifications, even when your app is offline. You can either queue the notification from the app itself or from your server hosting your account data. They also have the ability to compose and push rich content notifications.
The basic account for small apps gets 1 million free push notifications per month. Everything beyond that is fractions of a penny.
Hope this helps, Cheers!
Notifications is one such thing which can drain down battery if one takes polling route, thats one of the reasons Apple developed Push Notifications. I would recommend try to use Apple Push notification as much as possible as it would have been optimized to hell. If you have different flows for when the app is active & for when the app is not active (reg. notifications) you can do it like so -
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
{
if(application.applicationState == UIApplicationStateActive) {
// app active.
}
else {
// app not active
}
}
But if in any case Apples Technology does not suite ones needs one could always use third party services. In this case there are a few that can really help you.
Pusher has an Objective-C library and a REST API (along with a number of libraries) that would let you push realtime updates from your server into an iOS application.
OpenPush is another such service. Also check this link, here's a compiled list of realtime technologies in which I'm sure you'll also find technologies that meet your requirements.
All of these are better than polling.
Is there any way I can send information to device as soon as information is available?. Any suggestions will be appreciated
user1 wants to add user2 as friend.
from device, post information to server, in your webscript, process the friend request of user1 to user2 (insert/update information to database etc), when done. send the notification to user2. this will work if the device is offline, user2 will have real time update, if the app is running. you can run scheduled request that will check new notifications. say every 2 minutes, a method in your app runs. but thats not a very good idea. A reload button inside the app to check notification is better.
What you would normally do is to use the push request as a means of informing your app that new data is available. The user clicks on the push notification - the app is opened with the
-(void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
you register that there was push, query your server and the server let's your app know that this list of new friend requests are there.
You can't really do the queuing of messages on the device - and you don't need to. It's much easier to just store the info on your server until the app queries it.