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
}
Related
The Background Information:
I am writing an application that uses the PubNub framework to directly couple one Raspberry Pi with one iPhone, for each individual user. The Raspberry Pi uses an Arduino as a slave to gather analog data, then uses the PubNub network to publish that data to the one and only iPhone that is on the same channel. With the data that the iPhone receives, it determines (locally) if the user needs to be alerted. Then, when the user is alerted, they have the ability to adjust the current state of the Raspberry Pi by sending data (settings) back to the Pi, which will then resolve the problem that warranted a user alert.
The Problem:
When the iPhone app goes into the background, the messages sent by the Raspberry Pi that the iPhone should be receiving will no longer be caught by the application, and therefor the user is no longer notified when they need to be. The first obvious solution would be to move the logic of what warrants an alert to the Raspberry Pi itself, so that it can use Apple Push Notifications to send those alerts to the user. However, the problem with this is that I am also trying to track whether or not the Raspberry Pi connection has timed out, so that if some unexpected disconnect occurs, the user is notified of that problem as well. This logic obviously can not be on the Raspberry Pi itself, because if a disconnect occurs, then it will not be able to push the notification to the iPhone itself. Having a middle man server of sorts to monitor the state of the device would seem like a logical solution... however I do not want anything other than the iPhone and Raspberry Pi involved in the data transmission and handling, which is clearly the entire motivation behind using PubNub in the first place (within the scope of my application).
This is not a PubNub specific problem. I only cite them to paint a clearer picture. Also worth noting is that I do not want to fake a location service in order to get iOS to grant continuous background permissions. This is a lazy and sloppy solution with undesired overhead.
The Question:
How do I receive (or request) a short string every 15 to 30 seconds in the background to determine if I should throw an alert. This has to be achievable. Based on my research and reading of apple documentation, it is clear to me that many people will try to respond with "it isn't possible." I do not welcome this answer. I am here to find a solution that I could not previously find, or that has not previously been proposed. I need an intelligent engineer to propose a genuine solution or workaround to my problem.
I sincerely thank the champion engineer in advance.
#JonW I read your question, and some of the comment until I got to the TL;DR point :) The short answer is that silent push notifications might be the answer to one of your problems.The other might be PubNub Presence Webhooks. But I would agree with #Paulw11 that a server is the best practice and ultimately, PubNub BLOCKS will be your solution.
Background Processing with Apple Silent Push Notifications
To do some short background processing, you can have your RPi publish a message that includes a push notification (as I believe you are already doing). But this push msg should be a silent push notification. The docs say this:
When a silent notification arrives, iOS wakes up your app in the
background so that you can get new data from your server or do
background information processing.
... ensure there is no alert, sound, or badge payload in the aps dictionary
The full details are at the link I just provided but here is a sample message payload that you would publish on PubNub with the proper aps format.
{
"pn_apns": {
"aps": {
"content-available": 1,
"data": {
"temperature": "55",
"humidity": "42%"
}
}
},
"data": {
"info": "This is the full realtime message.",
"temperature": "55",
"humidity": "42%"
}
}
WARNING: The silent push notifications are only effective if the app is not in a kill state. In other words, it must be idle in background - not running, but idle. If you force kill the app (swipe up from recent apps list by double tap Home button) or do not start the app after device has been powered off then on again, then silent pushes will be ignored.
See this Badge Count Demo as a template for getting started. But as #Paulw11 said, regular push notifications every 30 seconds is not a good idea. You should be sending your updates to a server that can send a push notification to the iPhone app when it is necessary to take action.
Offline Notification with PubNub Presence Webhooks
Going further down the server process best practice, you can have your server monitor the presence of the RPi on the channel. If the RPi ever leaves the channel by explicit unsubscribe from channel (leave event) or by network disconnect (timeout event), then a message can be POSTed to your server REST endpoint (that you provide us to configure on your PubNub keys). If either of these events happens, then you can publish a message (silent push payload included) to your iPhone app to take appropriate action.
PubNub BLOCKS - No Server Required (Look mom, no server!)
So you say you want to avoid using a server. With PubNub BLOCKS, you will be able to avoid using your own server - instead, you will use PubNub servers.
I won't into too much details here, but you will be able to write a small bit of JavaScript in a BLOCK that can determine if a push notification needs to be sent or not and much much more.
Summary
For now, I think your prototype with silent push is good to flesh out your use case. But ultimately, you need to have an always on process that can determine when it is necessary to send a push notification. While your iPhone app is active, it can receive the realtime messages from RPi, but when in background, getting a silent push every 30 seconds is not ideal and possibly not allowed by Apple.
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 am new to IOS and wants to used Local Notification feature of iOS.
my problem is i do not know if i can go with local notification. in my case data will come from web service... it is like..no specific date. default time interval is 60 Sec. after 60 sec app has to call webservice which will return notification data..and after some validation i need to push to user.
and if user click on view details it will launch appand get data via webservice.
Is using localnotification will serve my purpose? or i have to go with other approach?
Please help.
Thanks in advanced.
I think this 60 second thing is you polling the server every 60 seconds to fetch new data, then if there is new data post a local notification?
This is kinda possible with iOS7 but not exactly every 60 seconds, sometimes not at all, But in general it is strongly frowned upon. Instead the webserver should send push notifications when new data is available, It saves the user battery life.
On iOS7 there are silent push notifications (just don't include the alert) that can ask the client to do the validation you mentioned, and If the user needs a notification you can create a Local Notification to alert the user in a change
You should give this documentation a long look, it isn't trivial work for a new iOS programmer:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Introduction.html
And here is a relevant Apple documentation quote "Local and push notifications serve different design needs. A local notification is local to an application on an iPhone, iPad, or iPod touch. Push notifications—also known as remote notifications—arrive from outside a device. They originate on a remote server—the application’s provider—and are pushed to applications on devices (via the Apple Push Notification service) when there are messages to see or data to download."
If you are trying to achieve this functionality to happen automatically/polling (i.e without user interaction like, clicking on the view details button)- the answer is a big NO at least not till iOS6.x
Your application cannot run for infinite length in background at-not till ios6.x. You may have to consider using APNS service to achieve this.
Otherwise, your approach on scheduling a local notification for ever 60 sec - The user clicks in the view option - the application comes up - You make a web-service call - Get the data - Validate the received data - Uploading to the server, looks fine to happen.
Will it not be annoying to the user getting notification for ever 60 sec & operating on the app to do whatever you intended to do? - Just curious.
It's generally a common question.
I wonder how do mail apps implement functionality of email-receiving?
I need to implement a simple sync between two devices(for example) using my web service.
Imagine a to do list app.
Is it possible to implement such a functionality: device1 makes an entry,then sends a message to webservice, webservice informs device2 that changes took place and device2 adjusts its data and displays that entry?
On iOS what you want could easily be implement with push notifications.
As soon as the server detects changes that device2 needs to be aware of the server will send a push notification to that device.
After the user views the notification the app should update it self, it would also be a good idea to let the app update it self when coming to the foreground.
The reason for doing it with Push Notification and not polling is that if your app is in the background you can only continue to run a process for 10 min max. You might get around this by adding the background mode to your app, like VOIP, Audio or location. But if you app does not fall in those categories apple might reject your app.
With Push notification the device will receive the notification even if your app isn't running or in background.
Basically there are 2 ways:
polling, each device asks the webserver for changes every N minutes: new todo, delete a todo, change a todo, ... and then each device will adjust. The frequency of the poll depends of the level of real time you are looking for. It can be 1 call every second or every 12 hours or much more.
implement a kind of BOSH protocol: the device opens a connection to the server. The server keeps it open until there something new to send to the device or the connection times out. In that case, the device reopens it.
Option 1 is better for your todo app because you don't need real-time accuracy. The option 2 is better for a chat application where you don't want to wait for the message.
Within my iPhone application I periodically make calls to a webservice, providing the endpoint with a list of numeric IDs. The webservice then returns information relating to the IDs it receives.
This is all well and good. However, I would like to be able to provide functionality whereby the user will receive a local/push notification when these changes occur, regardless of whether the application is open or not.
I'm just looking for guidance on my options in this scenario. As I see it, there are two main approaches: calculate any data changes on my webserver and send a push notification to all devices, or query the webservice from the device itself.
The second option seems ideal, as not all devices will need each push notification, but I'm unsure as to whether this is possible with the current state of iOS' multitasking APIs. Any advice would be appreciated.
Bad news: it's not possible. Apps can only run in the background for a short period of time after the user has exited unless it fits into a small number of categories (GPS, VoIP, etc).
Web services, unfortunately, do not count. So this would have to be performed on the server side and with push notifications.