I have a pretty unique situation:
My iOS app has companion hardware that it's connected to via Wi-Fi. The Wi-Fi creates a local network, meaning that when the phone is connected, there is no outside internet access.
I want to be able to post analytics up to a centralized server that we've built via a simple REST API. The issue is that users may only ever open and close the app while they're connected to the network, meaning that when they do have outside internet access, the app may have been terminated (or at the very least, put in the background).
If I run code inside of
-(void)applicationWillResignActive(UIApplication *)application
OR
-(void)applicationDidEnterBackground:(UIApplication *)application
OR
-(void)applicationWillTerminate:(UIApplication *)application
They may only get called when the user is still connected to the Wi-Fi network with no outside access.
Is there any way you can think of uploading some simple data to our server even under these circumstances? Is there a way to spin up a quick background process to do this after the fact?
Thanks!
You can use NSURLSession to do uploads from the background. Once you submit the upload task, the system keeps it running even if your app moves to the background or is terminated.
Related
We are building an iOS iPhone app that needs to check-in with a server on a 12 hour basis. This is needed to let the server know that the app is still using it's service on the server. To our understanding this is possible when the app is in background state (not showing on the foreground) via backgound fetch or remote notifications.
But this is not possbile when the app is not running or terminated, when the app is in these states then there is no way to initiate communication with a server. Is this statement corret? Is it possible initiate the communication after a device bootup, is it then possible to send a small keep alive message to te sever?
The background fetch and responding to remote notifcations is not possible in the not running and termenating states(?), so we cannot use these mecahnisms for this purpose. If that is the case are there any other solutions that we can try? Or is it just not possible?
We looked at many sources on the internet but some say that it is possible and others say it is not.
You might want to take a look at the Silent Push Notifications. Here is the thing, if the app is in background mode or suspended state, you will be fine. If the app was killed by the user, you have a problem.
You can always send a silent push notification, and wait for a service call made from the device to your service. If there is a response, it means the app was in background or suspended, and then you can go ahead and do whatever you need to do. If no request is made, it means that app was killed. Then you might want a sent a non silent push letting the user of that device know that he needs to launch the app or something like that. I don't know how you are going to work around it, but that could be a possibility.
I would tell you to take a look at NSURLSession and Background NSURLSessionConfiguration as well, but you will run into the same issue. If the user manually terminates the app, you need to find a work around to set up that connection to the server, and that will imply the user to somehow launch your application.
I have a voip app, but it won't wake up from standby mode when a call comes in. The docs say the following:
There are several requirements for implementing a VoIP app:
1. Enable the Voice over IP background mode for your app. (Because VoIP
apps involve audio content, it is recommended that you also enable
the Audio and AirPlay background mode.) You enable background modes
in the Capabilities tab of your Xcode project.
// I did this using the "capabilities" tab in the project's settings.
// I have "audio and airplay", "voice over ip",
// "background fetch" and "remote notifications" checked.
2. Configure one of the app’s sockets for VoIP usage.
// I have 2 sockets, one for sending stuff to the server that closes after sending.
// One socket that stays alive all the time, which is used to
// receive stuff from the server.
// The one that stays alive is configured as voip*.
3. 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.
// I did this and in the handler I send a login message to the server,
// On the server side it's detected that the account is already logged in so
// it refreshes the connection instead.
4. Configure your audio session to handle transitions to and from active use.
// I did not do this yet, I might in the future.
5. To ensure a better user experience on iPhone, use the Core Telephony
framework to adjust your behavior in relation to cell-based phone
calls; see Core Telephony Framework Reference.
// I did not do this and probably never will (company's decision, not mine).
6. To ensure good performance for your VoIP app, use the System
Configuration framework to detect network changes and allow your app
to sleep as much as possible.
// I don't do this yet, but will implement it once all the basics run fine.
When a call comes in I create a local notification to let the user know about the call. When the app is minimized this works fine, but when the device is in standby (sleep) there is no notification. When I wake the device from standby, the notification pops up after a few seconds (so it's not already there, it really appears after waking up the device).
I created more voip apps in the past, and I can't remember ever having trouble with this. I'm running ios 8 now, perhaps I have to do some more to make it work while in standby? Are there more requirements for voip now? Or am I missing something stupid?
Note: I know about push notifications. They are an option (in fact, I already tested and they make it work), but I'd rather not be dependent on the apns.
I just spent two full days troubleshooting a similar problem. An iPhone 6+ worked properly but neither of two iPhone 6's did. To make a long story short, SIP packets were not being transmitted reliably. I pinged the VOIP servers offered me and found that I was using one with a latency of 30 milliseconds but one with 15 milliseconds' latency was available, so I tried switching servers. That did the trick.
Be aware that if the user closes the App manually (double click home button, swipe up) your application will not be able to run in the background until the user manually opens it up.
However, the system does not automatically launch your app if the user has force-quit it. In that situation, the user must relaunch your app or restart the device before the system attempts to launch your app automatically again.
Check it here.
I have a chat application developed by JS. I want to send PING to server once in a while. Its not a problem if app runs on fore ground. The problem is when user minimizes it or open another app. My app looses its focus and gets into suspended state.
I have following two use-cases.
To keep the chat session open I need to send PING to server (Its an IRC server) every X minutes even the app runs in background.
We also need to check for new messages (by ajax on a local http server) and add a local notification to the notification queue so when user clicks on it app can resume
I have found apple does not allow running apps in the background. if they allow they require special permission. I found some apps does it by requesting finite length execution time.
What is the best way to get highest possible background execution time? As a chat app can I request permission for voip, location or any other way ?
Note: the app will be running in an environment where there is no Internet. Hence push notification will not work here.
Update: After doing a lot searching I found background fetch. It seem background fetch will suite it. But still the problem remains, its not called in a timely manner.
This sounds like an interesting problem. From reading the various comments, it sounds like you want this to work when you're on a local network - so you have wifi, but the wifi router/base station isn't connected to the actual internet?
Because background refresh isn't going to be predictable - you'll never know when it is going to update - you might want to get creative.
You could look into exploiting iOS VOIP support, only without the Voice! Apple has some tips on VOIP here. VOIP basically uses something called SIP (Session Initiation Protocol), which is signalling layer of the call, and a lot like HTTP. It's this SIP layer that you want to take advantage of.
This isn't going to be terribly easy, but it should be achievable. Setup your app to use VOIP, and then look into something like PJSip as your SIP library. Then, on your local network have a SIP Server (I'm sure there are plenty open source implementations) that you can register your iPhone against (so your server knows where your phone is, pretending to be a VOIP phone). This should work, because it doesn't need to go through Apple as far as I am aware... And will run happily on your local network.
Then, the server can send a message via SIP to the handset, as if it were instigating a VOIP session. You app is awoken, gets the messages - ideally from the SIP message if possible - and then just doesn't start the session. SIP was designed just for creating sessions, not just VOIP. When I worked in Telecoms R&D (a long time ago) we were using it to swap between Text/Voice/Video, all using local servers.
You'll have to jump a lot of hoops to make this work, but it would be pretty awesome. I have never tried this actual use case - especially with iOS, but I'm fairly sure it will work. It is a bit of a fudge, but should get you where you need to go.
Good luck!
You can use something like PubNub to build this chat app with iOS using native Objective-C code, or with the Phonegap (Cordova) libs.
The beauty with using a real-time messaging network like PubNub is that when the app goes to the background, you can easily have the chat messages come in on APNS.
When the app is in the foreground, it can just receive them as the native (PubNub) message. And if it needs to "catch-up" with the messages it missed while in the background (but received via APNS), its trivial to implement.
Also, PubNub is platform agnostic -- so you can easily also use it on Web, Android, BB, Windows Phone, etc.
http://www.pubnub.com/blog/build-real-time-chat-10-lines-code/
http://www.pubnub.com/blog/html5-websockets-beautiful-real-time-chat-on-mobile-using-pubnubs-channel-presence/
https://github.com/pubnub/objective-c/tree/master/iOS
https://github.com/pubnub/javascript/tree/master/phonegap
geremy
I'm spec-ing an iOS app (which will be built outside of our company) which will upload a user's data entry to a server. If the device is not connected to the Internet, we'd like to save data on the device and upload it when the network is re-connected. (The app will primarily run on iPod Touch devices that will be disconnected most of the time).
If the user unlocks the device and re-opens our app after the network is reconnected, then uploading to the server should be easy because the app is running.
But what if the app is not running, where "not running" can mean one or more of:
device was power cycled
user has locked the device and it's sitting in his pocket
app crashed
user exited the app
user started using other apps so our app isn't running in the foreground anymore
are there other cases?
In the cases above, is there a way (ideally a battery-efficient way) to ensure that local data is uploaded soon after Internet connectivity is restored? Is the answer different depending on which of the cases above caused the app not to be running?
And is there a minimum iOS version the device will need in order to enable some (or all) of the above not-running cases to still upload when the app is not running?
My apologies if these are obvious newbie questions-- I'm not an iOS expert.
There is an interesting technique that is used by among others Instapaper and News.me(the pioneers of this technique) where you use region monitoring to initiate background downloads or uploads. Marco (Instapaper) blogged and talked (in episode 80 of the Build and Analyze podcast) about his communication with Apple so it should be a allowed in the App Store.
In brief the technique is that you set up certain regions (geofences) like "home" or "work" and respond to the locationManager:didEnterRegion: (and similar) callback(s). Your app will wake up from the background once you enter the pre-specified region and you can check to see if there is any data to upload.
This technique won't guarantee that the data is uploaded when the network reconnects but it will allow your app to automatically upload the information when the iPod Touch users gets home to their WiFi network.
That should most likely be at least once a day which may or may not be frequent enough for you. You could add a timestamp to when the initial upload was attempted and send that along the upload once it succeeds to get the correct order of events (data entries) on your server.
There is no way to ensure this. If your application is "not running" (by the definition described in your question), it will not be capable of responding to a change in the device's network status. It should be setup to resume upload operations the next time the application runs again.
EDIT:
Some of the cases you've described may indeed provide different opportunities for your application. Specifically, if the user "exits" the app by pressing the home button or launches another app in the foreground, your application may continue to run the in the background and could potentially respond to a change in network reachability.
The nature of what may be done in the background and for how-long is well documented, and supported by any version of iOS that supports multi-tasking. I recommend you review the documentation pertaining to App States and Background Services.
device was power cycled --> really NO WAY of resuming, unless you open the App!!!
user has locked the device and it's sitting in his pocket --> apps applicationStatus is UIApplicationStateInactive but it is running in the background. You still are able to react to notifications and i.e. accelerometer events. Try the Reachability Class and Log the changes!
app crashed --> NO WAY, unless opening the App
user exited the app --> App is sitting in the background. There you have a maximum of 10 Minutes Restriction of fully using your App (like the App "Pastebot" does)
user started using other apps so our app isn't running in the
foreground anymore --> Same as user exited the app
On multitasking Apple says the following:
Real multitasking only for certain kinds of usage, as there is Audio Background playing, VOIP (like Skype), navigation applications
All the other apps can request a specific amount of time after the app is closed/in the background, to finish certain tasks (as sending an email, sms or uploading/downloading important data)
Important Quote from dev docs:
Your app delegate’s applicationDidEnterBackground: method has approximately 5 seconds to finish any tasks and return. In practice, this method should return as quickly as possible. If the method does not return before time runs out, your app is killed and purged from memory. If you still need more time to perform tasks, call the beginBackgroundTaskWithExpirationHandler: method to request background execution time and then start any long-running tasks in a secondary thread. Regardless of whether you start any background tasks, the applicationDidEnterBackground: method must still exit within 5 seconds.
If you're building a restful API then I would recommend using RestKit, it has a request queue that checks the network status on the device and starts uploading once network access has been assured. You can read more about this here: http://mobile.tutsplus.com/tutorials/iphone/advanced-restkit-development_iphone-sdk/. Read the sections about Request Queue and background download/upload. It should be noted that RestKit is a big library which has it's advantages and disadvantages. I'm not completely sure how this que works with the app lifecycle, if it saves the request que even if the app is terminated. You would have to investigate that. RestKit does support background uploading/downloading, but as already noted, I think it's impossible to do any uploading if the app is terminated and not in background state.
I wouldn't recommend using RestKit if the API isn't Rest though.
You can download and experiment with RestKit here: https://github.com/RestKit/RestKit.
Is it possible to interface with a webservice (or, for what matter, do any scheduled local or remote activity) while the app is in background?
I know that you can receive remote pushes or schedule local alerts, but I wonder if I can periodically send my GPS position to a webservice even if the app is not in foreground.
I have been thinking about this myself in an attempt to impress my boss with an iPhone/iPad App that accesses our Web Service.
If the Web Service takes a non-trivial amount of time to process a request then there is absolutely no guarantee that the App won't be interrupted and stopped, therefore making it useless for any business-level tool. The only Apps that are allowed to run for extended periods in the background are a select set that use certain frameworks (music players, etc.).
I concluded that the only way of doing it is to introduce a middle tier that performs and waits for the response from the actual Web Service and provides an interface that the iOS App can poll or be pushed to in order to allow it to sleep/die whenever iOS thinks it should.
You can make sporadic network calls while you are running in the background if you are a location-based app with proper permissions. You need to make sure you are running a background task properly. FYI, there are a number of applications in the app store that do this.