I am developing SIP and VoIP based iOS application and requirement is that the application should be continuously running even in background also.I am using pjsip lib.
I know that to run the iOS application in bacground,we need this
Set UIBackgroundModes key in Info.plist with voip value
Created a handler that I passed to setKeepAliveTimeout:handler: for
keeping the connection alive
But I just want that if my application is running in background can I receive UDP packets over (RTP/RTCP),while I am keeping UDP port always open.
I have already gone through the posts:
iPhone VOIP in background
VoIP socket on iOS - no notifications received
But,I have not getting clear idea that can we get UDP packet continuously even the app is in background or foreground.
So that if there is any data is coming to iOS client app , the app should be able to notify the user.
Please give suggestions.
In order to run VoIP app at the background and register on a server one should use TCP on iOS. When something happens you can fire local notification.
I think you can set local notifications when the app is running in background and indicate the user of an incoming call through the notification. When the user enters the application you can show the incoming call.
In the below link, check
Background Execution and Multitasking and also Scheduling the Delivery of Local Notifications
IE since you have set the UIBackgroundModes key in Your Info.plist, your app will support long running tasks. So in the applicationDidEnterBackground method add a method which creates a UILocalNotification when there's a call. UILocalNotifications notifies the user with an alert message and a tone of your choice. So once the user is notified and user enters the app, the app will come to foreground where you can add the method for him to receive the call.
In the alert body of the LocalNotification you can send the caller's information to the user.
EDIT : Check out the answer of Paul Richter in this link, where he says
VOIP mode gives you the ability to have code running to notify you of a call coming in
but you're not going to be able to record audio from the background. If you look at how
Voip apps work, when a call comes in a Local Notification is sent informing the user
that a call is coming in. The User then must accept the call which will bring the
application to the foreground at which point from the audio side of things you can
activate your session and proceed with the phone call.
Although not completely related to the library you are using, he has given a decent explaination of the process.
Hope this helps.
Related
I am building a TVOS app for the new Apple TV that needs to get notifications from a server to update it's display. Remote notifications are not allowed with TVOS, and it actually displays an error when you try to register the app for remote notifications.
With this being said, are there any alternatives to what I need?
To clarify:
- The app stays running indefinitely, showing a display.
- When the user adds content to the display, I want to notify any apps that are logged in to the same user to update the display.
- I cannot use remote notifications.
Please let me know if this makes sense, and thank you in advance for your help!
What part of the registration errors out for you? Notification dialogs and banners may not really make sense on tvOS, but can you send a silent push notification? All you need to do to register for these is
[application registerForRemoteNotifications];
You do not need to display the request dialog to the user for permission for silent notifications (you do need to have the remote notifications entitlement though.)
According to Apple's documents here, they allow CloudKit. CloudKit subscriptions rely on silent push notifications that I would assume would work on tvOS (without them it would severely cripple CloudKit)
If that still does't work, then you could create your own long polling connection (essentially, you would be making your own custom push notifications). It would only be able to send messages to devices that have the app opened however.
I guess you can have the app poll a web server at a given interval to check if any updates have been made...
In my application , i works with web-services and when user log in into my app my app is sending a request with status 1 means loged in and when on log out button click sending a request with status 0.
Now problem is , when user removes app from devices , status in my server is remain 1(log in) , hence other user can see him available while his app is not in device. so is there any way by which i can send request when my app removes from device (i don't think it is possible) or is there any other way that i can do in my backend side ?
Thanks in advance.
It is not possible to call a web service when the user deleting the app from an ios device. There are three methods to came to know that whether your application is there in user's ios device. But there are few limitations also.
Activate Push notification: By doing this, device will get registered with Apple's push notification service. When user delete the app from device, the registration will be revoked from APNS server and through the APNS feedback service, you can get to know whether the application is existing. (Limitation: If the user did not agree with receiving push notifications, then the app will not be registered with APNS and you never came to know that whether application is existing or not)
Activate Location Based service: If your application enables location based service, then your application will get periodic location updates in a location delegate method. In this delegate, you can call a webservice and keep update the status of user even the application is in background. (Limitation: If user disables the location update, then your server will not get info about user status)
Periodically Call a Webservice From you app: This is possible only if your app is active. (Limitation: When you application pushed in to background, your application will be in suspended mode, so it will not possible to call webservice)
Sorry Unfortunately Apple not provide any method that user Uninstall app from user's device, There is no such method.
When user delete any application device does give the alert "Do you want to delete this application" with option "Delete" and "Cancel". You don't have to write any specific code for this.
I just assume that There is one method in which you can find out when user is about to delete your app. That is you need to implement push notification Apple server will inform you when you try to push to an uninstalled instance. Other than that there's no way to detect it but i am not sure its helpful or not.
You can't do this from within the app. You would want to do something like have a periodic task which runs on the backend, checking the last activity date of logged in users and setting them to 'not available' after some configured period of inactivity. This will probably require some changes to the backend to record last activity date and a change to the app so that while it's open it sends a periodic 'heartbeat' to the backend. You probably want to make the timeout quite big (say 15 minutes, big enough to not have a large impact on performance).
I am new to iphone. I am doing Project in that i have struck in the middle because of local notifications concept.In my applications i am sending the request to the server and getting response for every 20 sec by using timer concept but when the application enter the background
how can we get the response from the server for every 20 sec by using local notifications.If anybody knows this concept please help me...
When App on background mode , you receive loacl notification, and you click yes button then
- (void)application:(UIApplication *)app didReceiveLocalNotification:(UILocalNotification *)notif
this function is call and you get dictionary
NSLog(#"%#",[notif userInfo]);
and call the xml in this function.. and you can get resonance from your server very easily
Generally, your app doesn't get to execute in the background, and local notifications won't provide you the ability to execute in the background.
(There are exceptions to this, but they come with limitations. If you really need to ping a server every 20 sec because you're something like a VoIP app, you can declare that you're a VoIP app and set up a keep-alive handler for doing that ping. However, if you're submitting to the App Store, Apple will require that you're really implementing a VoIP-like app, and not just downloading new RSS feeds in the background or some such.)
What local notifications are for is getting the user's attention when your app isn't active. While your app is running, you can schedule a local notification to post a message to the user some time later (sort of like a calendar alarm). If you're using one of the supported background execution modes, you can use a local notification to get the user's attention right now. Either way, your app only gets activated if the user chooses to tap the notification.
I have implemented all recommended methods in AppDelegate to get working Remote Notifications service.
I can accept them while running, while launching and while turned off.
But there is an issue, since I can't work with many received notifications while in background. I can work only with latest notification.
What is recommended manual to do that? How can I got all notifications received while in background? Is it only solvable via manual call to my service provider (sender of apns data)?
With all the projects I've worked on there hasn't been a way to locally store this information if the push notification is dismissed. In all those cases we used a small file on the server that the app would connect to and pull when it became active again. There was also some place in the app where the user could see all their notifications which, again, were stored on the server for quick retrieval.
With the way I understand push notifications to be setup, if the notification is dismissed the system discards it. It'll perform anything it's supposed to do (such as update the badge number and play the correct sound) but any additional information specific to that notification is lost.
Not sure if this helps, but if you just want to know how many notifications you have missed while you were in background. You can create a variable which contains notification number and store this in the app every time you handle notification. When you come out of background and receive a new notification you can subtract the new number with the stored number to find out the number of missed notifications. I don't think there is a way where iOS can give you complete data associated with all the notification device have received while the app was in background.
The best solution is to keep a list of sent notifications with all relevant data on your server, so the app can access that data when it launches. Sending multiple notifications with data that is not stored on the server can be risky, because the application only receives the notification when the user opens the app from that notification, so if they tap on one notification, the app will only every receive that one.
If you have them all in a list on your server, the app can simply go and pull that list down, and process it, making sure no data is lost.
I have an iphone app receiving network message from server. It is ok when the app is running in frontend.
However, when the app is running in background, the app does not receive network message. After I bring it back to frondend, it starts receiving.
How to make the app can receive network message even it is running in background?
Thanks.
You've got two options for network connection while in the background:
Push Notifications. The app is not running, but your server can request to send a notification, which will then be sent to the iPhone, prompting the user to launch your app which can then update itself from your server thru a regular request.
Background network calls. Your app can request to keep a thread alive in the background in order to finish a network activity. You could use this to send a request when your app closes to check in with your server.
First check this post: iphone - Connecting to server in background
Second, specifically speaking, when you app is in the background and is frozen by the OS, it won't have access to the internet, thus any call back from an async request won't be heard by your app.
Third, a possible strategy:
When you app is to switch to the background, immediately post a request to your server so your server would have an updated record about your app's latest status
When your app is to switch back to the foreground, again, let your server know about this by posting a request
It might happen, that your app is still in the background while your server just need to access it or send any message to it. In this scenario, try APNs (Apple Push Notification Service) provided by Apple. It's free and easy to implement. The possible outcome once you set up APNs for your app would be, the user gets an push message from your server and then decide to put your app back to the foreground. Though it's still totally up to the user, chances are good.
I'm not an iphone dev but for me, for all background apps, all network messages should be push to apple server and then push to the phone. There is no service like in Android.