I am trying to understand the best practice for remote notifications on iOS when the user has a particularly poor network connection or no network connection.
The scenario is such:
The user gets some remote notifications and at some point in the future opens the app. At this point I wan't to let the server know ASAP that the badge count is now zero. I am using server side badge count management as the only way you can update the icon badge reliably is in the APNS payload. However the call to the server fails as there is no network connectivity. Then the user puts the app into the background so I can't make any further calls to the server if network came back. Subsequently a new remote notification comes in but the badge number is wrong because the server doesn't know it needed to be zeroed.
Am I missing something here? Any advice gratefully received as I haven't found any articles online dealing with this scenario.
Yes, you have implemented in right way. We can't do anything if there is problem in internet connection. Badge count is managed by server only. So, whenever you open application, application will update Zero to server. Now, if it is not properly updated to server then it is not possible to manage it from Mobile side.
Related
I have an iOS app which displays some information fetched from the server.
The app communicates with the server using REST API, and makes GET requests periodically (or when user pulls-to-refresh). However, we need better synchronization. As soon as data changed on server, we want to reflect it in the mobile app.
How can I get notifications from the server when data changed and update needed? I thought about silent push notifications, but they do not look a right choice here.
Are there alternatives? May socket programming help? I have no an experience in it, but I it is relevant, I will start digging.
So my app extracts JSON from a server that i don't control, and parses that JSON to populate a UITableView.
I want to update my UITableView to reflect the latest information available on the server in real time. So Whenever something changes on the server my UITableView also gets updated.
Now one solution that comes to mind is to Continuously send GET Requests lets say after one minute, parse the JSON and reload data on the table.
However there must be some other solution for this problem. I have tried searching but thus far no success.
Now i understand this questions is somewhat subjective by stackoverflow's standards but really i need help regarding this matter and i haven't got the slightest clue on where to start. So any help would be greatly appreciated.
Repeated GETs are generally frowned upon, because it demands client and server resources when nothing is happening, which can be most of the time.
Since you don't control the server, I'd recommend building a server that you do control that can perform the polling, and then send the push upon detecting a change. This has a couple advantages over polling from the client: It scales better since only one source of polling will exist in the world, and it conserves client energy as well as the pure push approach does.
Apple provides a push system (APNS) wherein your server sends a message to your iOS device (via Apple). The device will launch your app in the background and invoke:
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo;
on your app delegate.
As the above answer states, its better to use APNS.
if however, you truly do not control the server, then as you describe theres nothing you can do except poll. Since you're writing for iOS, you're well advised to consider a few things:
Wifi constraints: Are you fetching a tiny payload such that it doesn't matter whether you are on wifi? otherwise you ought to configure reachability to not be a drag on the users cellular service.
Backgrounding Sessions & background Execution: Consider using an NSBackgroundUrlSession to request this data. Backgrounding sessions are a bit more efficient to the OS in that they allow the OS to perform the request opportunistically. Consider The Background Execution entitlement if You need to customize the NSURLSessionTasks for the background session.
Scalability: can your backend handle continuous requests from your volume of users?
better solutions might utilize APNS, or Socket / WebSockets / Socket.io / firebase / etc.
Normal Silent Notification is best solution for this
When you adding any new item on server that time you can send push notification (Silent push notification) to devices to notify status that you added something on server side.
When device receives such push notifications then you have to call API and reload your table view. So you don't have to reload tableview every 10 sec.
It "will not show notification alert in notification bar, but it will only notify your app that there is some new data available, when you want to push new content.
Displayed in Notification center : No
Awake app to perform background task : Yes
just add below paylod from server side in push notification
{
"content-available" : 1
}
{
"content-available" : 1
}
I have a service that allows user to enter the type of events they like, and whenever a new event that fits those criteria is available in my database, I want them to get a notification.
I have been looking around at the best way to handle it and I have found two possible solutions, but I'm not very clear with which one I should use and how.
First, a solution that looked great was the didReceiveRemoteNotification method and the usage of remote silent notifications to tell the app that new content was available. But my questions remains: how can I send this remote notification to the user if I don't know which criteria he has. I mean, how can I send this notification using PHP? I'm a bit lost here.
So I found another possible solution that does look a lot like a hack (iPhone - Backgrounding to poll for events), to be able to make your app execute a method every XX minutes while it is in background. This would be way more battery consuming and I'm not even sure it would be accepted by Apple, but at least it is clear as to how it works: the app downloads data from a link with the parameters that fit the special criteria, and if there is new data, it sends a notification.
How could I combine both these methods?
EDIT
I think the main issue on my side is that I don't understand how I could check a certain PHP file whenever new data is added into mysql and make sure that it fits the criteria of the user and then send the notification. That is the part that I don't understand in the backend PHP usage.
Your flow should be like this -
Mobile -> BackendServer(PHP) -> APNS server -> Notifications->Back on device.
User will submit her/his criteria to server then server will process on that and send request to APNS server.
The APNS server will send remote notification on her/his device based on criteria requested.
I understand the basic concept of having a provider talk to Apple's Push Notification Server which then pushes the notification to the phone. Usually, the provider is an app server running on some machine somewhere completely separate from the app.
However, we don't currently have a separate server, and don't yet need one as everything is currently handled in-app. So, is there any way we can use the app itself as the provider to send a notification to Apple's server and thus to another phone?
Basic concept: we have a game and when a user completes 70% of the level, we'd like to notify his competitors that he's close to finishing the game (or that he has finished at 100%).
If it's possible, are there any security concerns with this approach?
P.S. The app already knows who the competitors are because it displays them in a UITableView.
Technically it's possible. If you include the push certificate with your app, and you have a way to send the device token of each device to all other devices that may need to push to that device, you can push a notification directly from one device to another.
However, in practice, that would require opening and closing many connections to the APNS servers frequently (you'll need a connection for each device, and every time a device loses network connection - which may happen often - you'll have to re-open that connection), which will probably cause Apple to block your app from connecting to their APNS server (since they would interpret it a DDoS attack).
Therefore you should use a server.
For future visitors to this question: we wound up ditching Amazon SNS since we spent nearly 8 hours and couldn't get it working the way we wanted. Instead, we setup Parse Push in rough 15 minutes with exactly what we wanted to do, so I would definitely recommend giving it a look.
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!