I have a native ios app that is essentially a REST client. The backend is a java REST API.
There is a delegate service that the backend is subscribed to. The delegate service sends events to the backend service.
What is the best way to communicate these events back to the IOS app?
Is polling the only option or is there a cleaner and more efficient way to PUSH data back to the devices.
I have done a little reading about push notifications but I am not sure it fits my use case. I don't want to notify the user about the change, I want the data to be passed to the application and to be used to perform business logic (change the u.i)
Related
Can we integrate VoIP services through the new framework CallKit without using any server services or push notification?
I am really new to this concept, also checked the speaker box app as a sample app but didn't get much idea how it would be working.
Please, share your feedback if anyone has integrated CallKit.
Thanks
The CallKit framework provides programmatic access to VoIP functionality, as well as call blocking and identification. Apps can use CallKit to receive incoming calls and make outgoing calls using the native phone UI.
Reference for call kit.
Can we integrate VoIP services through new framework call kit without using any server services or push notification?
No we can't use it. You will need third parties like Twilio, Plivo, or ICELink and create your own server. Then provide CallKit the data required, it will handle the call and UI stuff. You can read the apple docs for more ideas.
If a CallKit app only intends to make outgoing calls, then it may be possible to not have a server component. But if the app intends to receive incoming calls while the app may not be running (e.g. when it is suspended), those incoming calls must be signaled via Push Notification, and those push notifications are typically sent by a backing server.
I'm looking for a way to push data to an app similar to APNs but that doesn't use APNs. Is there a way to do this? The reason I want to do this is if the User disables notifications I want to still be able to send data to the app without needing user input such as a pull to refresh or what have you. I only want it to happen when the App is in the foreground.
Basically, I want it to use push notifications like normal, so if there is new data available the user is notified if the app is closed so the user can click on it and have the app open and display the new info. Then if the user disables push notifications through the settings the user will no longer receive notifications, but the app will still refresh if there is new data available.
I tried using GCM/FCM but that just piggybacks off of APNs so it won't work if the setting is turned off for notifications.
Is this even possible?
If the app is in the foreground, you have two options:
1) Poll - For example, every few seconds to you make a network call to poll for new data. This may be possible if you can guess a frequency at which you get new data. But as you can imagine, this is pretty impractical/wasteful if you have to do this very often.
2) Push - You can open a persistent HTTP connection (web socket) and push new data to the client from server. This is more difficult architecture (publish-subscribe) to implement than polling, but definitely worth the time if you implementing any sort of real time system (think new Facebook posts on the timeline, new tweets). For websockets, you can use a home grown solution (eg http://socket.io/) or you can use many available 3rd party solutions (like http://pubnub.com etc.)
How can an iOS app be notified that it needs to update its content?
I would like to have an app that listens for update alerts that trigger a download rather than doing a data request to be able to stay in sync with the server.
What is the correct way to have an iOS app that needs to be in sync with a server stay in sync while minimizing network activity?
Im aware of using a cache locally, NSURL Cache or Core data etc. and adhere to the timeout in the http header etc. but I would like to correctly setup a sync mechanism without having an update button that a user needs to press to get updates.
I have thought of implementing a dispatch_source on a socket but wont that keep the network active and drain battery?
Rather than request a token for the version of the data to sync from the server I would rather like the server to notify the device that it needs to update. Is this practical?
How does the OS handle listening to push notifications? Is it on POSIX level?
You really have two options here:
Client Side Polling: call the server and ask every so often. For 99% of apps this is fine as it's not that big a deal for someone to run the old version during the interval between polling.
Real-time Server Push: If for some reason you need to disable the old version as soon as you push a new version, you could do a server side push. You would not want to use APNS for this (user may deny APNS, delivery not guaranteed, etc). You would want to use a cheap push service like PubNub or Pusher for this to guarantee real-time delivery. Or code you own version using the same principles of these services, but really why re-invent the wheel?
There are two common, as far as I am aware, approaches to doing this on iOS;
Regular GetUpdates calls to the server at an interval (Fairly standard across any platform I think)
Apple's Push Notification Server(APNS) if anything changes on the server you can push a notification to the device.
At work we typically implement both options because there are a few issues with APNS;
They are not guaranteed to reach the device, if the device is offline the APNS service will store the Notification for a limited time in the APNS system upon which it is forwarded (if it hasn't expired)
If multiple Notifications are sent while the device is offline only the most recent notification is sent
If the device is offline for a long enough period of time all stored notifications will be discarded
the user has to allow Push Notifications to be sent to their device because it suppliers and identifier that you can use to determine the device
I'm working on a small messaging app, similar to IM or SMS text messages. I'm obviously planning on using Apple's Push Notification Service (APNS) for notifying users of new messages when the app is not running. The question is, what about when it is running? Should I rely on APNS to notify the app when to refresh the list of messages that the user has received? Or, should I do periodic polling to grab any new messages?
My app will be making use of RestKit 0.20 as its web service client library. Polling should be easy enough to configure there, but I'm concerned about the additional overhead of creating the connections, as well as the increased bandwidth utilization that polling will create.
Is APNS reliable enough that I can use it to trigger a UI refresh when a new message is received? Or should I handle it manually within the app itself via polling?
APNS is very reliable, so you can get away with using it to refresh the application when new messages come in. However, it isn't 100%, so I'd plan on keeping a Refresh button close by to allow the user to poll as they wish.
lets suppose I have a PHP web service, and I have an iphone app that communicates with it. If the iPhone want info from the web services, it makes an http call to the server ans retrieves information. But how do you do this the other way around, how does would the server notify the the application when some state has changed, and what is the most efficient way to do this?
What you are looking for is Push Notifications. You will need to create a push notification server that will send notifications to your users. http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html