I'm developing a chat-app for iOS that must use an existing server API. The way it works is pretty straightforward: the app checks every given interval whether there are new messages on the server and displays them, plus, it sends the server new messages that the user typed.
When the user starts 'multi-tasking' or presses the home button, my app will go to the background and therefore will not be able to check the server for new messages. The server will automatically assume that the user stopped the chat when a certain timeout has been reached.
Often, the user isn't aware of the fact that when the app is put to the background, it is unable to maintain the connection to the server and will stop the chat. I'm looking for a method that will notify the user of this behavior as soon as the app is put to the background.
My current idea is to notify the user when applicationWillResignActive and/or applicationDidEnterBackground is fired, but I wouldn't know in what way. Can it be done in a way that complies with Apple's guidelines?
I'm aware of the fact that the best solution would be a different overall design of the software (e.g., using push notifications and no server-side chat termination by timeouts), but in this case I can't change that.
I would continue running in the background and set an expiration handler block (called by the os when you app is REALLY killed) and there schedule a UILocalNotification
use
- (UIBackgroundTaskIdentifier)beginBackgroundTaskWithExpirationHandler:(void (^)(void))handler
Related
I have an iPhone application like facebook for iPhone. My application must connect my server and read all message every two hours regularly. I have a thread to read all message but when the application is terminated the thread cannot work. Can the thread run undependently from main delegate or how can I find solution for this problem?
You cannot have your app do stuff in the background. There is an API to finish tasks like uploading a photo but even that will be killed after around 10 minutes.
But the Apple Push Notification Service seems like the most appropriate solution for your problem. Your server notifies the device that there is something new happening and you fetch the actual messages when the user opens the app.
edit: As of iOS 7 Apple implemented a feature where you can schedule running tasks to fetch data in the background. Those tasks are not guaranteed to run at any specific times. See the release notes for iOS 7 and the linked methods below:
Apps that regularly update their content by contacting a server can
register with the system and be launched periodically to retrieve that
content in the background. To register, include the UIBackgroundModes
key with the fetch value in your app’s Info.plist file. Then, when
your app is launched, call the setMinimumBackgroundFetchInterval:
method to determine how often it receives update messages. Finally,
you must also implement the
application:performFetchWithCompletionHandler: method in your app
delegate.
There is no solution.
Apple does not permit applications to run in the background unless they are of a specific type such as location or audio or voip or newstand (your app can continue to run for about 10 minutes after it was active if it uses shouldBeginBackgroundTaskWithExpirationHandler).
There is no workaround, many many other people have wondered how to do the same thing as yourself before, but there is no legitimate way. Your app cannot schedule any sort of periodic call home activity.
The only way your app can run once its gone into a suspended or terminated state is for the user to launch it, either explicitly or in reponse to a local notification or remote push notification.
Is it possible to get a notification (that launches the app) when the network gets available?What I want is my application to update its contents as soon the internet gets available.The only way I can think of is to send a push from the server once is a while (may be once a day)and that tell the user it might be a good idea to get yourself synchronized.
This is currently impossible if your background task scope is limited to that feature. The only way you could do this is if you had some other legitimate reason to become a background app (aka VOIP or GPS) and run reachability checks every X minutes, and then post a UILocalNotification that allows the user optionally open the app (you cannot programmatically open your app yourself).
Is it possible to keep a socket connection alive in background, to be able to push new data and alert users at all times?
The answer to this question is a definitive yes. If you are in the background state, then you can keep a connection open and process messages from a server.
Unfortunately the complexity here is that you don't have a lot of control over the state your application is in:
foreground - The user has tapped your icon and the app is running with the UI visible.
suspended - The user was previously running your app in the foreground, but suspended it by hitting the home button or receiving a call. Basically your app is 'freeze dried' and will remain inactive until it is resumed by the user (starting where it left off) or it is terminated by the OS (see below).
background - The app was previously running in the foreground but has moved to the background state as a result of something the user has done. Normally your app will move to the suspended state in this case, but there are things you can do as the developer to prevent the instant 'freeze dry' and go into the background instead (see below). Your app will also be in the background state if it is woken up for a significant change event.
terminated - Your app has been unloaded from memory and the next time it starts will be from scratch. This is what happens when you double click the home button and then tap the x next to your app icon. It moves the app from the suspended state into the terminated state. This will also happen if the OS decides it needs room for more recently running apps and your app has been suspended for a long time.
So obviously the trick here is how do I stay in the background state as a long as possible. There are a couple of ways to do this:
Beg for more time - You can get up to 10 minutes of additional background processing when your app is closed if you ask for it.
Use UIBackgroundMode - You can declare youself a voip, audio or location app by adding the corresponding UIBackgroundMode value to the pList. There are special requirements for these types of apps which you can check out here.
So these approaches are not without their own problems (getting approved on the store being one of them) and as such I tend to agree with the other answers that using push notifications is probably your best approach for notifying your users. With the notification improvements in iOS5 this is going to be the best user experience going forward.
You can keep a socket connection alive (or do whatever else you want) in the background for about 15 minutes after your app closes. There are also more specialized background processing modes (specifically, audio, voip, and location) which Apple supports if your app fits into one of their supported categories. See here.
If you want to keep sending the user notifications indefinitely, you want to use the Apple Push Notification Service. This allows your app to continue to receive notifications when it's not running, and it conserves resources since there's only one connection to the APN service at a time.
You can definitely alert users with local and push notifications.
And as far as I know, you can keep a connection open only for limited time.
Look here for more details.
Hey, I am about to start working on an app. I am a beginner, so I am starting out with a pretty basic concept. But, I was wondering if it was possible to send texts from an app. For example, if the person using my app sets a new high score, could they hit a publish button and my app could then send a text to his buddy bragging about the new high score.
Also, what if someone is using my app and they receive a text, does the OS take over, or do I have to handle the reception of text/calls. Is it possible to alter the way the phone behaves when my app is disrupted by calls/texts.
Thanks for any advice you can give. Have a good Monday everyone!
Apple's iOS documentation has a section that roughly covers how to incorporate in-app SMS.
Basically, your application displays an MFMessageComposeViewController as a modal view controller. It won't cause your app to terminate or background — it just lets your user send a text message, and when done, return to your app and continue.
When a phone call, text message or another notification comes in, your application delegate's applicationWillResignActive: method is called. It's up to you what you want your app to do while the user is dealing with the call, message or notification. If the call is declined or the alert dismissed, your application delegate's applicationDidBecomeActive: method is called and your application can resume as if nothing happened. Otherwise, the app either exits or backgrounds (depending on whether you want it to support multitasking), and you'll also have to handle it from there.
Also bear in mind what Toastor says about
Controlling whether messages can display to your user or not
Bills related to texting plans
There is no way to change the way the phone responds to calls. The only way to prevent your app from being interrupted by an incoming call is by activating the airplane mode on the device - which you cannot enforce from within the app.
Same goes for incoming texts - there is no way to notify your app if a message has been received. How would the system know if the message is meant for your app anyway?
The only thing you can actually do is send a text message from within your app. But if I were you I'd go either with established leaderboards or the new GameKit (have not checked this out yet myself, though).
Or, at least, use mail instead of text messages, since texts are not free in every country.
I'm developing an application that needs to take action on completed phone calls, preferably right after the call ends but minimally once per day.
I've read up on the new CoreTelphony framework, and it seems I can get call events if my app is active, but I don't see how to launch/wake my app when a call ends if my app is not the foreground app. I also don't see how any of the new pseudo-background "modes" would allow my app to listen for these events in the background. Do any of you know how this might be done?
If post-call processing isn't possible, then I'd like to figure out a way to automatically wake my app up once per day, pull all of the call events since the last wakeup, and process them. I know how I might do this with Push or Local notifications, but my understanding is that those require user action to continue; in this case, I just want the processing to happen automatically. Is there a mechanism that would enable this?
Thanks,
Dan
You can't launch your app without user interaction.
Push / Local notifications aren't for this kind of thing, they're for letting the user know about event.
On a non-jailbroken device there is no way to do what you want to do.