Is it possible to have an iPhone app which carries on listening for data on a port when it is sent to background by the user and if any data comes the app can show a local notification and alert the user? I know the multitasking is deliberately limited but wof it allow for that?
It can but with major caveats:
First, the system will unregister any Bonjour names you might have established.
Second, if you're bound to the WWAN, it will go down even with you listening on it (this is true even in the foreground).
Third, if your app is not doing anything else in the background (i.e., isn't registered to provide background music, location events or telephony), you must still shutdown within the time limit for background task completion or be terminated.
So, while you could bind and listen on a socket in the background, for almost all practical purposes, it's not worth doing and you should rethink your design.
This is exactly what push notifications are for. Your application doesn't listen to your server, your server tells Apple's about any notifications, and Apple's server delivers them to the user and your application if the user wants them.
Related
I developed and app that is currently set as "Location based" so that it can run in the background indefenitely. It's not a trick i need it to do stuff when the user moves.
After some search I learned that this app will only execute code on the event of a location change, no timer whatsoever will be able to execute any code after 10 mins.
My app, while in the background, stays connected to XMPP for 50mins or so, it then disconnects. I would like the app to never disconnect, I looked at the framework but I can't find the place where to fix this behaviour. Do you know if it's possible to stay connected "indefinetly"? if so what settings do I have to change in the xmppframework.
thanks
[EDIT]
After 50mins the user is still connected to XMPP but it's disconnected of the XMPPRooms it was conected.
On another run it was connected for 3 hours, the time the iPhone is connected doesnt seem to be consistent.
To make sure your application can do send and receive keep-alive messages, it needs to be a voip app and use a voip socket. From Apple's Documentation:
Add the UIBackgroundModes key to your app’s Info.plist file. Set the value of this key to an array that includes the voip value.
Configure one of the app’s sockets for VoIP usage.
Before moving to the background, call the setKeepAliveTimeout:handler: method to install a handler to be executed periodically. Your app can use this handler to maintain its service connection.
As for the socket:
NSInputStream and NSOutputStream: For Cocoa streams, use the setProperty:forKey: method to add the NSStreamNetworkServiceType property to the stream. The value of this property should be set to NSStreamNetworkServiceTypeVoIP.
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.
I'm reading through the multitasking documentation, and it has a few references to apps which launch directly into the background state, never entering the foreground state. Is this really allowed for regular apps? Can anyone give me an example of an app like this?
VoIP apps are the biggest one to use this feature. Basically a VoIP app can register itself with the system to be notified when network traffic is intended for it at which point the app takes over handling the incoming traffic (i.e. receiving a call). Skype and Viber both use it.
From the iOS Developer Library (emphasis mine):
Including the voip value in the
UIBackgroundModes key lets the system
know that it should allow the
application to run in the background
as needed to manage its network
sockets. An application with this key
is also relaunched in the background
immediately after system boot to
ensure that the VoIP services are
always available.
The significant location changes backgrounding service also allows an app to be updated with the new location even if it's not running.
Other than those two cases, an app can't do anything from a terminated state until the user launches it.
When you use location manager with significantchange notification, App gets backgrounded automatically if the app is killed, when there is a location event
How are push notification better than pull notification on iPhones?
Are there any links with more information about this?
Any help would be appreciated.
Pull notification requires the user to be running your app, and your app to be wasting battery power constantly polling some server (or waiting on some network socket in another thread , or using the new background services).
Push notifications, when enabled by the user, and if the phone has a network connection, allows a message to be sent to a phone even when it's not running your app, prompting the user that your app wants some attention. It uses a much lower power network connection than any frequent polling method.
If you want to know about push notifications, I'm guessing you are interested in the Apple Push Notification Service.
You can read about its architecture here:
http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/ApplePushService/ApplePushService.html
There is no such thing as a "pull" notification, but using APNs gives you the advantage that you don't have to manually poll a server every so often within an app, which usually saves you a lot of battery life in the long run if you are interested in telling the user about sporadic, infrequent events. Using push notifications also allows you to interrupt the user if they are not currently running your app, which of course can be very useful in certain use cases.
You should think about what kind of message flow you expect to see between your app and any server components in your system. Push notifications make the most sense where some event external to your app is going on which requires the app to be updated in some way, and where the frequency of those updates is low or highly variable.
My application needs Internet Connection. It seems like if I keep my iPhone idle for a while it shuts down its 3G connection. Once I wake it up (slide to unlock) and run my application, it cannot connect to the Internet. I have to run Youtube or Safari first, then it gets the Internet connection, then I have to shut down Youtube/ Safari and then I can use my application to login to my service.
Could you please let me know how can I activate 3G connection from my application (so that I can use my application directly after it wakes up from the idle state and I do not have to run other applications like Youtube/ Safari?
Thanks.
To disable the idle timer, take a look at the idleTimerDisabled property of the UIApplication class.
From Apple:
The default value of this property is
NO. When most applications have no
touches as user input for a short
period, the system puts the device
into a “sleep” state where the screen
dims. This is done for the purposes of
conserving power. However,
applications that don't have user
input except for the
accelerometer—games, for instance—can,
by setting this property to YES,
disable the “idle timer” to avert
system sleep.
Important: You should set this
property only if necessary and should
be sure to reset it to NO when the
need no longer exists. Most
applications should let the system
turn off the screen when the idle
timer elapses. This includes audio
applications. With appropriate use of
Audio Session Services, playback and
recording proceed uninterrupted when
the screen turns off. The only
applications that should disable the
idle timer are mapping applications,
games, or similar programs with
sporadic user interaction.
There is obviously another better solution, but you could load a blank page with:
[NSString stringWithContentsOfUrl ... ]
The connection will be established if it is necessary.
Only NSURLConnection (and any APIs that are layered on top of it) reinitializes the data connection after waking from sleep. To reinitialize the data connection create a dummy NSURLConnection to a non-local address and cancel it right away; then the socket API will work as expected.
There is a post on the developer forums where an Apple dev explains this in detail (but I can't find it at the moment)
Are you sure you're establising the connection correctly? My application does the same using sockets and it has no problems to re-establish the connection after device sleep. Use Reachability API in SystemConfiguration framework to get notified when coverage is available and after that make your connection attempt. Note that a time period - from several seconds to couple of minutes - has to elapse after the device awakes to gain Internet connectivity, so be patient.
There is Reachability sample from Apple, search also stackoverflow for reachability and you'll find more hints how to implement it.
Actually, you get the same problem when you change the network settings on your phone between launches of the application. For instance let's say that you use the WIFI connection when you launch the app. Then you close the app and switch off the WIFI so that the device uses the carrier's network. When you relaunch the app the socket won't be able to connect unless you do the trick with the dummy NSURLConnection (or you launch the browser before lanuching the app).
Also, canceling the NSURLConnection right after initializing it (with connectionWithRequest or initWithRequest) did not work for me. Either do not cancel the request or wait some time before canceling it (e.g. with performSelector:withObject:afterDelay:).